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

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.