Subject: Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Jan 2011 19:41:58 +0100

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-masked]]
> Sent: Tuesday, January 18, 2011 8:57 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]
>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.
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Jan 2011 10:04:40 +0200

Hi,

> This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points.

right. This is very much related to the ongoing discussion in BEHAVE about how IPv4/IPv6 translator boxes should treat IPv4 packets that come in with UDP checksum zero. If they calculate a UDP checksum for the outgoing UDP packet, they might "upgrade" that packet to a level of assurance that the original didn't have.

I'm not sure what the current thinking in BEHAVE is, but it would make sense for this ID to follow their thinking.

> 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.

Against transmission corruption, but not necessarily against corruption during on-node processing during forwarding; think faulty RAM (yes, rare.)

> 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.

You mean let an IPv6 UDP packet go with a zero checksum? That's at the moment not allowed by RFC2460. The 6MAN WG is discussing just this topic.

Lars

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Jan 2011 10:36:01 +0100

Hi Lars,

> > 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.
> 
> right. This is very much related to the ongoing discussion in BEHAVE
about
> how IPv4/IPv6 translator boxes should treat IPv4 packets that come in
with
> UDP checksum zero. If they calculate a UDP checksum for the outgoing
UDP
> packet, they might "upgrade" that packet to a level of assurance that
the
> original didn't have.
[Pascal] I'll copy Dan, and forward the previous mail unicast.

> I'm not sure what the current thinking in BEHAVE is, but it would make
sense
> for this ID to follow their thinking.
> 
> > 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.
> 
> Against transmission corruption, but not necessarily against
corruption during
> on-node processing during forwarding; think faulty RAM (yes, rare.)

[Pascal] Well:

1) 2 bytes checksum is not exactly a great protection anyway. When I was
younger, I've had a sad experience on a SNA MLTG that would hang because
of the 2 bytes CRC of SDLC. 65535 out of 65536 errors would be caught.
Even on T1 lines, that proved insufficient.

2) The memory error can also happen in the transmitter before checksum
or on the receiver application.
 
> > 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.
> 
> You mean let an IPv6 UDP packet go with a zero checksum? That's at the
> moment not allowed by RFC2460. The 6MAN WG is discussing just this
topic.

[Pascal] Exactly. Without that 6MAN work, we had to reform a normal UDP
packet, thus the current text.
But now, with the 6MAN work (on tunnels mostly as it goes), there might
be an opening.
How would you suggest we move forward?

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 07:55:10 -0800

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2011 1:36 AM
> To: Lars Eggert; Dan Wing (dwing)
> Cc: The IESG; [email-masked]; [email-masked]; 6lowpan-
> [email-masked]; [email-masked]
> Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with
> DISCUSS)
> 
> Hi Lars,
> 
> >

Because 6MAN had not finished deciding exactly what it wanted to do
regarding zero checksums in UDP, we sidestepped the issue as much
as we could.

BEHAVE allows a configuration option to (a) drop an IPv4 UDP packet 
without a checksum, or (b) have the translator calculate the checksum:

http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-23#section-4.5

That document has finished IESG review.

-d

---

From: <[email-masked]>
Date: Wed, 19 Jan 2011 21:06:18 -0500

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

> Sent: Tuesday, January 18, 2011 1:42 PM
> To: Lars Eggert; The IESG; Black, David; [email-masked]
> Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)
> 
> Hi Lars and David:
> 
> 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.
>  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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jan 2011 12:24:16 +0100

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 20, 2011 3:06 AM
> To: Pascal Thubert (pthubert); [email-masked]; [email-masked]; gen-
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> 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
> 
> 
> > 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
> > 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
> > > 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
> > > [Edited to include David Black's gen-art review, since I'm already
> > > holding a discuss on part of the issues he has raised.]
> > >
> > > >  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.
> > >

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 10:20:19 -0500

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

> Sent: Friday, January 21, 2011 6:24 AM
> To: Black, David; [email-masked]; [email-masked]; [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jan 2011 16:46:43 +0100

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

> Sent: Monday, January 24, 2011 4:20 PM
> 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:
> 
> > > To: Pascal Thubert (pthubert); [email-masked]; [email-masked];
> > > gen- [email-masked]
> > > 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
> > > Rechecking the received UDP checksum after applying the other
> > > integrity check is among the ways to achieve this).
> > >
> > > Thanks,
> > > --David
> > >
> > >
> > > > 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.
> > > > would 'look right' to middle boxes and end points.
> > > > let the packet go with a zero checksum and add some text on
> > > > authorizing that
> > > an arbitrary end point.
> > > >
> > > > What do you think?
> > > >
> > > > Pascal
> > > > >g Subject: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13:
> > > > >(with
> > > > >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
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > 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.]
> > > > >
> > > > > >    received such authorization.  The Upper Layer SHOULD only
> > > > > > provide
> > > the
> > > > > >  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.
> > > > >

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 12:07:31 -0500

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

> Sent: Monday, January 24, 2011 10:47 AM
> 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.
> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jan 2011 18:43:58 +0100

Hi David:

I'm with you. Let's see what Lars recommends here.

Pascal

> Sent: Monday, January 24, 2011 6:08 PM
> 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
> 
> > 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
> > > 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:
> > >
> > > > > 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
> > > > > > behalf
> > > of
> > > > > >    the source node and place that checksum in the restored UDP
> > > > > > header
> > > as
> > > > > > 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
> > > > > > > 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
> > > > > > > >    The UDP checksum operation is mandatory with IPv6
> > > > > > > > [RFC2460] for
> > > all
> > > > > > > >    packets.  For that reason [RFC4944] disallows the
> > > > > > > > compression of
> > > the
> > > > > > > >    UDP checksum.
> > > > > > > >    endpoint MAY elide the UDP checksum if it is authorized
> > > > > > > > by the
> > > Upper
> > > > > > > >    received such authorization.  The Upper Layer SHOULD
> > > > > > > > only provide
> > > > > the
> > > > > > >   draft-ietf-6man-udpzero). For example, even if there is an
> > > > > > > upper
> > > layer
> > > > > > >   (port), *that* application may not have an upper layer
> > > > > > > integrity
> > > check
> > > > > > > >  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.
> > > > > > >