Hi Pascal,
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).
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.)
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*.
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.
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.
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 :-)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
