[riot-devel] gnrc udp-hc support for elided checksum

René Herthel rene-herthel at outlook.de
Fri Apr 22 21:49:30 CEST 2016


Hello all,

 a little time has passed since I wrote the last mail about eliding 
 checksums of UDP packets for the GNRC network stack.
 There are two general requirements:

 1. We need to pass the information to elide the checksum of a packet 
 through the stack. The netapi is not able to pass additional 
 informations of a packet through the stack.

 2. An application layer protocol that doesn't allow to receive packets 
 where checksums have been elided, shouldn't see any of them.

 My proposed solution for the first problem is to insert a new member in 
 the gnrc_pktsnip_t structure. This member holds the information to 
 authorize a packet, which is a precondition to elide the UDP checksum. 
 This way we can carry around that information through the network stack, 
 for each packet.

 My proposal for the second problem is quite similar:
 Adding a new member to the gnrc_netreg_entry_t structure with the 
 information that the corresponding module (or application) is (not)
 allowed to receive packets with elided checksums.

 In addition one could probably use these newly introduced struct members 
 for different kinds of information, or just don't compile it if it's not 
 needed. Any ideas on that?
With my proposed solution one does not need to change the netapi but 
 enhance some functions to handle the additional information.

 Looking forward to get some feedback from your side!

 Best
 René Herthel
---------------------------------------------------------------------------------------------------

> Date: Tue, 12 Jan 2016 14:52:40 +0100
> From: cabo at tzi.org
> To: devel at riot-os.org
> Subject: Re: [riot-devel] gnrc udp-hc support for elided checksum
> 
> RFC 6282 UDP checksum elision is a textbook example of a "cross-layer"
> optimization that seems cheap to implement but has non-trivial
> architectural costs.
> 
> In order for an application to indicate that the UDP checksum can be
> elided, or for an application to accept UDP datagrams that have had
> their UDP checksum elided, this information really needs to be carried
> down and up with each single datagram.  There is no shortcut that would
> allow making these decisions within the adaptation layer.
> 
> There actually is a significant use case for UDP checksum elision: DTLS.
>  A DTLS implementation should indicate that the UDP checksum can be
> elided when sending datagrams if they have been integrity-protected by
> DTLS -- not so for a few handshake packets.  Similarly, a DTLS
> implementation should accept datagrams where the UDP checksum has been
> elided only if the content of that datagram is then subject to integrity
> protection.  When initiating the listening, it will need to signal that
> it is prepared to accept UDP datagrams with that information attached
> and that it is willing to deal with the information.
> 
> So to implement this, you have to:
> -- implement it in the adaptation layer (RFC6282 implementation);
> -- enhance the interfaces so a "checksum can be/has been elided" bit can
> be carried around with a datagram;
> -- implement that bit in DTLS, and create the necessary signaling;
> -- make sure that unsuspecting applications (that don't know about that
> bit) never see packets where the bit is set.
> 
> Grüße, Carsten
> 
> 
> Oleg Hahm wrote:
> > Hi René!
> > 
> > On Mon, Jan 11, 2016 at 05:14:31PM +0100, René Herthel wrote:
> >> i would like to implement the support (TODO [1]) for elided checksum of
> >> compressed udp pakets on the gnrc.
> > 
> > Thanks for offering your help regarding this topic.
> > 
> >> So therefore i have some questions:
> >> Is someone already working on it?Is there any reason why this is not
> >> implemented before?Are there some things i should definitely know? ( like
> >> other work/PR's which have to be done first, or something else..)
> > 
> > I think there exist some reasons why this hasn't been implemented yet. While
> > decompressing packets with elided UDP checksum shouldn't be problematic,
> > for the compression itself some considerations has to be taken:
> > 1.) RFC 6282, Section 4.3.2 [2] specifies that the upper layer must authorize
> >     the header compression module to elide the checksum. This is only possible
> >     if tunneling (like IPsec Encapsulating Security Payload tunnel mode) or
> >     another message integrity check (such as IPsec Authentication Header) is
> >     present in the UDP payload. Since IPsec has not yet been implemented for
> >     RIOT and to the best of my knowledge also no other tunneling or additional
> >     integrity checking mechanism for UDP payloads exists in GNRC, there is
> >     currently no immediate use case for UDP checksum elision. Also note that
> >     this features is optional.
> > 2.) Since 6LoWPAN and IPHC/NHC operates asynchronously to any upper layer, it
> >     is not trivial to determine for which packets the checksum may be elided.
> >     A node may communicate over UDP to several services or hosts concurrently,
> >     where one connection may use something like IPsec and authorize the NHC
> >     module to elide the checksum, while for another connection this should not
> >     be allowed. I think with the current netapi calls (send and setting of
> >     netopts) this is not easy to implement. Maybe other GNRC knowledgeable
> >     persons such as Martine, Hauke, Cenk, Peter or Johann may have an idea.
> > 
> >> [1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/sixlowpan/iphc/gnrc_sixlowpan_iphc.c#L506 		 	   		  
> > 
> > Cheers,
> > Oleg
> > 
> > [2] https://tools.ietf.org/html/rfc6282#section-4.3.2
> > 
> > _______________________________________________
> > devel mailing list
> > devel at riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20160422/42f62838/attachment-0001.html>


More information about the devel mailing list