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

[Brian Trammell <[e-mail]>]

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