On 10/9/10 4:58 AM, L.Wood@xxxxxxxxxxxx wrote:
This is pretty fundamental to Internet transport protocol design.
Agreed. But that doesn't make it automatically correct in all situations.
If the net were still end-to-end, we wouldn't even be talking about this
(well, we might because of badly configured firewalls, but that's a
different issue).
We do, because turning up at the wrong node and handing corrupt data
up the stack becomes much more likely if the checksum and its demultiplexing
check are turned off.
And, of course, having a bit saying 'checksum off' is akin to
special-casing a zero-value checksum. Interesting things happen if an
error flips that bit.
I don't want *no* checksum. I just don't want us trying to force the
checksum outside of DCCP.
I was thinking the bit/option/case/version would say "checksum without
pseudoheader" rather than "checksum off". That way you still get a
checksum over (at least) all the fields in the DCCP generic header.
So, in order to demultiplex incorrectly, you would have to have the IP
layer hand you a packet from the wrong IP addresses (most likely of the
problems), flip the "checksum without pseudoheader" bit, get an error
that flips the source and dest ports to your values, get an error that
puts a sequence number in the correct place, and then adjusts the
checksum to the correct value.
I don't find that scenario very likely.
I find it more likely that some NAT/Router dumps a UDP checksum and
prevents DCCP from working at all while some other crappy protocol blows
through on UDP just fine. If we're going to *demand* a checksum (as Tom
has said he is committed to doing and I'm not actually opposed to that),
it should be in what DCCP controls, not what it doesn't.
This is effectively what the encap is doing, just in an implicit
mechanism rather than explicitly. And then forcing the UDP layer to
checksum the *entire* packet to protect itself, even if we have told
DCCP that we only want CsCov == 1 (No application payload coverage).
Variable checksum coverage is a lost cause.
Really? Must be nice to always be plugged into the mains ...
However, even if that is true, it doesn't really change my point about
DCCP is the only thing that should make demands/answer demands in its
own protocol.
DCCP demanding that UDP require checksums is like demanding that NAT go
away. Demanding doesn't make it so.
I'm still concerned about this through multiple NAT layers, but I need
to think about that a little more.
Thinking about specific scenarios is what helps me. I'm thinking about:
Standard NAT configurations (everybody thinks of these):
A(DCCPencap) -> NAT1 -> Net -> B(DCCPencap)
A(DCCPencap) -> NAT1 -> Net -> NAT3 -> B(DCCPencap)
Wireless-like configurations (normally, if you can survive 2 NATs, you
can survive 3 or more NATs. Quite often, people forget about these):
A(DCCPencap) -> NAT1 -> NAT2 -> Net -> NAT3 -> B(DCCPencap)
A(DCCPencap) -> NAT1 -> NAT2 -> Net -> NAT3 -> NAT4 -> B(DCCPencap)
Aggregator-like configurations:
A(DCCP) -> Router/NATA(encap) -> NAT1 -> Net
-> NAT3 -> NAT4 -> B(DCCP)(encap?)
And, from my point of view, all of these are running on batteries. So,
CPU speed doesn't matter, but total energy consumed (total work done
over time) does.
I'm most interested in the Aggregator-like configurations for selfish
reasons. Router/NATA(encap) is a particular pain-point. I control A,
and RouterNATA(encap). I have no control over NAT1, Net, NAT3, and
NAT4. I have user-only privileges on B.
And I *know* that NAT1 dumps UDP checksums. So, yes, I have reasons
behind this objection. ;)
-a
