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

On Sat, May 26, 2018, 5:26 AM Lou Steinberg <lou@ctminsights.com> wrote:

> Got it on both...makes sense. Let me see how we can spin up a test like
> this.
>
> Best
> Lou
>
> On May 23, 2018 4:25:15 PM EDT, Ben Schwartz <bemasc@google.com> wrote:
>>
>> 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.
>>>
>>
> --
> Lou Steinberg
> Managing Partner
> CTM Insights, llc
>
> Sent from my phone while not driving. Please excuse typos and brevity.
>