- From: Brzozowski, John Jason <jjmb@jjmb.com>
- Date: Tue, 22 May 2018 15:00:19 -0400
- To: ietf-http-wg@w3.org
- Cc: Kris Beevers <kbeevers@ns1.com>, Josh Shaul <jshaul@akamai.com>, John <John_Leddy@cable.comcast.com>, Lou Steinberg <lou@ctminsights.com>, Lutz Jacob <ljacob@bloomberg.net>
- Message-ID: <CAFFn+aXKxXgYj4ZaHzx=U5U6PL-_cYzRiQcB-F2_54Yc+vOqsQ@mail.gmail.com>
A small group with members who work at Akamai, Bloomberg, Comcast, CTM,
Google, NS1,and  Squarespace self-formed about a year ago to work on a
solution to high-volume DDoS traffic from IoT devices.  From this emerged
an idea to use tokens, like cookies, that an internet destination could
issue to change how traffic flows to it from trusted sources (e.g.
bypassing scrubbing centers, creating a deterministic mechanism and
eliminating potential delays or loss during attacks).  The mechanism
selected was designed to work with https traffic over IPv4/6  without
having to distribute certificates to decrypt.  A variant of the mechanism
for any IPv6 application was defined that leverages SRH, but the consensus
was to prototype our solution for http/s traffic using browser cookies.  A
working POC was implemented and tested for both performance and resiliency
at scale.  The group would like to share our work as a potential BCP.
We believe that broader input from the community would help to produce a
better solution.  For example, we included an optional ability to use IP
addresses to inhibit replay attacks, though we understand that it likely
won't be desired in dual stack environments with long-lived authorization.  We
considered   https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-01
to eliminate the need for our redirect mechanism, but were concerned about
needing certificates to decrypt the contents for intermediate validation
and didnt see a place to assert that a session was authorized for different
treatment.  We considered TLS client_hello extensions to to not overload
the SNI/hostname field but were unsure if the browser would have access to
this layer.  While our approach has been demonstrated to work, we are open
to discussing and revisiting any of these.
John
+1-484-962-0060
-----Original Message-----
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Subject: New Version Notification for
draft-jjmb-httpbis-trusted-traffic-00.txt
    A new version of I-D, draft-jjmb-httpbis-trusted-traffic-00.txt
    has been successfully submitted by John Jason Brzozowski and posted to
the
    IETF repository.
    Name:               draft-jjmb-httpbis-trusted-traffic
    Revision: 00
    Title:                 Trusted Traffic
    Document date:  2018-05-22
    Group:               Individual Submission
    Pages:               12
    URL:
https://www.ietf.org/internet-drafts/draft-jjmb-httpbis-trusted-traffic-00.txt
    Status:
https://datatracker.ietf.org/doc/draft-jjmb-httpbis-trusted-traffic/
    Htmlized:
https://tools.ietf.org/html/draft-jjmb-httpbis-trusted-traffic-00
    Htmlized:
https://datatracker.ietf.org/doc/html/draft-jjmb-httpbis-trusted-traffic
    Abstract:
       Current methods for managing traffic through content inspection tend
       to process all sessions similarly.  Internet traffic examples like
       DDoS mitigation require all data to pass through one of a limited
       number of scrubbing centers, which create both natural choke points
       and the potential for widespread collateral damage should a center
       become overloaded.  Similar issues exist with email SPAM and malware
       filtering, traffic shaping, etc.  We propose a method to utilize
       existing HTTP and HTTPS protocols that enables destinations to
       temporarily confer trust on sources, and for trusted traffic to be
       routed and processed differently from untrusted traffic.
    Please note that it may take a couple of minutes from the time of
submission
    until the htmlized version and diff are available at tools.ietf.org.
    The IETF Secretariat
Received on Tuesday, 22 May 2018 19:00:56 UTC