The purpose of the IP address in the UDP transport checksum hash is to
make sure the packet is delivered to the correct endpoint.
If we layer DCCP on UDP, and traverse a NAT that changes the IP
addresses this would be update the outer UDP Cksum, but not an inner
cksum (in this case the DCCP one).
We don't however have to use the IP address in the pseudoheader of DCCP
in this case to get the required protection for DCCP: It's quite OK in
my mind to allow the endpoint to use any (unique-ish) identifier that
both ends know in this hash - so if we were encapsulating DCCP in UDP,
both ends could choose not to use the IP addresses in the DCCP
checksum, but choose some other identifier and let both ends know (e.g.
exchanged in the tunnel handshake) - this is a little HIP-like.
Since SCTP has it's own way of performing these checks, we would anyway
need to do something different for DCCP.
Gorry
Ian McDonald wrote:
Writing a very quick reply as at work and not so much time left these days.
The primary problem I found when testing on DCCP over Internet to
Arnaldo in Brazil was that NAT would rewrite the IP address which
would make the checksum wrong. Firewalls/NAT know about TCP/UDP and
rewrite checksums. The checksum for DCCP encapsulated needs to be
protected or implemented in a manner that survives UDP header
rewrites.
Your emails may well cover this but as said just skim reading at work
and just thought I'd mention our implementation experience...
2009/11/23 Phelan, Tom <tphelan@xxxxxxxxxxxx>:
[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
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.
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?
Tom P.
-----Original Message-----
From: Michael Welzl [mailto:michawe@xxxxxxxxxx]
Sent: Friday, November 20, 2009 11:59 AM
To: Phelan, Tom
Cc: gorry@xxxxxxxxxxxxxx; DCCP working group
Subject: Re: Soliciting input on UDP encapsulation for DCCP
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 :-).
Haha, I love that idea!
But seriously, I do, it's a good one I think!
Cheers,
Michael
