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

From: "Brzozowski, John Jason" <[email-masked]>
Date: Tue, 22 May 2018 15:00:19 -0400

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: "[email-masked]" <[email-masked]>

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 23 May 2018 09:54:44 -0400

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.
>     has been successfully submitted by John Jason Brzozowski and posted
to the

submission

---

From: Lou Steinberg <[email-masked]>
Date: Wed, 23 May 2018 15:24:29 -0400

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.

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.  Can the validator send a misdirected request should this happen?  

Appreciate your help!
Lou

On May 23, 2018 9:54:44 AM EDT, Ben Schwartz <[email-masked]> wrote:
>>        Current methods for managing traffic through content
>inspection
>tend
>>

-- 
Lou Steinberg 
Managing Partner 
CTM Insights, llc

Sent from my phone while not driving. Please excuse typos and brevity.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 23 May 2018 16:25:15 -0400

On Wed, May 23, 2018 at 3:24 PM Lou Steinberg <[email-masked]> 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.

>> > 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
>> https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-01 to
>> eliminate the need for our redirect mechanism, but were concerned about
>> treatment.

---

From: Lou Steinberg <[email-masked]>
Date: Wed, 23 May 2018 19:59:49 -0400

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 <[email-masked]> wrote:
>>> >     A new version of I-D,
>>> >        to process all sessions similarly.  Internet traffic
>examples
>>> like
>>> >
>>> >        number of scrubbing centers, which create both natural
>choke
>>> points
>>> >
>>> >        become overloaded.  Similar issues exist with email SPAM
>and
>>> malware
>>> >
>>> >        temporarily confer trust on sources, and for trusted
>traffic to
>>> be
>>> >
>>> >     until the htmlized version and diff are available at
>tools.ietf.org
>>> .
>>> >
>>> >
>>> >
>>> >     The IETF Secretariat
>>> >
>>> >
>>> >
>>> >
>>>
>>
>> --
>> Lou Steinberg
>> Managing Partner
>> CTM Insights, llc
>>

-- 
Lou Steinberg 
Managing Partner 
CTM Insights, llc

---

From: Natasha Carroll <[email-masked]>
Date: Sat, 26 May 2018 05:46:30 +1000

On Sat, May 26, 2018, 5:26 AM Lou Steinberg <[email-masked]> wrote:

>>> 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
>> 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.
>>
>
>>
>> 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
>>>
>>>
>>>
>>>> > 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
>>>> > 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
>>>> >     has been successfully submitted by John Jason Brzozowski and
>>>> posted to the
>>>> >
>>>> >     IETF repository.
>>>> >
>>>> >
>>>> >
>>>> inspection tend
>>>> tools.ietf.org.

---

From: Lou Steinberg <[email-masked]>
Date: Thu, 31 May 2018 10:13:23 -0400

Hi Ben (et al) -

Just an update.  Still working on getting our test up and running, just 
need to fight through some issues we ran into with our proxy as an alt 
service.  Browser and origin seem to be doing what we need.

While we have a punch list of things to check, the main one is whether 
our transparent proxy (alt service) needs to host a certificate for the 
origin.  I suspect we will be able to get the proxy to forward one from 
the origin, if necessary, but need to be sure.

The reason for my concern about the alt service having an origin cert is 
that RFC 7838 says:
>     Importantly, this includes its security context; in particular, when
>     TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] is used to authenticate, the alternative service will
>     need to present a certificate for the origin's host name, not that of
>     the alternative.
Assuming we make this work, we will have another use-case for SNI alt 
services.  Should know soon.

/lou

On 5/23/2018 7:59 PM, Lou Steinberg wrote:
>     On Wed, May 23, 2018 at 3:24 PM Lou Steinberg <[email-masked]
>     <mailto:[email-masked]>> 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.
>
>
>     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.
>
>
>     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.
>
>     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
>
>
[snip]

-- 
---
Lou Steinberg
Managing Partner
CTM Insights, llc

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 31 May 2018 10:49:59 -0400

> service.  Browser and origin seem to be doing what we need.

Great.  Feel free to contact me directly if you have non-standards-relevant
issues, to avoid unnecessary traffic on the working group list.

While we have a punch list of things to check, the main one is whether our
> transparent proxy (alt service) needs to host a certificate for the
> origin.  I suspect we will be able to get the proxy to forward one from the
> origin, if necessary, but need to be sure.
>
> Yes, this is correct.  However, if your transparent proxy acts as a TCP
bytestream forwarder, which seems consistent with your design goals, it
doesn't need to host any certificate at all.

(The SNI Alt-Svc proposal does relax this requirement somewhat: if the
client doesn't get the origin's certificate immediately, it can try again
using Secondary Certificate Authentication.  I think this is not relevant
to your use case.)

> On May 23, 2018 4:25:15 PM EDT, Ben Schwartz <[email-masked]>
> <[email-masked]> wrote:
>>