Hi Carsten,
What I was talking about UDP-NAT is only about the recalculation
of the UDP checksum. I didn't mean the address translation happened
with this 6lowpan case.
I don't understand why the 6lowpan stack of the receiver builds the UDP
checksum after the ULTP stack has checked the ULTP MIC ? It is straightforward
that the UDP checksum is built by the 6lowpan stack before the UDP stack gets
the decompressed message before the ULTP stack will get the message.
I am thinking that all of the decompressing is processed at the 6lowpan stack
which is dedicated under the IP stack. Am I misunderstanding ?
===
Shoichi Sakane
On 11/19/2008 10:00 PM, Carsten Bormann wrote:
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
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
