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

On Wed, May 23, 2018 at 3:24 PM Lou Steinberg <lou@ctminsights.com> wrote:

> Hi Ben
>
> Thanks for the comments. A couple of thoughts, though I am by no means an
> expert in Alt-Svc-SNI so please correct me if I get this wrong.
>
> I think the biggest concern was that the alt service may need to present a
> certificate for the origin (with TLS). We had explicitly tried to avoid
> having to manage certificates on the validator. Maybe that's worth
> reconsidering if this simplifies the process.
>

I think you can do this without managing any certificates on the
validator.  The validator can simply inspect the SNI, and then either
forward the entire TCP stream to the origin or drop it.


> Additionally, as I understand it, the client woukd still need to manage
> the expiration of Trust Tokens, but the client generally doesn't have
> access or visibility into the fact that alt services are in use. There is a
> freshness setting that allows an alt svc to expire, but I think the client
> is still permitted to continue to use the alt service after expiration.
>

I think this may be based on a misreading of RFC 7838:

   Clients with existing connections to an alternative service do not
   need to stop using it when its freshness lifetime ends; the caching
   mechanism is intended for limiting how long an alternative service
   can be used for establishing new connections, not limiting the use of
   existing ones.

This means that client does not have to tear down its open sockets, but it
cannot use an expired Alt-Svc value for establishing new connections.


> Can the validator send a misdirected request should this happen?
>

I don't think you need to worry about clients using expired Alt-Svc values,
but if you want to fail gracefully, you could have the validator forward
connections with expired Assertion Tokens to the "public" origin servers
that handle untrusted traffic.  The client will then get a new Alt-Svc
value, which will override their present value.


>
>
> Appreciate your help!
> Lou
>
>
>
> On May 23, 2018 9:54:44 AM EDT, Ben Schwartz <bemasc@google.com> wrote:
>>
>>
>>
>> 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
>> >
>> >
>> >
>> >
>>
>
> --
> Lou Steinberg
> Managing Partner
> CTM Insights, llc
>
> Sent from my phone while not driving. Please excuse typos and brevity.
>