Re: [dccp] Partial checksum support in DCCP_NAT

[Gorry Fairhurst]

Michael Welzl wrote:

On Nov 23, 2009, at 4:40 PM, Phelan, Tom wrote:

[Subject changed to focus on sub-thread]

Hi Michael,

I've been thinking about a slight variation of option 3 below for
dealing with partial checksums.  Note that the intent of option 3 was
_not_ IP/UDP/UDP-Lite/DCCP as was mentioned in another thread.  That
just creates a turtles-all-the-way-down problem -- you still have the
top-level UDP checksum to work around.  The intent of option 3 is to

I understood that "defining UDP-Lite-in-UDP" can't mean
just to put it into UDP, without playing any additional tricks.
>
I thought that this trick might be to use a checksum of
zero in UDP, and include the UDP header in the UDP-Lite
checksum ... but then there's the NAT problem again, of
course, if the ports are included. Sigh...

Yes that is the NAT problem, unless we do some different processing of 
the inner checksum (see other thread). It's also not IPv6-friendly.


make UDP-Lite changes to UDP.  Basically, just redefine the UDP length
field to the semantics of the checksum coverage field in UDP-Lite.

The variation I'm thinking of is to say this -- when a UDP port is
offering the DCCP_NAT service, the length field is redefined to checksum
coverage.  To use DCCP partial checksum, set the (redefined) length
field to the portion of the datagram that needs protection, as
negotiated via the DCCP Partial Checksum feature.  This might get around
the giant can of worms that redefining the length field everywhere would
open.

So what you say is "for the following port numbers, UDP becomes
UDP lite". Maybe feasible, but architecturally ugly, of course...
I don't know how far we can stretch this sort of ugliness for the
sake of deployability - given the current lack thereof, my tendency
is to agree to ugly solutions, just to make things happen.
>
It is feasible. It is not what the IETF wanted to standardise though 
when UDP-Lite was on the table.


I'm not sure what setting the length field to less than the total packet
size would do to existing end system and NAT implementations.  Looking
at the Linux code, UDP and UDP-Lite are integrated, so it doesn't barf
on UDP length less than packet length, but it looks like you can't use
the socket option to accept less checksum coverage unless it's a
UDP-Lite socket.

But I don't think it matters if end systems and NATs need to be upgraded
to support this, since links already need to be upgraded to understand
partial checksums.

Opinions?

I'm all for it (but I say "yuck!").

I'd say it does matter if you need NATs to be upgraded to traverse them 
when using DCCP. If we're going to update them, why not require them to 
implement the native DCCP transport?

Cheers,
Michael


I can see why we want to allow endpoints to enable partial coverage in 
the DCCP datagrams that they send - because I want to be able to run 
DCCP application "x" that expects partial coverage to be available.

I'm less clear that we should be creating some complicated approach that 
will allow systems within the network to partition the packet headers 
and payload to provide partial coverage in the network links. Do you 
expect a router in the Internet to figure out that this is a 
UDP-tunneled DCCP packet which uses this feature, and has set coverage 
"y" and then compute "y" by accounting for the various preceding headers 
before it forwards the encapsulated packet over a (radio) link?

Gorry