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

[Tom Herbert <[e-mail]>]

> 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. 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 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, although I don't believe they allow
middleboxes to modify or to be regularly looking the headers.

> 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. SSL/TLS are
widely deployed with use of NAT, and we are certainly using encrypted
tunnels over the Internet.

Tom

> Cheers,
>
> Brian
>
>> Joe
>>
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
>
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>