Re: Last Call: <draft-ietf-6man-udpchecksums-06.txt> (IPv6 and UDP Checksums for Tunneled Packets) to Proposed Standard

[Magnus Westerlund <[e-mail]>]

Thanks John

The editorial nits we will take care of in an update. Many of these are
new due to the significant changes, and this is in fact the first chance
to comment on them. Thus, do not feel bad for it being IETF last call.


On 2012-12-18 00:56, John William Atwood wrote:
> Comments on draft-ietf-6man-udpchecksums-06
> 
> 

> 
> Bullet 3, sub-bullet 1.  What does it mean, "the 5-tuple with a zero
> checksum enabled"?  I _believe_ that you are trying to indicate that the
> delivery mechanism has a data structure with the 5-tuple and an
> indication that this context has enabled zero checksums and that the
> incoming packet has a zero checksum and that the 5-tuple matches the one
> in the data structure.  I am not sure what to suggest, but the potential
> for erroneous coding seems high to me.

A packet matching an existing context which has zero checksum enables
receives a packet not intended for this context, but due to some
corruption event of the address information it arrives in this context.

You are correct that there is basically nothing you can do against this
unless you actually have a checksum to detect the corruption. In the
case of a tunneling protocol is is also likely that the tunneling
protocol is so thin, i.e. no or few headers that using them to detect
that this packet is not intended for this context is difficult.
Correctly I think this is something you have to accept when using
non-checksum protected receivers. It can occur but more than 10000 times
as common when using Internet checksums.

> 
> Bullet 3, sub-bullet 1.  If a payload is matched to the wrong context,
> why is it delivered as if it were correct?  Is there something that I am
> missing here?

The receiving context interprets the packet according to the rules of
the existing context. If nothing in this processing is tripped then what
was in that packet will be used as a valid packet in that context.

To be clear here, we are describing the cases using full knowledge of
what occurs, but the receiving node can't see the difference between a
corrupted zero-checksummed packet and a correct one. That is what it
requires the checksum to do.

> 
> Page 9, replacement text, para 1, lines 6-9.  This sentence has no
> subject.  I suggest the following text:
> 
> "As an alternative usage for some protocols, such as protocols that use
> UDP as a tunnel encapsulation, the zero-checksum mode MAY be enabled for
> specific sets of ports."
> 
> I note, however, that the phrase "zero-checksum mode" is probably not
> defined anywhere in RFC2460, so it may be necessary to be more specific
> here: "a packet with a zero checksum MAY be allowed for specific sets of
> ports."

The zero-checksum mode is intended to be defined by this text, where the
zero-checksum mode is defined by the rules in draft-ietf-6man-udpzero. I
have some difficulties determining what changes would improve this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------