Subject: Re: [Spud] Possible WG-forming follow-on to SPUD BoF

From: Brian Trammell <[email-masked]>
Date: Wed, 1 Jun 2016 09:04:16 +0200

hi Tom,

snipping a bunch of the message; replies inline...

>> Unbreaking firewalls in the face of transport encryption is a necessary first step. What you do after that is a separate question.
>> 
> Brian,
> 
> Like Szilveszter mentions the choice to encrypt must be up to the
> application or TP. Applications should not have to ask for permission
> from the network to use encryption,

Of course not.

> nor can deployment of encryption
> be gated on middleboxes being updated with PLUS (it's unrealistic to
> think we are going to wait N years for PLUS deployment in middleboxes
> before starting to encrypt transport headers).

And of course not. I'm having a hard time seeing where anyone has proposed otherwise in this thread.

Since the protocol bounded by draft-trammell-spud-req relies on the superstrate to provide secrets for integrity protection, we presume encryption of the superstrate by default. Indeed, one could envision PLUS' selective exposure and transport state exposure mechanisms being implemented as extensions to DTLS, since it already provides most of the pieces we'd need.

The difficulty we see in PLUS is what happens when an application/transport chooses *not* to encrypt; when the superstrate doesn't provide exchange of secrets, you get no integrity protection for the PLUS information either. Indeed, in this case the *only* benefit PLUS provides is a common framing and data model for information exposed to middleboxes, which as you note is rather useless in the initial phases of deployment. And this might be an acceptable corner case anyway: a decision not to encrypt can at this point be taken as an explicit statement that the endpoint is unconcerned about its packets being thoroughly inspected and mangled by the network.

> As for "Unbreaking firewalls in the face of transport encryption is a
> necessary first step" can you elaborate exactly how firewalls are
> broken in this regard? I don't see a good description of this problem
> in RFC7663 and your UDP data as well as the fact that QUIC is
> currently being deployed don't seem to be illustrating a widespread
> reachability issue using UDP in the Internet.

Two issues: blocking and state maintenance.

On the former: QUIC falls back to TCP 6%-9% of the time; our RIPE Atlas numbers, which undercount enterprise access networks, point to 3.3% to 3.6% of measured networks blocking outbound UDP (on ports other than 53). These are acceptable numbers if you always have a fallback (which QUIC does built-in, since H2 runs acceptably over TCP, and where something like TAPS comes in for other applications). But it seems to me we can do better than that. Providing firewall vendors and administrators with an incentive to unblock would help here, and exposure of state information so that new transports over UDP can be managed like TCP is, I think, a good one.

On the latter: have a look at the spectrum of NAT timeouts between TCP and UDP in the paper Lars sent to maprg (in the "Is UDP a trash heap?" thread): population median (and mode) UDP timeout for tested devices on flows that look like QUIC was 3 minutes (figures 4,5), versus 60 minutes for TCP (figure 6). See also Jim's slide on NAT unbinding from tsvarea in Vancouver (https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf): this test is, I believe, roughly equivalent to the one shown in figure 3 in Lars' paper, with equivalent results: median is about 1.5 min. Both datasets suggest a simple heuristic for keepalives: send a useless packet every thirty seconds if you care about keeping the connection up and don't have anything to say.

The reason these timeouts are longer for TCP is that TCP exposes state maintenance information to the path. If there is a common mechanism for UDP-based transport protocols for exposing equivalent information, with an equivalent level of trust as we can place in TCP flags (formally zero), then the timeouts can tend over time to be longer, reducing the need for unproductive keepalive traffic.

Cheers,

Brian

> Thanks,
> Tom
> 
>> Cheers,
>> 
>> Brian
>> 
>> _______________________________________________
>> Spud mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spud
>> 
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Szilveszter Nadas <[email-masked]>
Date: Wed, 1 Jun 2016 16:02:25 +0000

Hi Brian,

Thanks. Some further comments inside.

Cheers,
Sz.

> > -"allow applications and transport protocols to explicitly provide limited
> information in cleartext to devices on path" vs. "sending endpoint", "receiving
> endpoints". The terminology is not 100% clear to me. What is the difference
> between "applications and transport protocols" and "endpoints" here?
> 
> Some information to be exposed (e.g. expected constant data rate) might
> come from the application layer, and some information (e.g. transport
> reordering tolerance, measurement headers that look something like those in
> the PDM DO header the IPPM WG is currently working on) comes from the
> transport layer. In this case, the transport should always allow the application
> to know what is being sent, and to have control over whether it is sent, but
> may keep the application from changing the values exposed. This is up to the
> transport/app API.

