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. More below: >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). [Pascal] Right. >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.) [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. >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*. [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 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. [Pascal] The correspondent needs to run ULTP over UDP. Agreed about the OS operation on a legacy node. >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. > [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. >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 :-) > [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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
