Subject: [Gen-art] Gen-ART review of draft-ietf-6lowpan-hc-13.txt

From: <[email-masked]>
Date: Mon, 17 Jan 2011 15:33:08 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6lowpan-hc-13.txt
Reviewer: David L. Black
Review Date: January 17, 2011
IESG Telechat date: January 20, 2011

Summary: This draft is on the right track, but has open issues, described in the review.

This draft is a complete redesign (in the form of new headers) of the IPv6 header compression support for IEEE 802.15.4 in order to make the result usable in practice, and hence obsoletes the old formats.  The draft reflects experience with the technology and contains a wealth of design details to obtain as much leverage as possible from compression.  While I did not go through all of the header details, the draft looks like it's in good shape and the result of careful consideration.

I have one open issue.  The draft allows UDP checksums to be omitted when there are higher level integrity checks in place, and says the following about verification that those checks are in place:

   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.

   ....

   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.

Omission of UDP checksums has a lousy track record, suggesting that both of the above should be "MUST NOT" instead of "SHOULD NOT".  There are plenty of storage "war stories" about someone who ran NFS over UDP with checksums turned off and later discovered corrupted files.

There may be something special about 802.15.4 that makes this sort of corruption less of a risk, but I strongly request that the IESG discuss whether to change both of the above "SHOULD NOT" statements to "MUST NOT" with an explanation of the significant risks to data integrity (e.g., there's a reason why RFC 2460 made the UDP checksum mandatory).

idnits 2.12.05 generated a few miscellaneous warnings, none of which require changes to the draft.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 09:57:49 +0200

> There may be something special about 802.15.4 that makes this sort of corruption less of a risk, but I strongly request that the IESG discuss whether to change both of the above "SHOULD NOT" statem…

I hit the first "SHOULD NOT" in my discuss, but I missed the second one. I'll add it.

Lars

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Jan 2011 08:44:37 +0100

Thanks  a lot, David, for your review.

Lars made a very similar suggestion (see attached). 
I do agree with the stronger language. We'll work on the text and come back to you.

Cheers,

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, January 17, 2011 9:33 PM
> To: [email-masked]; Pascal Thubert (pthubert); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Gen-ART review of draft-ietf-6lowpan-hc-13.txt
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> Please wait for direction from your document shepherd or AD before posting
> a new version of the draft.
> 
> This draft is a complete redesign (in the form of new headers) of the IPv6
> header compression support for IEEE 802.15.4 in order to make the result
> usable in practice, and hence obsoletes the old formats.  The draft reflects
> experience with the technology and contains a wealth of design details to
> obtain as much leverage as possible from compression.  While I did not go
> through all of the header details, the draft looks like it's in good shape and
> the result of careful consideration.
> 
> I have one open issue.  The draft allows UDP checksums to be omitted when
> there are higher level integrity checks in place, and says the following about
> verification that those checks are in place:
> 
> Omission of UDP checksums has a lousy track record, suggesting that both of
> the above should be "MUST NOT" instead of "SHOULD NOT".  There are
> plenty of storage "war stories" about someone who ran NFS over UDP with
> checksums turned off and later discovered corrupted files.
> 
> There may be something special about 802.15.4 that makes this sort of
> corruption less of a risk, but I strongly request that the IESG discuss whether
> to change both of the above "SHOULD NOT" statements to "MUST NOT" with
> an explanation of the significant risks to data integrity (e.g., there's a reason
> why RFC 2460 made the UDP checksum mandatory).
> 

Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Lars Eggert" <[email-masked]>, "The IESG" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 17 Jan 2011 14:50:26 +0100

Hi Lars,

Many thanks for your review. Please see inline
 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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.
> >    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?
> 
[Pascal] 
I agree with your enforcement of the "MUST NOT" and "MAY only".

I understand that we also need to reference draft-ietf-6man-udpzero, in particular section 3.

No, we haven't ran that spec by 6MAN; I understand you mean we should. Is there a process for doing so when a document is in IESG review? Would we need a last call from 6MAN or something?

For the specific case of the wrong app delivery, I understand that a legacy app should be identified as such by the UDP layer at the socket interface and thus the zero checksum should be seen as a transport layer error and the packet should be dropped. IOW, I'd expect that an application that tolerates a zero checksum indicates so in a socket API to the UDP layer, and that the application that needs zero checksum can make sure that the UDP layer supports that feature . In an ISA100.11a device, the security is actually handled at a sublayer above UDP, and UDP I changed to expect zero checksum and in that case delegate the check to the sublayer. This is what we mean by upper layer authorization.  This is what we mean by:
" 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."

Do we need more?

Pascal

Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: "The IESG" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 17 Jan 2011 16:06:11 +0100

> > In an ISA100.11a device, the security is actually handled at a
sublayer above
> UDP, and UDP I changed to expect zero checksum and in that case
delegate
> the check to the sublayer. This is what we mean by upper layer
authorization.
> This is what we mean by:
> > " 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."
> >
> > Do we need more?
> 
> Yes, I think for safety you need to add that "if the terminating node
does not
> know that the app it is about to deliver a message to will validate it
with a
> sufficiently strong app-layer checksum, it MUST drop the message."
> 
> That seems harsh, but I think is needed to protect against the case
where a
> message gets mis-delivered to an app that does not use app-layer
> checksums.
> 
> Does that make sense?
> 
It does not seem that harsh and we are in the exact same spirit.
There is a need for a UDP layer that can accept packet with a zero
checksum to make sure that the sublayer|ULP performs checks that are
equivalent or better. In the absence of such assurance, the UDP layer
MUST assume a traditional operation. The current text is missing those
specific words and your sentence is fine.

Thanks a lot Lars!

Pascal