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
