Hi Lloyd: >> - 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.
[Pascal] The only fake is that we still call the ISA100.11a transport UDP though it's not. This is done to reuse the IPv6 next header and the 6LoWPAN HC2 though we know it's improper. The transport is a UDP variant in that the checksum is computed differently, has additional security properties and gets placed somewhere else. But the end to end principle is respected exactly as with original UDP. > >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. > [Pascal] No. The ISA100.11a transport is end to end as usual in the IP model; both ends need to be ISA100.11a nodes so that they know how to terminate the ISA100.11a transport. The IP network in the middle is transparent and could be the Internet, that's the end to end principle. IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. > >> - 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." [Pascal] ISA100.11a has spent quite some effort doing its work. For instance, we made sure that the points raised in draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular aspect of how we compute the checksum, we pretend it is as good or better than in the original UDP. Are you challenging that? Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
