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

[Tom Herbert <[e-mail]>]

On Wed, Jun 1, 2016 at 12:04 AM, Brian Trammell <[e-mail]> wrote:
> 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.
>
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

> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>>>
>>
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
>