Subject: [6lowpan] Proposed new text for the UDP checksum elide issue

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Nov 2008 11:46:10 +0100

Hi:

Carsten asked for a crisper wording for which node can elide the UDP 
checksum and when that happens. There seems to be a consensus that 
we are not ready to open the door for heuristics based operations.

So at this point, only the source of a packet MAY elide the checksum, 
And the receiver of a packet MAY ignore the checksum if it is present.
This in only allowed in the case of tunneling or stronger integrity 
check above UDP.

Here is a proposed text:

"
   With this specification, the source of a packet MAY elide the UDP
   checksum in the following cases:

   Tunneling:  The source of the packet is tunneling another packet that
      possesses its own integrity mechanism.
   Upper Layer MIC:  The Upper Layer Protocol over UDP uses an end-to-
      end Message Integrity Check (MIC) that has stronger properties
      than what is provided by the UDP checksum.  Such an integrity
      check MUST be end-to-end and cover the IPv6 pseudo-header, UDP
      header, and UDP payload.

   Only the source of a packet can know what Upper Layer operation takes
   place.  A router on the way that is not aware of such operation
   SHOULD NOT elide the UDP checksum when performing 6LoWPAN
   compression.

   The 6LoWPAN termination point has to recompute the elided checksum
   based on the received packet.  If that point is a router, then the
   router reforms a proper IPv6/UDP packet that can be forwarded on any
   interface.  If the 6LoWPAN termination point is the destination of
   the packet and is aware of the presence of the Upper Layer MIC for
   the destination UDP port, it MAY omit the UDP checksum operation
   completely.
"

What do you think?

Pascal

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 20 Nov 2008 07:17:04 -0800

Perhaps this is a "newbee" question, answered in the history of this 
discussion thread, but how does a lower layer "know" what kind of MIC may be 
applied by a higher layer (i.e. in the payload) unless it is explicitly told 
by the next higher layer?  The suggested wording requires such cross layer 
knowledge.  I see that only the source of the packet can know this, but 
likewise in that source node, how would the LoWPAN layer make such a 
determination? The obvious way is when informed by the upper layer via the 
appropriate SAP mechanisms. Would the wording not be more 'crisp' if it the 
only case is when the suppression of the UDP CRC is indicated by the upper 
layer?

Mention is made of this being a layer violation in the thread, but what I 
don't understand is why this is necessary in the standard?

Thanks

-Ben

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Nov 2008 10:11:25 -0600

On Nov 20, 2008, at 09:17 , Benjamin A. Rolfe wrote:

> how does a lower layer "know" what kind of MIC may be applied by a  
> higher layer

I think we have arrived at: "the higher layer has to tell the lower  
layer".
Since we can't put this information into the packet, this means the  
optimization can only be done on the source host.
Also, a 6lowpan-to-6lowpan forwarder (router node inside the 6lowpan)  
can use the fact that the incoming packet has the optimization as  
authorization in order to also apply it on the outgoing packet.
Once the packet has gone through a non-6lowpan router, the  
authorization to elide is lost.
Also, the app is only supposed to give the authorization of it knows  
the other end will check the MIC.

The remaining danger is that a packet with a mid-span-generated  
checksum has been corrupted inside the 6lowpan to go to a different  
node; the checksum generated at the 6lowpan egress will be based on  
that corrupted information, so cannot detect that.  So a node that  
does not know about (or expect) MICs is going to process the corrupted  
packet.  I think this is a danger we can live with, given how weak the  
UDP checksum is in the first place.

So I propose the following text for a new subsection in the UDP  
compression section:

n.n.n UDP checksum elision guidelines

A compressor MUST NOT set the C bit unless it has received  
authorization from the sending application to elide the checksum.  The  
application SHOULD only provide the authorization if there is some  
other form of integrity check in the packet that covers at least the  
same information as the UDP checksum (data, pseudo header) and has at  
least the same strength.

There are only two ways this authorization to elide can pass from an  
application to a compressor:

1) Locally within a source node (the specific form is local matter,  
e.g., by a setsockopt() or as a parameter of the packet sending  
interface).

2) Within a forwarding node: the forwarding node MAY imply  
authorization from the incoming packet being forwarded if the C bit  
was set there.

Note that this makes UDP checksum elision a first-hop or first-few- 
hops optimization; once the packet has left the 6lowpan or transited a  
node that does not implement (2), the UDP checksum may not be elided  
any more.  This also means that the checksum has to actually be  
computed and inserted into the packet at a node that does not  
implement (2) or at an egress Edge Router.

Comments?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Nov 2008 18:57:14 +0100

Hi Ben

>only case is when the suppression of the UDP CRC is indicated by the
upper

[Pascal] That's right. But for tunnels which are similar yet a bit
different.

>don't understand is why this is necessary in the standard?
[Pascal] 
Saving bits is critical in this space, mostly sensors->backbone because
that's most of the traffic and backbone routers have a power source
anyway. Bits translate into days and weeks of battery operation. Bits
can make the difference between a packet that can be sent on scavenged
energy and a packet that can not be. 2 bytes are wealth in LoWPANs :)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Nov 2008 18:59:54 +0100

>I think we have arrived at: "the higher layer has to tell the lower
[Pascal] 
That's right. 
Not so difficult to do in the target environment though.
We do not have to specify how that happens. 
Usually a form of SAP/IOCTL in parallel with the socket. 
Or configuration etc...

>optimization can only be done on the source host.
[Pascal] 
That's right.

>authorization in order to also apply it on the outgoing packet.
[Pascal] 
That's right. 
We still need to work and see if there's a way to avoid decompressing
recompressing at every hop. That's bad, in particular with fragments.

>authorization to elide is lost.
[Pascal] 
That's right, but that usually does not hurt so much. The optimizaiton
is mostly useful across the lowpan from a lowpan node to the outside.
That' smost of the traffic.
 
>the other end will check the MIC.
[Pascal] 
That's right. ISA100's MIC also provides authentication

>UDP checksum is in the first place.
[Pascal] 
Back to above, the sender should know that the receiver checks the MIC.
In any case I agree with you.

>same information as the UDP checksum (data, pseudo header) and has at
[Pascal] Good. There is still the tunnel case to cover.

>implement (2) or at an egress Edge Router.
[Pascal] This is good text. It's not a 100 percent replacemeny of my
proposal though.
What do you think?

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Nov 2008 12:20:17 -0600

> In any case I agree with you.

It can't know anything about the receiver if the packet is corrupted  
and as a result misrouted to a total stranger.
But again, this is a danger we probably can live with -- receivers who  
care should probably have some app level checking anyway.

> [Pascal] This is good text. It's not a 100 percent replacemeny of my

What's missing?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Nov 2008 10:42:17 +0100

Hi Carsten, 

Things that I'd wish to see in there:

1) MIC usage and recommendation

An application getting a misdirected payload can happen today and that
has nothing to do with the checksum. UDP is a dangerous tool and the
IETF does generally recommends the use of other transports such SCTP.
The risk of getting the wrong type of payload and misinterpreting the
content is increased when the ports are overloaded like our F0Bx as
opposed to reserved at IANA like say, TFTP. 

Considering that the F0Bx ports will be used by many apps, apps should
protect themselves and recognize their payload. One way of doing this is
to provide their own MIC. Apps might also provide their own internal
dispatch.

I think we need words to actually recommend the use of some integrity
check / authentication such as a Transport Layer Security above UDP to
enable both the checksum compression and protect the application against
misguided packets.

2) Tunnel

There are tons of legacy protocols in the sensor space, many of them
proprietary, more and more of then providing a bus technology base on
ethernet, IP over even UDP. The transition to wireless and the backbone
operation that aggregates such traffic can be reasonably done an opaque
tunneling over UDP - call it pseudofieldbus like we have a pseudowire.

The tunneled PDU possesses its own addressing, security and integrity
check. Then again it makes little sense to add the 2 checksum octets to
the non negligible overhead of UDP tunneling.

I think we need words to allow an UDP tunnel endpoint to elide the UDP
checksum.

3) More and more focussed on the operation in the transport endpoint and
in the intermediate router

A part of your text is informative explains the whys and the hows like
how the stack passes the information down; this is good information but
would delay us and I expect that it should appear in a different
document. 

Instead, I'd wish to concentrate on the normative part that specifies a
protocol that guarantees that we get the expected result with the SHOULD
and the MAYs: 

On the sending transport endpoint 
---------------------------------
I like the following sentence:

"A compressor MUST NOT set the C bit unless it has received
authorization from the sending application to elide the checksum.  The
application SHOULD only provide the authorization if there is some other
form of integrity check in the packet that covers at least the same
information as the UDP checksum (data, pseudo header) and has at least
the same strength."

I'd turn the MUST in a SHOULD, for as you mentioned in that thread, UDP
checksum's worth is limited anyway. This gives the behaviour of the
source transport endpoint. Also, the upper layer might not be an
application. It can also be a TLS residing above UDP. So I'd use 'Upper
Layer' to be more generic.

On the forwarding node
----------------------
Your text on the forwarding node seems perfectly reasonable to me too:

"The forwarding node MAY imply authorization from the incoming packet
being forwarded if the C bit was set there."

But I would like to add the reverse condition, that is something like:

"The forwarding node that can not derive such authorization in an
non-ambiguous fashion SHOULD NOT elide the UDP checksum when performing
6LoWPAN compression."

And I would also like to see text that expresses that the router
computes the checksum as part of the 6LoWPAN expansion and that when the
packet gets forwarded onto another interface, it is a valid IPv6/UDP
packet, like:

"The forwarding node that expands a 6LoWPAN packets 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 2460, RFC 768]."

On the receiving transport endpoint
-----------------------------------

I think we need text there too.

"If the 6LoWPAN termination is a transport endpoint, and it receives an
incoming packet has the C bit set, then it is entitled to ignore the UDP
checksum process completely."

Also but maybe more controversial:

"If the C bit not set, the packet might have been forwarded by an edge
router, so this must not be taken as an indication that the MIC is not
present. If the terminating node knows that the MIC will be checked 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." 

What do you think?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:[email-masked]]
>Sent: jeudi 20 novembre 2008 19:20
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Benjamin A. Rolfe; 6lowpan
>Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide
issue

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Nov 2008 11:58:39 +0100

Hi Carsten:

I including your input and reshuffled a bit. 

Here's the updated proposal for -04:

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

   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 imply authorization from the incoming packet
   being forwarded if the C bit was set there.  The forwarding node that
   can not derive the authorization in an non-ambiguous fashion SHOULD
   NOT elide the UDP checksum when performing 6LoWPAN compression.  The
   forwarding node that expands a 6LoWPAN packets 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 that has the C bit set, 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.

What do you think?

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pascal Thubert
>(pthubert)
>Sent: jeudi 20 novembre 2008 11:46
>To: 6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Nov 2008 06:08:37 -0600

Conceptually, decompression with the C bit set means that the elided  
field is reconstituted, i.e. a UDP checksum is computed.
No difference between node and router.
*As an optimization*, a node that is going to discard it right away  
(a) when re-compressing on the other side of the forwarder or (b) when  
checking the checksum, might not do the computation (I would expect  
that optimization to be implemented everywhere, but it is not a  
feature of the protocol).

I believe the places where I used MUST should be MUST.  They are  
essential features to make the compression mechanism work.
When you say SHOULD, what special conditions are you envisioning here  
where that would not be heeded but the protocol still works?

Field bus protocols don't encompass the pseudo-header in their  
checksum, so technically they are outside the condition that allows  
the application (yes, I should have said upper layer) to indicate  
authorization to elide.  If they have their own addressing, that is  
rarely out of a global address space like the IPv6 address protected  
by the pseudoheader.

If we turn some of the MUSTs into SHOULDs, we need to add text that  
explains the purpose of the UDP checksum and the pseudoheader so  
readers not as familiar with IPv6 get enough information to make an  
informed decision whether they really should be violating the SHOULD.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Nov 2008 13:39:01 +0100

>No difference between node and router.

[Pascal] Agreed

>feature of the protocol).
[Pascal] 
Agreed. Also when passing the packet to ULP in clear 
understanding that a MIC takes place.

>where that would not be heeded but the protocol still works?

[Pascal] Makes sense.

Can you please copy/paste/update the proposal to restores 
MUST where you reckon it's mandatory?

>rarely out of a global address space like the IPv6 address protected

[Pascal] A protocol should protect itself. If the field protocol is 
already IP/UDP then it does. For the tons of protocols in place in 
buildings and industrial spaces, I guess that the gateway that 
performs the tunneling will have to be configured to tell whether
the tunneled protocol is intrinsically safe. Since we will not provide
that list, the goal is to have a text that's just open enough to allow
it.

>informed decision whether they really should be violating the SHOULD.

[Pascal] The ball is in your camp :) please propose a revision with
MUSTs.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Nov 2008 17:56:41 +0100

Hi again Carsten:

I mixed your latest comments in:

   With this specification, a compressor in the source transport
   endpoint MAY elide the UDP checksum in certain cases for instance:

   This elision is indicated by setting the 'C' bit in the LOWPAN_NHC
   header.

   A 6LoWPAN endpoint that compresses the LOWPAN_NHC header MUST NOT
   elide the UDP checksum (set the C bit) unless it has been authorized
   to do so by the source of the packet.  In the source transport
   endpoint, this authorization can come from upper layer transport or
   application protocol instance that originated the packet.  In a
   forwarding node, this authorization is implied when the incoming
   packet had the optimization applied (add the C bit set).

   A 6LoWPAN endpoint that expands the LOWPAN_NHC header MUST
   reconstitute the UDP checksum by computing the valid value for the
   datagram as specified in [RFC0768] and [RFC2460], and place the
   result of that computation in the restored UDP header, unless it has
   been authorized to ignore the checksum operation.  In the destination
   transport endpoint this authorization can come from upper layer
   transport that will receive the packet and would ignore the UDP
   checksum should it be restored.

What do you think?

Pascal