On 10 Jun 2008, at 12:49, Pascal Thubert (pthubert) wrote: > Hi Lloyd: > > This is great reading and might prevent mistakes in using UDP CS > compression; > but does not apply here: > > - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) > Message Integrity Check (MIC) instead of UDP checksum.
Pascal, End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How can this be "end-to-end UDP" when it clearly doesn't want to be UDP? Sitting directly on top of IP at both endhosts and doing the pseudo- header check yourself as a transport layer alternative to UDP, without the overhead of unwanted UDP fields that get faked up, would seem to make more sense here than sort-of-tunnelling in UDP from the endhost and then subverting and reconstituting the UDP fields. RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits UDP checksum compression for good reason. Modifying that to allow checksum compression might work for IA100.11a if and only if both endhosts are sitting on the 802.15.4 network communicating via ISA100.11a, and the packet never goes any further - ie you're relying solely on the MIC, and the UDP checksum is never used. If the packet goes further and a reconstituted UDP checksum is required at the endhost for an integrity check - that's the slippery slope where the end-to-end principle has many warnings. Applying TLS across the 6lowpan part of such a path does not mitigate end-to-end concerns here. And, thanks to NAT/relaying etc., it can't be guaranteed that the packet will go no further - a slippery slope. > - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) TLS was intended and is used simply as a shorthand for transport layer security - a term you used in the email I was replying to. I don't accept that RFC4346 now owns the term. This quote to you from Geoff Mulligan on 22 May seems relevant and applicable here: "There is some concern that has been expressed that we are prematurely optimizing the headers. I'm not convinced that the benefits of saving 3 bytes outweighs un-thought-of issues that might come about because of these optimizations." cheers, L. > - And we are designing for devices that might not have hardware assist > other than maybe what's specified by 802.15.4 so that's what we use. > > I hope it's clearer now... > > Pascal DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ <http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
