On 10 Jun 2008, at 15:13, Pascal Thubert (pthubert) wrote: > 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
It's a pretence, then. (US readers: pretense.) > the IPv6 next header and the > 6LoWPAN HC2 though we know it's improper. right. > 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. But the proposed way to handle the UDP checksum does not respect the e2e UDP checksum, so this really isn't UDP; just a convenient way to stick something else on top, even if that something else has a separate, higher and therefore better, e2e check. >> 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, where the regenerated UDP checksum will be relied on by e.g. NAT boxes, which recompute the checksum again. Ugh. Okay, once NAT's involved the checksums are all messed up and regenerated and not pristine anyway. Not a convincing example. Better example: there's an application sitting on a node on the Internet, pretending to be an ISA100.11a node, and regenerating the UDP checksum so that this application can just use ordinary sockets to talk to a node on a 15.4 net is desirable and inevitable. This will make developing for ISA convenient; it is guaranteed to happen, and has properly happened already. Everything gets virtualized. What happens when the regenerated UDP checksum and the ISA checksum from a packet on the 15.4 net disagree about whether the packet is good? UDP says 'discard, so the app never sees it', but the UDP checksum is no longer really the e2e arbiter here. If ISA sat on IP direct, this would be avoided. > that's the end to end principle. > IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. But the UDP header is no longer being used to provide header and payload protection; it's really just in there for convenience. >>> - 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? Yes, I'm challenging that pretence, simply because it is a pretence; thanks for the explanations to this point. I can see how ISA is e2e between ISA nodes thanks to internal consistency/pseudoheader checks; what I can't see is why that UDP header is in there having its semantics munged, when it's only used as a layering hack. Separately, the zero-checksum 'changing something well-known just because we're compensating for it by layering something else on top' idea makes me uncomfortable; the pieces will be reused badly. How long before someone says 'zero-checksum UDP is great, because it's faster, so let's do zero-checksum ISA, as that's faster too', and goes on to rediscover that implementations with UDP checksums off introduce problems? There's willingness to alter RFC2460 and RFC4346 to get a zero checksum here; how will the next group to come along alter existing specs as well? Slippery slope. (I think if ISA sat over UDP-Lite, there would be slightly less of a pretence here, as redundant coverage of the payload from a checksum that's not trustworthy would at least be removed. And there's less data for the Lite checksum to be computed across. But really, ISA over IP direct doing its own pseudoheader check without the UDP fields makes a lot more sense to me.) ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of UDP. Still, never mind; it is, of course, late to change the ISA100 design (but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to ignore me. cheers, L. and I'll feel free to say "told you so" in a decade or so. 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
