Hi Carsten, Things that I'd wish to see in there:
1) MIC usage and recommendation An application getting a misdirected payload can happen today and that has nothing to do with the checksum. UDP is a dangerous tool and the IETF does generally recommends the use of other transports such SCTP. The risk of getting the wrong type of payload and misinterpreting the content is increased when the ports are overloaded like our F0Bx as opposed to reserved at IANA like say, TFTP. Considering that the F0Bx ports will be used by many apps, apps should protect themselves and recognize their payload. One way of doing this is to provide their own MIC. Apps might also provide their own internal dispatch. I think we need words to actually recommend the use of some integrity check / authentication such as a Transport Layer Security above UDP to enable both the checksum compression and protect the application against misguided packets. 2) Tunnel There are tons of legacy protocols in the sensor space, many of them proprietary, more and more of then providing a bus technology base on ethernet, IP over even UDP. The transition to wireless and the backbone operation that aggregates such traffic can be reasonably done an opaque tunneling over UDP - call it pseudofieldbus like we have a pseudowire. The tunneled PDU possesses its own addressing, security and integrity check. Then again it makes little sense to add the 2 checksum octets to the non negligible overhead of UDP tunneling. I think we need words to allow an UDP tunnel endpoint to elide the UDP checksum. 3) More and more focussed on the operation in the transport endpoint and in the intermediate router A part of your text is informative explains the whys and the hows like how the stack passes the information down; this is good information but would delay us and I expect that it should appear in a different document. Instead, I'd wish to concentrate on the normative part that specifies a protocol that guarantees that we get the expected result with the SHOULD and the MAYs: On the sending transport endpoint --------------------------------- I like the following sentence: "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." I'd turn the MUST in a SHOULD, for as you mentioned in that thread, UDP checksum's worth is limited anyway. This gives the behaviour of the source transport endpoint. Also, the upper layer might not be an application. It can also be a TLS residing above UDP. So I'd use 'Upper Layer' to be more generic. On the forwarding node ---------------------- Your text on the forwarding node seems perfectly reasonable to me too: "The forwarding node MAY imply authorization from the incoming packet being forwarded if the C bit was set there." But I would like to add the reverse condition, that is something like: "The forwarding node that can not derive such authorization in an non-ambiguous fashion SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression." And I would also like to see text that expresses that the router computes the checksum as part of the 6LoWPAN expansion and that when the packet gets forwarded onto another interface, it is a valid IPv6/UDP packet, like: "The forwarding node that expands a 6LoWPAN packets with the C bit on MUST compute the UDP checksum on behalf of the source node and place that checksum in the restored UDP header as specified in the incumbent standards [RFC 2460, RFC 768]." On the receiving transport endpoint ----------------------------------- I think we need text there too. "If the 6LoWPAN termination is a transport endpoint, and it receives an incoming packet has the C bit set, then it is entitled to ignore the UDP checksum process completely." Also but maybe more controversial: "If the C bit not set, the packet might have been forwarded by an edge router, so this must not be taken as an indication that the MIC is not present. If the terminating node knows that the MIC will be checked by the upper layer by some state associated to the service access point, it is entitled to ignore the checksum operation as if the C bit was set." What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[EMAIL PROTECTED] >Sent: jeudi 20 novembre 2008 19:20 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Benjamin A. Rolfe; 6lowpan >Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue > >On Nov 20, 2008, at 11:59 , Pascal Thubert (pthubert) wrote: > >>> 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. > >It can't know anything about the receiver if the packet is corrupted >and as a result misrouted to a total stranger. >But again, this is a danger we probably can live with -- receivers who >care should probably have some app level checking anyway. > >> [Pascal] This is good text. It's not a 100 percent replacemeny of my >> proposal though. > >What's missing? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
