Re: [dccp] Soliciting input on UDP encapsulation for DCCP

[Gorry Fairhurst]

Phelan, Tom wrote:
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 :-).

DCCP_STD would be OK, or DCCP_transport?

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,
>
Yes. RFC 5405 may help to clarify issues.

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.

My take is don't do it for v6:
http://tools.ietf.org/html/draft-fairhurst-tsvwg-6man-udpzero-00

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

I'm interested in 1 & 2. What do others think?

To me the merit of UDP-Lite in UDP is to enable UDP-Lite more widely 
with reduced functionality. I'd not advocate UDP/UDP-L/DCCP as an 
attractive proposition.

Opinions, anyone?

Tom P.

Gorry

-----Original Message-----
From: Gorry Fairhurst [mailto:go...@erg.abdn.ac.uk]
Sent: Friday, November 20, 2009 11:16 AM
To: Phelan, Tom; DCCP working group
Subject: Re: [dccp] 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