I see. And now I can ask my real question: is it intentional to limit declarations to "applications" and "transport protocols" in the "endpoint"? What about other entities like a middleware? Or an OS level function which acts on behalf of the user's interest vs. the applications being maybe too selfish? 

(I refer to Fig. 1. of https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf  )

> > -What do we gain by limited vocabulary ("limited information")? Is not any
> set of declarations too much for some users/countries/whatever and too few
> for others? Is not it forcing the WG participant's ethics by protocol design?
> 
> A few things; mostly, we gain some control at the process level against
> subversion of endpoint control.

Please elaborate it more. I do not get it.

> > -There was a comment "PLUS header would make this behavior visible to
> *everyone* on the network. That alone is IMO a reason it wouldn't be
> deployed in this way". I agree with this, PLUS would/shall make every non-e2e
> conversation as explicit as possible. Is that protection enough? Is it possible to
> make this explicitness as transparent as possible? Is it necessary to have further
> protection as e.g. limited vocabulary?
> 
> WRT "limited vocabulary", the thing it's hard to defend against here is
> someone defining their own declaration, the meaning of which is secret and
> the name obfuscated. If I see that an app is radiating something to the path
> over PLUS, but I can't understand it, well, I do know that app may be up to no
> good, but I don't know what *kind* of no good. It's not clear to me whether
> that's enough to qualify as "transparent".

Another way to implement it in the long run is to delegate the task of declarations to a trusted piece of software (again like in the marnew paper). Then this trusted piece could decide whether to send any data, and to encrypt it also.

Of course it is hard to prevent steganography in both cases.

> I'll note that if there was a "app-to-path-cleartext-supercookie" information
> element in PLUS (which I don't think would be a useful one to have, nor would
> it meet any goal we have), it would *not* be removable by a middlebox, since
> it would be integrity protected end-to-end. A supercookie mitigation box in
> PLUS would have to notice the existence of the supercookie, drop the packet,
> and send back a direct feedback message that said "I'm sorry, I don't permit
> supercookies, please reset the superstrate transport session and try again
> without the supercookie."

This makes inserting any middlebox declaration to the packet impossible. That was discussed before, is it not in scope anymore? 

> > -The charter still says "goal is to enable the deployment of new, encrypted
> transport protocols". I think that whether to encrypt or not is the decision of
> the TP, and while I agree that encryption really helps there by avoiding further
> ossification, I think it shall not be the scope/decision of PLUS.
> 
> Yes, but: in order for integrity protection of declared information to work,
> PLUS needs a mechanism to share a secret between endpoints, so it either
> needs its own keying or it needs to borrow a key generated from the
> superstrate's session key. And if we are to meet the requirement to prevent
> future ossification of the transport layer (or rather, to re-ossify around the
> path layer provided by PLUS), then we need to encrypt the transport layer
> headers. So IMO this is very much in scope.

This definitely makes sense. I am not sure whether this is the best compromise though. 

The requirement is to be able to provide some kind of integrity protection and encryption capabilities in PLUS, in a lightweight way. Reusing TP security context is definitely a solution, there might be issues with that, not sure.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Jun 2016 09:29:37 -0700

Brian,

>From the proposed charter:

"In order to support more ubiquitous deployment of encryption, and the
encryption of transport headers to allow deployment of new transport
protocols, explicit in-band signaling must be added to the stack."

It's the word "must" here that is problematic, that implies a
requirement for deployment of encryption and new transport protocols.

I think there are two mostly orthogonal goals being expressed in the
proposal: 1) Encryption of transport layers 2) An extensible signaling
mechanism between hosts and networks.

There seems to be general agreement that encrypting the transport
layer is a solution to protocol ossification and provides better
security for users. But implementing this is non-trivial and will
require new specifications. We can't just encapsulate TCP, SCTP, etc.
packets within UDP and expect it to work-- the presence of NAT makes
this a hard problem. For instance, I already posted
draft-herbert-transports-over-udp which generally attempts to describe
host to encapsulate existing protocols within UDP (encapsulation of
TCP is detailed).

So my question per the proposed WG is:  are development and
specifications to encapsulate and encrypt specific existing transport
protocols within UDP is within the scope? For instance would a first
milestone be an RFC that describes how to encapsulate TCP within UDP
(or within DTLS)?

Thanks,
Tom