I think the new text is much better. I think the open question on checksum recomputation is whether there are enough "MUST" and "MUST NOT" requirements in the new text to sufficiently ensure that any recomputed checksum is computed on data that was integrity-protected via other means across the links over which the checksum was elided. If so, the result is concatenated protection, where the "other means" spans integrity protection of the packet across the gap created by eliding the checksum. This approach requires assurance that the integrity domains overlap - an important example is that if the other integrity check is applied in the same node that elides the UDP checksum, that node MUST be implemented so that there's no gap in the node between checking the UDP checksum and application of the other integrity check where an internal corruption would be unprotected. Rechecking the received UDP checksum after applying the other integrity check is among the ways to achieve this).
Thanks, --David > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] > Sent: Tuesday, January 18, 2011 1:42 PM > To: Lars Eggert; The IESG; Black, David; gen-art@ietf.org > Cc: 6lowpan-cha...@tools.ietf.org; draft-ietf-6lowpan...@tools.ietf.org > Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) > > Hi Lars and David: > > After the first round, the text would now look like this: > > " > 4.3.2. Compressing UDP checksum > > The UDP checksum operation is mandatory with IPv6 [RFC2460] for all > packets. For that reason [RFC4944] disallows the compression of the > UDP checksum. > > With this specification, a compressor in the source transport > endpoint MAY elide the UDP checksum if it is authorized by the Upper > Layer. The compressor MUST NOT set the C bit unless it has received > such authorization. The Upper Layer MAY only provide the > authorization in the following cases: > > Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- > fieldbus by tunneling existing field protocols over UDP. If the > tunneled PDU possesses its own addressing, security and integrity > check, the tunneling mechanism MAY authorize to elide the UDP > checksum in order to save on the encapsulation overhead. > Upper Layer Message Integrity Check: In this case, there is some > other form of integrity check in the UDP payload that covers at > least the same information as the UDP checksum (pseudo-header, > data) and has at least the same strength. > > A forwarding node MAY infer authorization from an incoming packet if > the C bit is set. A forwarding node that cannot unambiguously derive > such authorization MUST NOT elide the UDP checksum when performing > 6LoWPAN compression. The forwarding node that expands a 6LoWPAN > packet with the C bit on MUST compute the UDP checksum on behalf of > the source node and place that checksum in the restored UDP header as > specified in the incumbent standards [RFC0768], [RFC2460]. > > If a 6LoWPAN termination is also the transport endpoint and it > receives a compressed packet with the C bit set, then it MUST drop > the drop the packet unless it is explicitly authorized by the Upper > Layer to accept packets with a zero checksum on that UDP port. If it > has such authorization then it is entitled to ignore the UDP checksum > process completely. If the C bit is not set, the packet might have > been forwarded by an edge router, so this is not an indication that > the MIC is not present. If the terminating node knows that the > message integrity will be validated by the upper layer by some state > associated to the Service Access Point, it is entitled to ignore the > checksum operation as if the C bit was set. > > " > > I'm still unhappy since the text allows a middle point to recomputed the > checksum which then might be > delivered erroneously to the wrong IP or port. > This was done to ensure that a packet that flows on the Internet would 'look > right' to middle boxes > and end points. > It is probably OK for most 802.15.4 cases since L2 security is almost > always on and protects the > frames a lot better than 2 octets of checksum. > But if there's no security at work, it would probably be better to let the > packet go with a zero > checksum and add some text on authorizing that an arbitrary end point. > > What do you think? > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.egg...@nokia.com] > > Sent: Tuesday, January 18, 2011 8:57 AM > > To: The IESG > > Cc: 6lowpan-cha...@tools.ietf.org; draft-ietf-6lowpan...@tools.ietf.org > >g Subject: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) > > > > Lars Eggert has entered the following ballot position for > > draft-ietf-6lowpan-hc-13: Discuss > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this > > introductory > > paragraph, however.) > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [Edited to include David Black's gen-art review, since I'm already holding a > > discuss on part of the issues he has raised.] > > > > Section 4.3.2., paragraph 1: > > > The UDP checksum operation is mandatory with IPv6 [RFC2460] for all > > > packets. For that reason [RFC4944] disallows the compression of the > > > UDP checksum. > > > With this specification, a compressor in the source transport > > > endpoint MAY elide the UDP checksum if it is authorized by the Upper > > > Layer. The compressor SHOULD NOT set the C bit unless it has > > > received such authorization. The Upper Layer SHOULD only provide the > > > authorization in the following cases: > > > > DISCUSS: First, I think you want to use "MUST NOT" and "MAY only" > > here. Second, there are additional issues here (see > > draft-ietf-6man-udpzero). For example, even if there is an upper layer > > integrity check present for a given app, if the port number field gets > > corrupted and a message gets mis-delivered to an incorrect application > > (port), *that* application may not have an upper layer integrity check > > implemented to protect it. And so on. Have you run this part of the > > spec by 6MAN? > > > > Also, from David Black: > > > > > A forwarding node MAY imply authorization from an incoming packet if > > > the C bit is set. A forwarding node that cannot unambiguously derive > > > such authorization SHOULD NOT elide the UDP checksum when performing > > > 6LoWPAN compression. > > > > This needs to be a MUST NOT. > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
