> >> 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". [Pascal] That's right. Not so difficult to do in the target environment though. We do not have to specify how that happens. Usually a form of SAP/IOCTL in parallel with the socket. Or configuration etc...
>Since we can't put this information into the packet, this means the >optimization can only be done on the source host. [Pascal] That's right. >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. [Pascal] That's right. We still need to work and see if there's a way to avoid decompressing recompressing at every hop. That's bad, in particular with fragments. >Once the packet has gone through a non-6lowpan router, the >authorization to elide is lost. [Pascal] That's right, but that usually does not hurt so much. The optimizaiton is mostly useful across the lowpan from a lowpan node to the outside. That' smost of the traffic. >Also, the app is only supposed to give the authorization of it knows >the other end will check the MIC. [Pascal] That's right. ISA100's MIC also provides authentication > >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. [Pascal] Back to above, the sender should know that the receiver checks the MIC. In any case I agree with you. >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. [Pascal] Good. There is still the tunnel case to cover. > >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? [Pascal] This is good text. It's not a 100 percent replacemeny of my proposal though. What do you think? Pascal > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
