Hi Gorry, OK, I'll try to think up something to replace DCCP_RAW :-). Obviously that name came from "raw" sockets, which would be one way to implement it. DCCP_Native is too much like DCCP_NAT so might cause confusion. Maybe DCCP_STD? That's supposed to be DCCP Standard, not DCCP Sexually Transmitted Disease :-). As far as the partial checksum feature -- UDP-Lite would be perfect, except that it uses its own IP protocol number and therefore has the same NAT problems as DCCP, so that was out. It is my understanding that use of zero checksum with UDP is somewhat common (at least in IPv4, don't really know about its use in IPv6). Although in my opinion it does seem risky to do this, it seemed to be the only way to get support for DCCP's partial checksum feature with UDP encapsulation. Since this does open some reasonable issues, maybe we should rethink it a bit. I see three options at the moment: 1) Accept the issues with what we have already (well, add UDP Length to the checksum). 2) Eliminate support for partial checksums in DCCP_NAT. 3) Define UDP-Lite-in-UDP, then DCCP partial checksum becomes use UDP-Lite and ensure that the DCCP header is covered. I can imagine that this would open quite the can of worms :-). Opinions, anyone? Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Friday, November 20, 2009 11:16 AM > To: Phelan, Tom; DCCP working group > Subject: Re: Soliciting input on UDP encapsulation for DCCP > > Tom, > > A couple of comments: > > 1) I think DCCP_RAW is still a very odd turn of phrase for what the IETF > would call a native transport. This seems to imply someone in user-land > trying to use a "raw" IP socket, or something. Please can we call this > DCCP_Native or just "native DCCP" or "DCCP transport". > > 2) I agree with others on the checksum concerns. If you use UDP with no > checksum, there is no port validation - this vulnerability needs to be > described in the security considerations section. I'd argue particularly > a pain, since one of the reasons for using this mode - perhaps the main > reason - is that you want a link-layer coverage different to the entire > packet for error-tolerant apps. In this scenario corruption of ports is > not improbable, although you could argue this was not hugely important > if the content is error tolerant - still I'd argue there was a > difference - getting someone else speech/video samples is different to > distortion of your own stream. > > 3) Does UDP with no checksum encaps actually make any sense? If you want > to be corruption tolerant you should use a link-layer that knows about > transports that allow this. UDP-Lite would be sensible if you wanted to > test the mode - but has the same deployment issues as DCCP. > > I recall asking this before, just before the draft went dormant. > > Finally, please remember to make a note this mode is not valid for IPv6:-) > > Best wishes, > > Gorry > >
