Subject: [6lowpan] Compressing the UDP checksum

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Mar 2008 14:25:02 +0100

Hi:

Per RFC 4944:
    "The UDP header's checksum field is not compressed and is therefore
carried in full."

The UDP checksum is not the only way to protect the IP pseudo header,
the UDP header and the payload.
ISA 100.11a is defining a transport-level security that does all this
and more, since it has a larger signature and provides mutual
authentication at the same time.

Also, the ISA100.11a transport-level security is usually
hardware-assisted, so it requires little power or CPU time on the field
device, whereas UDP checksum will be a costly CPU operation.

So ISA100.11a is an example where the UDP checksum could and actually
should be compressed over the LoWPAN, leaving it up to be reconstructed
by a backbone router should the packet go any further than the LOWPAN
itself.

Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to
standardize it to mean that the UDP checksum is compressed, provided
that the headers and payload are equally or better protected than if the
checksum was used.

Note: that would be bit 7 in my HC3 proposal.  As a result, the complete
HC3 proposal could save us up to 4 additional bytes over RFC 4944 for a
UDP packet.

What do you think?

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

---

From: Kris Pister <[email-masked]>
Date: Mon, 03 Mar 2008 09:23:09 -0800

Pascal - this is a clear and coherent description of why UDP checksum 
should be elided in some circumstances.  Much better than my efforts 
earlier, and I think that you've addressed most of the concerns that 
were raised then.  I think it's a great idea.

ksjp

---

From: Philip Levis <[email-masked]>
Date: Mon, 3 Mar 2008 10:11:29 -0800

> HC3 proposal could save us up to 4 additional bytes over RFC 4944  

I'm wary of all of these very aggressive compression approaches. They  
shave off a few bits, but add to complexity. One of the challenges in  
lowpans is that their protocols need to remain simple. This isn't to  
say that saving four bytes isn't great; rather, it's a tradeoff to  
protocol complexity (read: code size requirement), and that tradeoff  
shouldn't be ignored.

Phil

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 03 Mar 2008 13:09:32 -0700

While a agree with Phil, I think that Pascal does have an interesting
suggestion in using one of reserved bits to indicated that the UDP
checksum has been elided because the protocol being used provides
protection of the same headers and data with at least the same strength.
It would then be required by any bridge/router that is expanding the
packet to calculate the UDP checksum and insert it.

	geoff

---

From: Philip Levis <[email-masked]>
Date: Mon, 3 Mar 2008 13:43:41 -0800

> packet to calculate the UDP checksum and insert it.

Right. I'm not trying to argue that none of these optimizations are  
worth it. Rather, I'm just trying to point out that on paper you see  
their benefits but not their costs, and so we should keep the costs  
in mind.

The UDP checksum versus message authentication codes does boil down  
to very different error resilience, however. I haven't seen  
experimental results for 15.4, but experimental results for 802.11  
from MIT indicate that many bit errors are in short bursts[1],  
something CRCs are better at catching than cryptographic operations  
are. Not all check bits are equivalent in their error detection  
properties.

Phil

[1] Allen Miu et al., "Improving Loss Resilience with Multi-Radio  
Diversity in Wireless Networks," MOBICOM 2005.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Mar 2008 10:50:54 +0100

Hi Phil:

For this thread and this forum, I'm not sure that an academic discussion
on the exact properties of CRC vs. other MIC techniques are appropriate.
But at the end of the day, I have trouble believing that 16 bits of CRC
will do better than the 32 to 128 bits MIC used in ISA100.11a. In fact,
I have a very vivid memory that 16 bits CRC can be dramatically
unsufficient, but that's another story...

What I really want on the specific topic of UDP checksum compression is
reach acceptance in this group that it can be reasonable to compress the
checksum over the 6LoWPAN network, with its logical consequence of
assigning bit 3 in the HC-UDP header for that purpose; note that the bit
is wasted anyway.

So can we get consensus on this?

Pascal

>-----Original Message-----
>From: Philip Levis [mailto:[email-masked]]
>Sent: lundi 3 mars 2008 22:44
>To: Geoff Mulligan
>Cc: Pascal Thubert (pthubert); [email-masked]; 6lowpan; Jay
Werb
>Subject: Re: [6lowpan] Compressing the UDP checksum
>
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 04 Mar 2008 09:16:42 -0800

Yes, when Kris originally proposed this earlier, we came agreement that 
there are cases where the UDP checksum may be elided simply because it's 
matched or exceeded by other mechanisms.

On the topic of security, I'm not so sure I would've chosen a method 
closer to TLS, by putting it on top of UDP. I would've preferred a 
method that is closer to IPsec, removing any binding to transport layer 
yet still remains end-to-end. While I agree that IPsec, as specified, is 
a little heavyweight. I think it's reasonable for us to mirror IPsec 
ESP, as in RFC4309, except using less bytes for IV and ICV. Key 
management, of course, is a different beast, and I'm not proposing to 
support IKE on 6LoWPAN nodes.

--
Jonathan Hui