Re: [Spud] Putting Network-Layer Information in the Network Layer

[Brian Trammell <[e-mail]>]

> On 10 Jul 2015, at 18:19, Tom Herbert <[e-mail]> wrote:
> 
>> Coming back to the layering question:
>> 
>> It does seem to me that what we're (the we that wrote the two documents starting this thread) trying to do is explicitly reinforce the boundary between the network layer and the transport layer, where this is defined as "things the path needs to see versus things only endpoints need to see". Asking nicely (i.e., publishing RFCs) did not work in this case: the transport ports are de facto part of the network layer now, and short of blowing the Internet up and starting over I can't see a way to get them back. So now we are left with enforcing the boundary cryptographically, leaving some space in the "new network layer" (in this case, IP + UDP (for ports) + SPUD) for those things now commonly done within the network.
>> 
> This "new network layer" breaks down at fragmentation.

One can argue (indeed, I do) that in-network fragmentation is essentially a deprecated feature of the network layer. The current version of IP doesn't support it, and AFAICT avoiding fragmentation is current practice in modern transport protocol design.

> Only the first
> fragment carries port numbers and the embedded network layer
> information in the payload. Other fragments will carry neither, but
> still can carry IP options, DSCP, TTL, ECN marking, flow labels in
> IPv6.
> 
> An alternate possibility would be to embed IP options within UDP. So a
> packet might look like IP-UDP-IP options-payload.

This is an intriguing possibility, if there is an advantage to reusing IP options handling code.

> This allows us to
> use native options (say in our data center where we can control
> things), but maybe to use embedded IP options in UDP on paths in the
> Internet where we see options are being dropped. SFC-in-UDP
> (https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00)
> proposes a similar model,

It looks a lot like innerspace (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too.

> although I don't believe they allow
> middleboxes to modify or to be regularly looking the headers.

What does "allow" mean in this context?

>> If we can do this in the _current_ network layer (IPv6 (with options) with some alternate way to handle NAT + DTLS, or we find a portal to an alternate universe where end-to-end IPsec is widely deployable and manageable), then great, let's do that. I'm pessimistic enough to believe that that hasn't been a realistic prospect at any time during this century, though.
>> 
> I don't understand what the issue is with crypto here.

We want the transport protocol headers to be encrypted, in order to enforce the network/transport layer boundary. (That's what I would mean by "allow". :) )

> SSL/TLS are widely deployed with use of NAT,

...which allows mucking about in the transport layer, and using *all* transport layer metadata to track/fingerprint/etc.

> and we are certainly using encrypted
> tunnels over the Internet.

My understanding of most deployed encrypted tunnels which (also) use tunnel-mode IPsec is that it has a fallback to a UDP encap to handle NAT, but I could be mistaken there.

Cheers,

Brian