W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

New Version Notification for draft-jjmb-httpbis-trusted-traffic-00.txt

From: Brzozowski, John Jason <jjmb@jjmb.com>
Date: Tue, 22 May 2018 15:00:19 -0400
Message-ID: <CAFFn+aXKxXgYj4ZaHzx=U5U6PL-_cYzRiQcB-F2_54Yc+vOqsQ@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC