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

On 10 dec 2008, at 20:45, james woodyatt wrote:

> 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).

Yes, why would we demux on the 128 bits that are there in clear sight,  
doing it on 16 others that may or may not be present elsewhere in an  
unpredictable place makes much more sense. </sarcasm>

> I'm only talking about stateful filtering IPv6 routers.

We "need" port numbers for stateful filters today (well, in the past,  
really) because someone may be running a vulnerable service on another  
port.

However, for non-TCP, non-UDP protocols we can assume that the hosts  
running those are keeping up with the times and don't run DCCP, SCTP  
or ???P services on certain ports so we should just allow these  
protocols without looking deeper inside them. We only need the old  
crap for TCP and UDP in case someone is running Windows 98 or XP  
without a service pack, anyway.

> Do we *not* want stateful filtering routers anymore?

I don't.

> Please please please... someone tell my managers and marketing  
> people!  I want to believe.  I really do.

We had this dicussion last year in the CPE context. You said you  
couldn't sell to those people letting through ANY unsolicited packets.

> I still think "layering new transports on UDP" is a kludge.

I tend to agree but even I can be pragmatic from time to time.

But this is really a pointless discussion except when inventing new  
transports, because all the other ones except RTP already exist and  
DON'T run on top of UDP so changing this to running ove UDP requires  
new hacks. Inventing new hacks because we don't like the old hacks  
doesn't seem like a very good use of our time.

Back to the transport negotiation issue: the whole idea of specifying  
TCP vs SCTP etc in URLs is nonsense, because the whole issue is that  
we don't know whether a client can support the new protocol. Feeding a  
client a URL it won't be able to parse just pushes the problem to the  
layer where URLs are created.

IPv6 got this part right: the URLs are the same but consenting clients  
and servers can discover that they share IPv6 capability and use it  
while oblivious servers and/or clients can remain oblivious. We could  
do transport negotiation in the same way (through the DNS) although  
this requires even more DNS lookups for clients that know the new  
protocols, which isn't great especially if the new stuff is rarely used.

Another option that wasn't really possible with the IP version  
negitiation is doing the negotiation in-band through test packets or  
options. However, test packets are also problematic when they are  
common while the things they are test for are uncommon. And some  
middleboxes barf on options...

> In my view, if we're looking for ways to make new IPv6 transports  
> capable of traversing stateful filters

Isn't that backwards? Shouldn't we adapt filters to our new protocols  
rather than the other way around? Especially with IPv6, where we can  
assume that there is no ossified legacy deployment, i.e., everything  
that runs IPv6 can assumed to be at least minimally upgradable.

But if we really want this we should probably come up with a "UDP  
ultralight" which would probably be ports and payload type, with  
possibly some SYN/FIN style bits to make statefulness workable. Bonus  
credit for putting this in a fixed place in the packet. We may also  
want to forbid the payload protocols from looking at the addresses for  
their checksum.
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae