Subject: [6lowpan] UDP checksum elide

From: Shoichi Sakane <[email-masked]>
Date: Wed, 19 Nov 2008 03:46:44 +0900

Hi,

In today's meeting, we didn't make a consensus to have the UDP checksum
elide bit in the HC.  I think that it is something like UDP-NAT.
The 6lowpan adaptation layer is responsible to realize it.
In my understanding, the UDP stack of both end devices should calculate
the checksum, and the 6lowpan layer elides or recalculate the checksum.
I believe it is UDP still.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Nov 2008 11:23:13 +0100

Hi Shoishi:

I agree with you that the expanded packet is UDP. Whatever is inside
that UDP packet is not IETF concern long as the UDP guidelines
(http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines) from
transport area are followed by the upper layer.

So again (and again):

- The draft is not talking about a zero checksum: there appeared to be
some confusion with the discussions around UDP tunnels in CAPWAP, AMT or
LISP. Here, once the packet is expanded it is a valid UDP packet with a
correct checksum. Routers on the way can verify that checksum if they
care. The receiver receives a UDP packet with a proper UDP header and
has to verify that checksum. What happens next is beyond UDP. 

- The draft not talking about hop-by-hop Message Integrity Check within
the LoWPAN: Geoff introduced some confusion yesterday. 

- The draft is not loosing end to end integrity: the checksum can be
elided ONLY IF there is an end-to-end integrity mechanism above UDP that
is better than UDP checksum, covers everything that the UDP checksum
covers (including the UDP pseudo header) etc... Yes we are talking about
an improved UDP, but it inherits all the UDP properties so it is still
UDP.

But it is critical that the HC2 defined in the draft expands into a NH
of UDP (17) even when the checksum is elided:

- UDP is ULP agnostic: 6LoWPAN constrains the range of ports (F0Bx) so
it implies that a port number will be overloaded depending on the
deployments. Considering this, it makes a lot of sense that some magic
happens at the ULP to make sure that the message being received is
expected, IOW it makes a lot of sense to have an additional MIC that not
only verifies the integraty but also authenticate the data.

- UDP is well understood by now: with UDP, come the UDP guidelines and
all the litterature.

- UDP is a good fit for smart objects: It is lightweight and enables
applications to save battery in constrained devices by piggy-backing
acks and payload.

- what would it expand to anyway? Defining an adhoc (6LoWPAN?) transport
protocol, we'd loose UDP handling in the Internet. NATs (yes they are
still there). Firewalls. Not defining it, we'd force other parties that
would implement 6LowPAN with checksum compression to invent their own
stuff. That's exactly the opposite of our mission, not only as 6LowPAN
but as IETF.

My take is to stick to what the draft does. We can improve the wording
but changing the bottom-line would hurt terribly the applicability of
this work.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shoichi Sakane
>Sent: mardi 18 novembre 2008 19:47
>To: 6lowpan
>Subject: [6lowpan] UDP checksum elide
>
>Hi,
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 07:00:33 -0600

Hi Pascal,

let's phrase your requirements and the proposed implementation in a  
different way.
You have a "upper layer transport protocol" (ULTP) layered above UDP.   
ULTP includes a MIC that functionally is more powerful than the UDP  
checksum (and includes everything that the latter checks).

BTW, legacy NATs don't work here (they would also need to rewrite the  
ULTP MIC, as the pseudoheader changes with new addresses).  (Oh, and  
routers have little business checking UDP checksums.)

The important thing here: we have to consider both the 6lowpan nodes  
(which may want to save two bytes and some unneeded UDP checksum  
computation) and the correspondent nodes (which have to work with  
legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly  
NATs).

A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away  
the UDP checksum and leaves only the ULTP MIC.  The decompressor at  
the 6lowpan boundary builds a UDP header that includes computed length  
and a newly generated checksum *after it has checked the ULTP MIC*.   
The correspondent node runs a legacy OS that does not know anything  
about ULTP, so the app writer is quite happy that the app can simply  
set up a UDP socket and do the ULTP processing (which may or may not  
include checking the MIC -- irrelevant here) in the app; the OS does  
the UDP checksum checking.

One the way from the correspondent node to the 6lowpan node, an app  
that implements the ULTP computes the MIC to allow the compressor at  
the 6lowpan boundary to check it and, if that *and* the UDP checksum  
were correct, to compress away the UDP checksum.  The ULTP  
implementation of the 6lowpan node now only has the ULTP MIC to check,  
which it does if it cares about e2e integrity; the UDP checksum is no  
longer available but has already been checked by the compressor.  As  
is often the case with header compression, the compressor decides by  
oracle that an ULTP was present (there is no indication in the UDP  
packet); a matching MIC is a very good oracle, though.  In any case,  
header compression *is* layer violation, so there is nothing new here.

One interesting side effect of using the ULTP presence oracle in the  
compressor is that, if the ULTP checksum happens to match, a random  
6lowpan node (that does not implement ULTP) might get a UDP packet  
with an elided checksum.  If that still wants to check the packet, it  
needs to implement the ULTP MIC (which we haven't standardized).   
There is a low likelihood of that happening, but this is not just a  
"packet loss", as it systematically will affect any packet that  
happens to match the MIC even if retransmitted.
In effect, this makes ULTP implementation an all-or-nothing  
requirement on the 6lowpan nodes.  This is the only problem I see with  
this kind of header compression.  (Oh, and, if that is the case, is  
there any point in compressing ULTP as well?)

Do you have a pointer to how the ULTP MIC you have in mind works?   
(Pointing to the entirety of a 1500 page document does not count :-)

Gruesse, Carsten

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 19 Nov 2008 22:39:25 +0900

Hi Carsten,

What I was talking about UDP-NAT is only about the recalculation
of the UDP checksum.  I didn't mean the address translation happened
with this 6lowpan case.

I don't understand why the 6lowpan stack of the receiver builds the UDP
checksum after the ULTP stack has checked the ULTP MIC ?  It is straightforward
that the UDP checksum is built by the 6lowpan stack before the UDP stack gets
the decompressed message before the ULTP stack will get the message.
I am thinking that all of the decompressing is processed at the 6lowpan stack
which is dedicated under the IP stack.  Am I misunderstanding ?

===
Shoichi Sakane

On 11/19/2008 10:00 PM, Carsten Bormann wrote:
> computation) and the correspondent nodes (which have to work with legacy 
> OSes and firewalls, but now can't accommodate non-ULTP-friendly NATs).
> 
> A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away the 
> UDP checksum and leaves only the ULTP MIC.  The decompressor at the 
> 6lowpan boundary builds a UDP header that includes computed length and a 
> newly generated checksum *after it has checked the ULTP MIC*.  The 
> correspondent node runs a legacy OS that does not know anything about 
> ULTP, so the app writer is quite happy that the app can simply set up a 
> UDP socket and do the ULTP processing (which may or may not include 
> checking the MIC -- irrelevant here) in the app; the OS does the UDP 
> checksum checking.
> 
> One the way from the correspondent node to the 6lowpan node, an app that 
> implements the ULTP computes the MIC to allow the compressor at the 
> 6lowpan boundary to check it and, if that *and* the UDP checksum were 
> correct, to compress away the UDP checksum.  The ULTP implementation of 
> the 6lowpan node now only has the ULTP MIC to check, which it does if it 
> cares about e2e integrity; the UDP checksum is no longer available but 
> has already been checked by the compressor.  As is often the case with 
> header compression, the compressor decides by oracle that an ULTP was 
> present (there is no indication in the UDP packet); a matching MIC is a 
> very good oracle, though.  In any case, header compression *is* layer 
> violation, so there is nothing new here.
> 
> 6lowpan node (that does not implement ULTP) might get a UDP packet with 
> an elided checksum.  If that still wants to check the packet, it needs 
> to implement the ULTP MIC (which we haven't standardized).  There is a 
> low likelihood of that happening, but this is not just a "packet loss", 
> as it systematically will affect any packet that happens to match the 
> MIC even if retransmitted.
> In effect, this makes ULTP implementation an all-or-nothing requirement 
> on the 6lowpan nodes.  This is the only problem I see with this kind of 
> header compression.  (Oh, and, if that is the case, is there any point 
> in compressing ULTP as well?)
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 06:42:08 -0800

Carsten Bormann wrote:

> correct, to compress away the UDP checksum. 

What happens if I have an application on a correspondent node which 
sends a regular UDP packet? (i.e., without the ULTP MIC) How can the 
compressor tell the difference between such a UDP packet and a UDP 
packet which includes the ULTP MIC?

    Erik

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 09:24:24 -0600

On Nov 19, 2008, at 08:42 , Erik Nordmark wrote:

>> that implements the ULTP computes the MIC to allow the compressor  
>> at the 6lowpan boundary to check it and, if that *and* the UDP  
>> checksum were correct, to compress away the UDP checksum.
>

That is indeed the point I was making.

I wrote:

> As is often the case with header compression, the compressor decides  
> by oracle that an ULTP was present (there is no indication in the  
> UDP packet); a matching MIC is a very good oracle, though.  In any  
> case, header compression *is* layer violation, so there is nothing  
> new here.

So the answer is: If the MIC doesn't match (or there are not enough  
bytes that this could be a MICed packet), the UDP checksum stays in.
If the MIC *does* match by accident, the compressor will likely decide  
to take out the UDP checksum, which leads to the second half of my  
point:

> with an elided checksum.  If that still wants to check the packet,  
> it needs to implement the ULTP MIC (which we haven't standardized).   
> requirement on the 6lowpan nodes.  This is the only problem I see  
> with this kind of header compression.  (Oh, and, if that is the  
> case, is there any point in compressing ULTP as well?)

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Nov 2008 16:46:12 +0100

Hi Erik:

If the compressor is a router forwarding a packet into the lowpan, then
it can not so it will not compress the checksum. The only node that can
compress the checksum is the transport endpoint that sources the
compressed packet.

Today, 99.9 percent of the packets that transit in such networks are
data measurements transmitted from a sensor node towards an application
that resides on a gateway or on the backbone. So it's worth the effort.

Also, there are tons of legacy field buses protocols in that space that
we will be tunneling over UDP/6LoWPAN. In that case also, the checksum
will be elided.

Pascal

>From: Erik Nordmark [mailto:[email-masked]]
>Sent: mercredi 19 novembre 2008 15:42
>To: Carsten Bormann
>Cc: Pascal Thubert (pthubert); Shoichi Sakane; 6lowpan; Geoff Mulligan
>Subject: Re: [6lowpan] UDP checksum elide
>
>Carsten Bormann wrote:
>
that

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 10:21:24 -0600

> of the UDP checksum.  I didn't mean the address translation happened

OK.
(I still think it's worth to make the point that the ULTP MIC renders  
legacy NATs unusable unless there is a way to undo the damage before  
checking/generating the MIC.)

> checksum after the ULTP stack has checked the ULTP MIC ?

It shouldn't (unless the implementation is so cleanly layered that the  
UDP layer would immediately discard the packet).  Did I say that?
At the compressor, you *have* to layer-violate, as usual.

> It is straightforward

Again, if your implementation is that cleanly layered.
Conceptually speaking, you are right.

> which is dedicated under the IP stack.  Am I misunderstanding ?

No, conceptually, you are right.
But when you argue about complexity of implementation, in reality  
there will be a signal from the decompressor that the UDP layer does  
not have to bother checking (actually, that the whole UDP layer is  
bypassed except for port numbers).

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 10:45:02 -0600

Shoichi just talked to me and made me realize that this can be put in  
a simpler way:

Where HC-03 says:

    C: Checksum:
       0: All 16 bits of Checksum are carried in-line.  The Checksum  
MUST
          be included if there are no other end-to-end integrity checks
          that are stronger 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.
       1: All 16 bits of Checksum are elided.  The Checksum is recovered
          by recomputing it.

How does the compressor know that there are "other end-to-end  
integrity checks
that are stronger than what is provided by the UDP checksum."?
It might on the sending end node.
It's hard to know that on a router, however; just looking at the  
packet doesn't tell.
Oracles only help if both cases are supported at both the compressor  
and the decompressor side, because the oracle can err.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 10:48:04 -0600

> The only node that can

That might be good material for a note in HC-03 then.

> we will be tunneling over UDP/6LoWPAN. In that case also, the checksum

More text for the note.  The tunneling protocol would have to include  
a checksum covering the pseudo-header, though.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Nov 2008 17:51:54 +0100

Hi Carsten 

(a long mail :) )

You got me slightly wrong:
the MIC is end to end over UDP and has to be there and checked.

Most times there will be no NAT because we are using IPv6 within a
domain 
- say a factory plant, an enterprise, a building, a home. 
I do not expect IPv6 to IPv6 NATs there, would you?

If there is a need to traverse IPv4 then I suspect that IPv6 will be
simply
tunneled over IPv4 and the IPv6 addresses will be preserved. 
I'm more concerned with firewalls then I am with NATs.

One thing that is very important is that the set of well-compressed
ports 
is very narrow (16). All 6LoWPAN deployments will attempt to reuse that 
range of ports, so F0Bx ports will be highly overloaded by differents 
6LoWPAN Applications.

An application listening to these ports should protect itself against 
unwanted traffic, either sent there by mistake or as the result of an
attack. 
So end-to-end authentication AND integrity are required.  This is why 
more often than not you'll get the MIC we are talking about. 

Now if we have an application that does not check for MICs, UDP will 
pass the packet to the application because it is valid at that layer.
Hopefully the app can recognize its payload, but it's not as safe.

>checksum (and includes everything that the latter checks).

[Pascal] Right. 

>routers have little business checking UDP checksums.)

[Pascal] They do though, when forwarding cost makes it worth the effort.
An example of that is DTN in deep space. UDP checksum is a layer
violation anyway.

>and a newly generated checksum *after it has checked the ULTP MIC*.

[Pascal] A 6LoWPAN router would NOT check the ULTP MIC - an ALG would.
6LoWPAN defines IP and UDP compression but ULTP MIC is beyond the spec.
That's why the correspondent end point HAS TO check the MIC. 

>the UDP checksum checking.

[Pascal] The correspondent needs to run ULTP over UDP. 
Agreed about the OS operation on a legacy node.

>header compression *is* layer violation, so there is nothing new here.
[Pascal] 

I do not expect that much - at least initially. The edge router
that performs 6LoWPAN compression might be in the middle of many 
application flows that might use different flavors of ULTP so it does
not 
know what MIC to apply. Also, since the MIC is probably also used for
authentication purposes, the router simply does not have the keys.

So it can either compress all packets, no packets, or get a hint 
from the packet like a flow label, in a way that is not standardized
today.

So we can not save easily the 2 bytes in that direction in the general
case.
But we can save on the operation in the receiving node.

A receiving node can check for the MIC first, and, if there is a MIC,
It can bypass the checksum validation that can be more expensive in
energy
than the MIC computation because the MIC will use whatever crypto the 
hardware assist in the chipset provides. 

For instance, ISA100.11a uses CCM (RFC 3610) that is common in 802.15.4
chipsets for L2 security.

>(Pointing to the entirety of a 1500 page document does not count :-)
[Pascal] 
I can point you to the 10-20 pages of ISA100.11a transport, though 
I'd rather wait till it has migrated from RFC 4944 to hc-03, which will 
happen in the current of the month. But that's just an example. 

Same causes, same effects, other 6LoWPAN application designers have a
good 
chance to reach similar conclusions and require a MIC one way or
another.

Best :)
 
Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Nov 2008 17:56:55 +0100

That's right.

The checksum is always 'virtually there' when it's elided. As opposde to
NULL.

We need to add text that when tunneling another protocol that protects
itself, the checksum can be elided but has to be restored when the
packet is expanded. 

This is the same spirit but a slightly different case because in the
tunnel case, the source and destination that are protected by the MIC
(of the inner packet) are different from the outer header protected by
UDP, though the UDP protection does not help so much that it would be
required to leave it uncompressed.

Would you propose text? We have a few typos to fix so we can always
publish a cleaner 04 before we address the other comments from the WG
meeting like contexts, link local, etc...

Pascal

>From: Carsten Bormann [mailto:[email-masked]]
>Sent: mercredi 19 novembre 2008 17:48
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Erik Nordmark; Shoichi Sakane; 6lowpan; Geoff
Mulligan

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 09:23:57 -0800

> that resides on a gateway or on the backbone. So it's worth the effort.

Doesn't this imply that the sender needs to know whether the destination 
is on the far side of a router which does the decompression?
How can the sender determine this?

I don't see how it can tell that since we've been talking about
  - using the same subnet prefix for an extended 6lowpan
  - having the decompression happen in the ER
  - having hosts on the backbone

Thus when a host on the backbone sends a packet your first paragraph 
seems to say that the UDP checksum can not be compressed, since the 
packet is forwarded by a (compressing) ER.

Assuming the sending 6lowpan node uses the destination prefix ("is it in 
my subnet prefix?") to determine whether or not a MIC is included and 
the UDP checksum compressed out, then the hosts on the backbone will 
receive some UDP packets with a MIC, and other UDP packets (from other 
hosts) without a MIC.

IMHO it would be a lot more robust to define a new IP protocol number 
for the "UDP with a MIC" protocol.

    Erik

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 20 Nov 2008 02:31:05 +0900

On 11/20/2008 01:45 AM, Carsten Bormann wrote:
> Shoichi just talked to me and made me realize that this can be put in a 
> simpler way:

Thank you for correcting me at the discussion.  My assumption was
different from all of you.  I was thinking that only when there was a
strong MIC under the 6lowpan layer, then the UDP checksum could be omitted.

The point was that how the ER or (de)compresser knew whether there
would be strong checksum at the end-to-end.  I think the behavior of
the 6lowpan layer should not depend on the upper layer situation.
I think that the decision of the behavior which it sets 0 or 1 should
be an out-of-band parameter.

> Where HC-03 says:
> 
>    C: Checksum:
>       0: All 16 bits of Checksum are carried in-line.  The Checksum MUST

So, I propose this bit should be remained.  An environment needs to
reserve 2 bytes, and it has a stronger MIC, the administrator tells the
ER to set the C-bit to 1, and then the (de)compresser care the UDP checksum.
Is there any problem of my assumption ?

> How does the compressor know that there are "other end-to-end integrity 
> checks
> It's hard to know that on a router, however; just looking at the packet 
> doesn't tell.
> Oracles only help if both cases are supported at both the compressor and 
> the decompressor side, because the oracle can err.
> 
> Gruesse, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Nov 2008 12:28:58 -0600

On Nov 19, 2008, at 11:23 , Erik Nordmark wrote:

> Doesn't this imply that the sender needs to know whether the  
> destination is on the far side of a router which does the  
> decompression?

Decompression usually happens at the L2-L3 boundary, so it is always  
the case that the packet undergoes decompression before being handed  
to a router or app.
Yes, L4 compression is undone before any L3 forwarding (did I mention  
"layer violation"?).
(Implementations can optimize that so a L3 forwarder does not really  
have to decompress/compress if the packet goes into a similar network,  
but conceptually it has to.)

> - having hosts on the backbone

The L3 forwarder cannot make that optimization then.

> packet is forwarded by a (compressing) ER.

Correct.

Also, when a UDP-checksum-elided packet traverses the backbone, it  
will be sent back into the lowpan without the elision optimization.   
Big deal, I'd say; not the case we are optimizing for.
Think "outsourcing the checksum computation to the ER".

> Assuming the sending 6lowpan node uses the destination prefix ("is  
> it in my subnet prefix?") to determine whether or not a MIC is  
> included and the UDP checksum compressed out, then the hosts on the  
> backbone will receive some UDP packets with a MIC, and other UDP  
> packets (from other hosts) without a MIC.

I think Pascal is right that this is a first-hop (plus all contiguous  
hops that can make the above optimization in their forwarders)  
optimization.  The app can then simply signal the applicability of UDP  
checksum elision down the stack.

> IMHO it would be a lot more robust to define a new IP protocol  
> number for the "UDP with a MIC" protocol.

Yes, in a greenfield world.
The problem is that the correspondent nodes are random legacy PCs and  
such stuff.
How do you handle "UDP with a MIC" in Windows 3.1?
(Yes, that is a rhetorical question, since 3.1 did not have IPv6.)

Gruesse, Carsten

PS.: I'm not saying the whole ordeal is worth it.  I'm just saying it  
can be made to work.
Sometimes complexity like this is needed for political reasons.   
Convince me that it is.
It will be much harder to convince me that there is a technical reason.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 15:38:54 -0800

Carsten Bormann wrote:

> Also, when a UDP-checksum-elided packet traverses the backbone, it will 
> be sent back into the lowpan without the elision optimization.  Big 
> deal, I'd say; not the case we are optimizing for.

I don't have a problem with that form of outsourcing as long as L2 has 
checksum/CRC that is applied between the ER and 6lowpan host that is at 
least as strong as the UDP checksum.

That would be a reasonable layer violation, since L3 can check the L2 
capabilities (implicitly or explicitly.)

But the case at hand is where L3 needs to depend on L7 capabilities, and 
furthermore the ER doesn't have an exact way to determine whether the 
application has those capabilies; ithe ERt needs to employ some 
heuristic guesswork.

> (Yes, that is a rhetorical question, since 3.1 did not have IPv6.)

Don't all the OSes on the legacy nodes on the backbone or that will run 
as gateways have support for raw sockets?

> PS.: I'm not saying the whole ordeal is worth it.  I'm just saying it 

Your definition of "work" might be different than mine ;-)
It doesn't look robust when it is based on heuristics of this form.

    Erik

---

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

>> Also, when a UDP-checksum-elided packet traverses the backbone, it
will
>least as strong as the UDP checksum.
[Pascal] 
The stronger CRC we are talking about is in fact end-to-end so it
encompasses the compressed segment. The Edge router can not know whether
that happens, it can only trust that the source node behaved, and
compressed the checksum only if it was entitled to per our spec.

>capabilities (implicitly or explicitly.)
[Pascal] 
We can not be relying on the L2 MIC in mesh-under because the L2
information that the ER sees covers only the last hop. 

>application has those capabilies; ithe ERt needs to employ some
[Pascal] 
It is the source node responsibility to elide the checksum. The ER does
not guess; it has to trust that the source node complies to this spec
and is entitled to perform the compression.

- For a packet sourced in a node in the LoWPAN, the ER recomputes a
compressed checksum as part of the UDP expansion in the input (6LoWPAN)
interface, and then passes the packet to L3.

- For a packet coming from outside, the ER can not compress. Some manual
config or hint in the packet might enable that but it's out of scope for
this doc.

>as gateways have support for raw sockets?
[Pascal] 
6LoWPAN compression/expansion happens in a shim layer between L2 and L3.

When sending a packet, Upper layers have to pass hints down the stack to
enable it, like an IOCTL. That will be highly implementation dependant,
but quite easy in a sensor stack that is very light and
mission-optimized.

OSes in Hosts in the backbome do not see a thing since all the magic
happens above UDP. 

Gateways terminate the transport layer so they have to support 6LoWPAN
interface like any node in the LoWPAN. Gateways might or might not
shortcut the UDP checksum operation in presence of a MIC, depending on
how easy it is in the code base they are using. A 'clean' implementation
would have to compute the checksum in the shim for UDP above to verify
it. If the NULL checksum was allowed in IPv6 it would certainly be used
there.

>It doesn't look robust when it is based on heuristics of this form.
[Pascal] 
I can not see the need for heuristics. 
This mechanism has been discussed at length in this group and at ISA. 
For all I know it works but it's fair to shake it and review the
associated text to make sure it's very crisp on when the checksum can be
elided.

Pascal

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 21 Nov 2008 01:01:42 +0900

All,

Would it be possible to make sense by the following text ?
Please correct me if there is something wrong.

- the 6lowpan compresser of the source of a packet MAY elide
  the UDP checksum when the stack is aware of presence of
  a MIC at the other layer.

- the 6lowpan decompresser of the destination of a packet MUST build
  the UDP checksum when the C bit has being set to 1.

- the 6lowpan (de)compresser of a gateway b/w the 6lowpan cloud and
  others:

   + MUST build the UDP checksum in the case that the C bit has
     being set to 1 when the node is going to forward the packet
     from the 6lowpan cloud to the others.

   + MAY elide the UDP checksum in the case that the stack is
     aware of presence of a MIC at the other layer, and MUST
     set the C bit to 1 in this case when the node is going to
     forward the packet to the 6lowpan cloud from the others.

- Any UDP stack of the source (or the destination) of a packet must
  always calculate (or check) the UDP checksum according to RFC2460.

- The mechanism by which the 6lowpan stack is aware of presence of
  a MIC at the other layer is out of scope of this specification.
  E.g. it might be realized by a manual configuration.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Nov 2008 08:25:16 -0800

> compressed the checksum only if it was entitled to per our spec.

You ignored the "L2" in my sentence. It is quite key.

> information that the ER sees covers only the last hop. 

So it would have to be a L2.5 MIC.

But my point is really about having an architecture that helps with 
robustness and having a solid base from which the protocols can evolve. 
Having L3 depend on a L7 MIC without being able to reliably determine 
whether the L7 MIC is present in the packet doesn't seem to do that.

> associated text to make sure it's very crisp on when the checksum can be

I think without an explicit way for the decompressor at the L3-L2 
boundary to tell that there is a L7 MIC the proposal is just a hack and 
should not be standardized.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Nov 2008 17:34:08 +0100

Hi Erik

>should not be standardized.

[Pascal] It knows that there is a MIC because the checksum is elided.
The source is not allowed to elide the checksum otherwise. It is up to
the source to screw up but that's true for all the rest.

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Nov 2008 14:32:26 -0600

On Nov 21, 2008, at 14:26 , Geoff Mulligan wrote:

> Does the MIC cover the UDP Pseudoheader checksum?

A little bird tells me that is replaced by zero in the MIC calculation.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Nov 2008 15:28:41 -0600

> Are you saying that the 6lowpan edge router strips off the ULTP
> (whatever that is) before sending the packet on?  If it doesn't strip
> the ULTP then the legacy OS at the other end needs to know/understand
> this ULTP, right?

No, the legacy OS hands the UDP payload to the app, which parses out  
the ULTP header from that and handles the data.

> I'm not convinced that all of this complexity is worth the minor
> optimization for this edge case.

I think the solution we have now arrived at is quite clean and not  
very complex; the danger of sending data to the wrong recipient is  
present but limited (and that danger is present but only somewhat more  
limited with a UDP checksum in place).

The cost of the solution is that the decompressors will have to  
compute checksums; this is not a problem for an end system  
decompressor (which in most cases will not compute it, but rather know  
the checksum it would compute is correct) or for a intra-lowpan  
forwarder (that can simply leave things compressed), so the cost only  
occurs at an edge router, where it is quite bearable.

The win is saving two bytes per packet from a sensor that applies  
application-level^W upper-transport-layer-level security.  Limited,  
but depending on the size of this packet we are talking about maybe 5  
% of the total bytes, which may be worth some code.  Less data will  
also relieve interference just a bit, which may be of interest in  
particular for 868 MHz (packets get almost a millisecond shorter  
there).  The biggest win is in the heads of design engineers who can't  
stand sending two redundant bytes, though :-)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Nov 2008 18:48:31 -0600

On Nov 21, 2008, at 17:56 , Geoff Mulligan wrote:

> Just so we are clear:
> - the only place that this compression will now happen is at the
>   source of the packet on a 6lowpan node

Correct.

> - this does not work for inbound packets

Correct.
The argument was made that the nodes that would benefit most are  
sensors with mostly outbound packets.

> - it doesn't have applicability to legacy tunneled protocols

Not sure we have consensus on this issue yet.
We need to develop some useful criteria for when a ULTP/app checksum  
is good enough so we can write these into the document.

> - for the source to compress the udp checksum the application must  
> have
>   a layer 7 MIC that calculates the MIC over the application payload
>   AND the pseudo header and signal to the 6lowpan layer that UDP
>   checksum compression is ok

that is a sufficient condition.
is it exactly the necessary one?

> - the edge router, when it gets a packet with the c bit set it will
>   compute the udp checksum and insert it in the full ipv6/udp header
>   and send the packet on it's way.

As I said, conceptually, this happens at every decompressor.
The edge router cannot optimize it away, as opposed to intra-lowpan  
hosts and forwarders.

> - the edge router has no way to verify the ip addresses since there is
>   no checksum and there is no validity check on the packet header or
>   the new checksum

Correct.
But it has the indication that the peer (if its address wasn't  
corrupted in transit) is going to check the MIC in the form of the C  
bit.

> - when the MIC is calculated over the IP and udp headers the udp
>   checksum value should be zero

(or excluded from the computation, whatever.)

> - in the end we save 2 bytes on some packets

Yes, and we spend 0.125 (but in a byte that is mostly unused right now).
<broken-record>We don't have a benchmark that we could use to judge  
that gain.</broken-record>

Good summary, except that I'm not fully sure about the criteria yet.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 22 Nov 2008 13:43:33 +0100

A little bird and the text that says that the MIC covers what the UDP
checksum covers... 
Which does not include itself. The MIC happens before the UDP checksum
because it is above in the stack.

Pascal

>Sent: vendredi 21 novembre 2008 21:32
>To: Geoff Mulligan
>Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 Nov 2008 16:56:24 -0700

Just so we are clear:
 - for the source to compress the udp checksum the application must have

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 Nov 2008 14:16:26 -0700

> (Yes, that is a rhetorical question, since 3.1 did not have IPv6.)
But in-order to have end to end reliability, the random legacy PC and
stuff will have to have new code and application that understands this
new MIC so there must be changes to the legacy PC or this doesn't seem
to work.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 Nov 2008 13:26:33 -0700

> legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly  

Does the MIC cover the UDP Pseudoheader checksum?  If so there is no
savings of computation since the checksum needs to be calculated anyway
or is the checksum not covered by the MIC?

 
> were correct, to compress away the UDP checksum.  

So is the checksum calculated and included in the bytes that are covered
by the MIC?

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 Nov 2008 13:37:59 -0700

> I do not expect IPv6 to IPv6 NATs there, would you?

Agreed, there is not likely to be IPv6 NAT - good point.

> more often than not you'll get the MIC we are talking about. 

Possibly in industrial applications, but I'm not sure that such a
general statement is true for all the apps that will be built.

> That's why the correspondent end point HAS TO check the MIC. 
This is confusing.  If you are doing route over, do the routers need to
confirm that the the IP addresses in the packet header have not
inadvertently been changed?  Isn't that part of the purpose of the
pseudo header chacksum?  Do intermediate routers today check the UDP
checksum?  Possibly not, in which case 6lowpan routers might not.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 Nov 2008 13:30:06 -0700

> we will be tunneling over UDP/6LoWPAN. In that case also, the checksum

How can this happen with legacy protocols.  They do not know about IP
and IPv6 and the pseudo header so they will not calculate a MIC over
anything but their own data, unless you are saying that the code that
tunnels the protocol calculates yet another mic over the tunneled
protocol and the IP header.  Is the udp checksum calculated and covered
by the MIC?

	geoff