On Nov 20, 2008, at 09:17 , Benjamin A. Rolfe wrote:
how does a lower layer "know" what kind of MIC may be applied by a
higher layer
I think we have arrived at: "the higher layer has to tell the lower
layer".
Since we can't put this information into the packet, this means the
optimization can only be done on the source host.
Also, a 6lowpan-to-6lowpan forwarder (router node inside the 6lowpan)
can use the fact that the incoming packet has the optimization as
authorization in order to also apply it on the outgoing packet.
Once the packet has gone through a non-6lowpan router, the
authorization to elide is lost.
Also, the app is only supposed to give the authorization of it knows
the other end will check the MIC.
The remaining danger is that a packet with a mid-span-generated
checksum has been corrupted inside the 6lowpan to go to a different
node; the checksum generated at the 6lowpan egress will be based on
that corrupted information, so cannot detect that. So a node that
does not know about (or expect) MICs is going to process the corrupted
packet. I think this is a danger we can live with, given how weak the
UDP checksum is in the first place.
So I propose the following text for a new subsection in the UDP
compression section:
n.n.n UDP checksum elision guidelines
A compressor MUST NOT set the C bit unless it has received
authorization from the sending application to elide the checksum. The
application SHOULD only provide the authorization if there is some
other form of integrity check in the packet that covers at least the
same information as the UDP checksum (data, pseudo header) and has at
least the same strength.
There are only two ways this authorization to elide can pass from an
application to a compressor:
1) Locally within a source node (the specific form is local matter,
e.g., by a setsockopt() or as a parameter of the packet sending
interface).
2) Within a forwarding node: the forwarding node MAY imply
authorization from the incoming packet being forwarded if the C bit
was set there.
Note that this makes UDP checksum elision a first-hop or first-few-
hops optimization; once the packet has left the 6lowpan or transited a
node that does not implement (2), the UDP checksum may not be elided
any more. This also means that the checksum has to actually be
computed and inserted into the packet at a node that does not
implement (2) or at an egress Edge Router.
Comments?
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
