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

On Tue, May 22, 2018 at 3:10 PM Brzozowski, John Jason <jjmb@jjmb.com>
wrote:
>
> 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.

I don't claim to have fully understood the draft's logic, but could you
expand on why Alt-Svc-SNI doesn't work in this case?  It seems to me that
the server could compute an Assertion Token and pass it to the client as a
replacement SNI, and the client would then display that token in the SNI,
labeling its connections until expiration and achieving the intended
effect.  I don't see why any decryption would be required.

>  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
>
>
>
>