Re: [tae] [tsv-area] Transport negotiation

On Dec 10, 2008, at 09:46, Stuart Cheshire wrote:
> On 9 Dec, 2008, at 19:01, james woodyatt wrote:
>
>> From where I stand, i.e. smack in the middle of your transport- 
>> aware packet-forwarding plane
>
> Why do we want a transport-aware packet-forwarding plane?
> The primary reason NAT gateways need [...]

I'm not talking about NAT gateways, especially given that I'm not sure  
I believe that NAT66 will require port multiplexing (though, I think  
it might).  I'm only talking about stateful filtering IPv6 routers.

Do we *not* want stateful filtering routers anymore?  Please please  
please... someone tell my managers and marketing people!  I want to  
believe.  I really do.  Would you like to see my scars again?  I could  
post the GIFs.  (NSFW)

> Layering new transport protocols over UDP is not a hack. It's  
> actually the right architecture AND (because of that) it also  
> happens to work though NAT gateways too.

I'm not in agreement with that.  I still think "layering new  
transports on UDP" is a kludge.  There's a lot of "transportly stuff"  
that needs to be negotiated on a node-to-node basis, and only  
sometimes (not always) on a user-endpoint-to-user-endpoint basis, e.g.  
congestion avoidance, mobility, etc.

I'm starting to come around to liking the idea of a toolkit of  
combinatory extension headers the more I mull over Joe's earlier  
comments.  To that end, I regard the UDP header as a conflation of two  
unrelated concepts: A) service multiplexing on node-to-node  
associations and B) datagram payload integrity checking.  Also, while  
I think UDP does a passing job on the former, it does a really lousy  
job on the latter, and I'd rather see those bytes used for extension  
header chaining than for checksum and length.

Alas, we have stateful filtering routers today (I have several on my  
desk right now!) and these are only aware of the transport protocols  
in existence presently (minus SCTP and DCCP).  One of them is UDP, but  
it's not the *only* available option for traversing filters.  I don't  
think it's the best one, either.  There are too many optional  
misbehaviors of stateful filtering routers with regard to UDP  
forwarding to make it optimally useful as a foundation for new  
transports.

In my view, if we're looking for ways to make new IPv6 transports  
capable of traversing stateful filters, we should instead consider  
layering them over IPsec AH or ESP, each of which is treated today  
under much more sensible rules: either they pass through filters  
unmolested or they get through not at all.  I like that much better  
than the crazy weirdness you get with UDP filtering, where passing in  
one direction between endpoint A and endpoint B is no guarantee that  
any related communications will pass through the filter in the other  
direction or even between either endpoints A and B and another  
endpoint C.

Sadly, I'm not sure we really want to be looking for ways to make  
transports capable of traversing stateful filters.  I think IETF  
enjoys finding new and interesting ways for routers to decide when not  
to forward as a matter of network policy.  I wish to be proven wrong  
about that, but I doubt it will happen.  In that light, I think the  
combinatory extension headers idea has a lot of merit.

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae