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 protected] [mailto:[email protected]]
> Sent: Monday, January 17, 2011 9:33 PM
> To: [email protected]; Pascal Thubert (pthubert); [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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
> <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 protected] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
--- Begin Message ---
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.
> > 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?
>
[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
--- End Message ---
--- Begin Message ---
> > 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
--- End Message ---
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
