Re: [Stackevo-discuss] [Stackevo] draft-byrne-opsec-udp-advisory

[Brian Trammell <[e-mail]>]

[...and now copying the newly-created stackevo-discuss list, just created as a place for public discussion on IAB stack evolution program related topics...]

> On 24 Jul 2015, at 07:04, Ca By <[e-mail]> wrote:
> 
> On Thursday, July 23, 2015, Brian Trammell <[e-mail]> wrote:
> hi Cameron, all,

<snip>

>> Cool. So, if we assume that we can find a way to quickly and easily distinguish bad old UDP ("all" of which is reflected crap, for some high value of all) from UDP-as-layer-boundary-reinforcement -- a well-selected magic number being the most obvious way (to me) to do this statelessly.
>> 
> 
> I would simply call it udp2 with a new transport protocol number.

If we're going to do that we might as well fix other things with UDP. I see this as an excellent way forward for the second stage of this transition.

> But I imagine you want to preserve some way to blast through legacy nats, which is not a good strategic goal / constraint

It'd be nice, yes, but it's not the main concern.

On the NAT question, I'd have to see data to convince me that the proportion -- internet-wide -- of connections from end-user / that are NATted (in a way that a *new* UDP that has port numbers in the same place in the header won't make it through, which is I assume today all NAT devices). V6 takes a lot of address pressure away, true, and careful engineering of V6-enabled CPE can reduce NATting. But V6 only access connectivity to services that are V4 only itself requires NAT. So the slope points downward but I don't see NAT being an insignificant part of the deployed architecture for a long time. We want something that works tomorrow, not someday, with negligible risk to connectivity. Shiny new features that break the delivery of cat videos they promise to improve get switched off.

More important is that basically every programming environment on every internet connected platform can give applications access to UDP/17. It will take a long time for that to be the case with UDP2/144 (or whatever number this protocol would be assigned). I hope that the curve for getting kernel support for these things is faster than it was with e.g. SCTP: endpoint operating system maintenance has matured a lot in the past two decades. But it's still a long curve.

>> So, there are broadly two things I mean when I say UDP:
>> 
>> (1) Packets with a protocol identifier of 17 on them. This is what you want to filter on because most of them are crap.
>> 
>> 
> Yes
> 
>> (2) What happens when you open a SOCK_DGRAM socket. This service is basically "nonprivileged userspace raw sockets". When we're talking about making it possible to deploy new transport protocols, the "userspace" is IMO crucial here (and the "nonprivileged" equally so if you're talking about the new world where everything happens on devices where the user has no root).
>> 
>> 
> Udp2
> 
>> If we had a way to get this second thing without throwing a UDP header on it, that'd be great, but whatever it is you need port numbers on it, more because you can have multiple userspace processes on each eventual endpoint than you need to get around NAT.
> 
> 
> I am optimistic about IPv6 deployment and the removal of nats and middle boxes.

I'm far more optimistic about the former than the latter. Just because one enables the other doesn't mean that it will.

>  This is tied to LTE capacity and latency improvements outpacing middle box utility and capacity.
> I find it strange that the ietf is trying now to talk to middle boxes while they are waning. YMMV.

For my part, I see this effort as an attempt to make interactions with middleboxes *explicit* as opposed to implicit; this can happen even as more paths get more transparent, and the diagnostics enabled by this layer can accelerate this trend.

>>> > I can only think of 2 paths forward.  Remove the noise from UDP (aka, upgrade the internet to stop DRDoS [home routers with SSDP, open DNS and NTP, booter services...]) or stop assuming your UDP packets will be transported at scale (aka, the ietf needs to not load new things into UDP and accept the mess that grew out of UDP... learning from it in new transport protocols that are not transport protocol 17).
>>> 
>>> I see the use of UDP here as a transition technology: that is, something that will be deployed for the next twenty years or so. The eventual goal (at least mine) is to be able to do all of this over a new protocol. The stack looks something like this:
>> 
>>    |  transport services API (TAPS)  |
>>    +---------------------------------+
>>    | shiny new transport protocol(s) |  encrypted
>> ==========================================
>>    |   explicit cooperation layer    |  cleartext
>>    +-----------------+               |
>>    |       UDP       |               |
>>    +----------+------+---------------+
>>    |    IPv4  |           IPv6       |
>>    +----------+----------------------+
>> 
>>     ------------ time -------------->
>> 
>> > The former is impossible and outside the capabilities of anyone reading this email.
>> 
>> I'd submit that if a good-UDP / bad-UDP discriminator, as well as return routability proof and state exhaustion resistance, can be designed into future good-UDP protocols, that's a start.
> 
> But it does not solve change anything in the I-D at hand, as the I-D is tactical and operational in nature

It would, were it deployed: there would be an easy way to determine reflected crap from nearly-certainly-not-reflected not-crap. The I-D at hand is a good collection of observations about why UDP might not be appropriate here. It is not clear that generalizing these observations to the wider Internet is useful guidance in and of itself ("deprecate UDP"), though it can be input to efforts to improve the situation on UDP ("reduce reflected crap until you can deprecate UDP").

>> > The latter is inconvenient for some yet-to-be-standardized or broadly deployed technologies, and it is within the circle of influence here at the IETF to wind down UDP.
>> 
>> This is tantamount to saying the future of the Internet is over TCP, which is not a particularly useful future. The inability to get new transport protocols deployed isn't just an issue with NATs, it's an issue with the kernelspace/userspace boundary in the endpoints. This has more than NAT to do with why we failed to deploy SCTP.
>> 
> TCP is not a useful future?

TCP *alone* is not a useful future. A future where all traffic runs over TCP is a missed opportunity. Most network applications don't necessarily fit on a transport whose API was designed to make the network look like a tape drive, and wedging them into a stream API is inefficient and brittle. Loss-based TCP congestion control algorithms (basically all of the ones deployed for general use) don't play particularly nicely with link layers designed without a recognition that TCP *must* induce loss as a congestion control signal.

> From where I sit, udp is less than 5% of traffic at peak, except during attacks when it goes north of 50%.  This is why policing udp is low risk and high reward in real networks.
> 
> Put the good udp in IPSec. Better, put sctp on the wire or in IPSec. Xbox is doing this with IPv6
> 
> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf

Indeed, the diagram above looks a lot like a super-simplified version of the diagram in the IPsec RFC that says where you stick various IPv6 extension headers when using ESP, if you put the explicit cooperation stuff in hop by hop and destination options. But it's not clear to me how I would ship an app over SCTP over transport mode ESP when I'm not also the administrator *and* the vendor of the OS running on the endsystem, and it's not clear to me how I would handle keying for such a thing without a closed management framework.

So I still think we need something else here.

Cheers,

Brian