Hi Pascal,. > What do you think?
I think you almost read my mind :-). When I wrote the proposed new text that you responded to, I was thinking about that sort of implementation issue and dithering between SHOULD and MUST for the integrity protection overlap. I decided to go with MUST to see what would happen ;-). I think I can live with a SHOULD for the overlap as sufficient warning to implementers, perhaps backed up with another sentence or two stating that completely unprotected data in device memory is a bad idea. I would definitely like to hear at least Lars's opinion on this, as he's more of an expert and is holding a Discuss on this topic. Thanks, --David > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:[email protected]] > Sent: Monday, January 24, 2011 10:47 AM > To: Black, David; [email protected]; [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) > > Hi David: > > For the sake of other readers, the flow we are talking about is when a device > in the LLN sends a > compressed packet with a destination in the Internet. The forwarder that > routes a packet onto > uncompressed space has to recompute the checksum that was elided. The > question is whether it can > recompute something different than was intended and what happens if so. > > I understand that an integrity check overlapping is better than having at > some point unprotected data > in memory. I certainly would prefer it that way. Sadly, that is often > impractical. The protection over > the Low Power Network(LLN) will be at commonly L2, and might be multiple > hop. In that case, the > checksum is elided, and then the L2 MIC is computed. If some bug happens > between the 2, then the UDP > checksum won't help figuring it out. So we're not 100 % covered; yet: > > - we are talking about packets being misdirected, that is the error takes > place in either the address > or the port. If the packet is not misdirected, then the existing MUST ensure > that the receiver has a > protection in place. > - we are talking about a software bug, not a transmission issue. The checksum > offers limited > protection against bugs and can't be expected to be the solution to all bugs > in the universe. > - A 2 bytes checksum is not so strong a protection anyway. An error might > still fall though in any UDP > packet today in the Internet. > > I'd be glad to add some words to recommend something about overlapping on top > of my original text, but > if we MUST it, the I'm afraid that we'll prevent in practice the packets from > being forwarding onto > the internet until the checksum 0 question is solved at 6MAN. > > What do you think? > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Monday, January 24, 2011 4:20 PM > > To: Pascal Thubert (pthubert); [email protected]; [email protected]; gen- > > [email protected] > > Cc: [email protected]; [email protected]; > > [email protected] > > Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with > > DISCUSS) > > > > Hi Pascal, > > > > I'd like to add some text on overlapping integrity protection. I also > > don't like > > "MAY not" (it's bad standardese, IMHO, e.g., MAY NOT was not defined in > > RFC 2119). The new text (with a few more edits) would be: > > > > If a forwarding node that compresses a packet cannot > > unambiguously derive such authorization, then that node > > MUST NOT elide the UDP checksum when performing 6LoWPAN > > compression. The forwarding node MUST verify the UDP > > checksum in the packet before it is elided, and MUST > > ensure that the other integrity check is in place before > > verifying and eliding the checksum. > > > > If an incoming compressed packet has the C bit set, then > > a forwarding node MAY infer authorization for that packet > > if the recomputed checksum is computed on data that was > > integrity-protected via other means across the links > > over which the checksum was elided. A forwarding node > > MUST NOT infer authorization if the node cannot unambiguously > > determine the presence of this integrity protection across > > the links over which the checksum was elided. > > > > 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 > > RFC 768, RFC 2460. After placing that checksum, the forwarding > > node MUST either verify the other integrity check or ensure that > > the other integrity check will be verified by a downstream node. > > > > Does that work? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) [mailto:[email protected]] > > > Sent: Friday, January 21, 2011 6:24 AM > > > To: Black, David; [email protected]; [email protected]; > > > [email protected] > > > Cc: [email protected]; > > > [email protected] > > > Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with > > > DISCUSS) > > > > > > Hi David > > > > > > Thanks a lot for this; the text for the forwarding node becomes: > > > > > > A forwarding node that compresses a packet that > > > cannot unambiguously derive such authorization MUST NOT > > > elide the UDP checksum when performing 6LoWPAN > > > compression. The forwarding node MUST verify the UDP > > > checksum in the packet before it is elided. > > > > > > A forwarding node MAY only infer authorization from an > > > incoming compressed packet if the C bit is set and > > > the recomputed checksum is computed on data that > > > was integrity-protected via other means > > > across the links over which the checksum was elided. > > > > > > 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 > > > RFC 768, RFC 2460. > > > > > > > > > This looks a lot better to me now. What do others think? > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] > > > > Sent: Thursday, January 20, 2011 3:06 AM > > > > To: Pascal Thubert (pthubert); [email protected]; [email protected]; > > > > gen- [email protected] > > > > Cc: [email protected]; > > > > [email protected]; > > > > [email protected] > > > > Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: > > > > (with DISCUSS) > > > > > > > > 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:[email protected]] > > > > > Sent: Tuesday, January 18, 2011 1:42 PM > > > > > To: Lars Eggert; The IESG; Black, David; [email protected] > > > > > Cc: [email protected]; > > > > > [email protected] > > > > > 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:[email protected]] > > > > > > Sent: Tuesday, January 18, 2011 8:57 AM > > > > > > To: The IESG > > > > > > Cc: [email protected]; > > > > > >[email protected] > > > > > >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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
