Re: Partial checksum support in DCCP_NAT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

Yes, I agree on the "yuck" factor :-).  But I think that there are
enough issues with the zero checksum solution that this sounds better --
not just with header checksum protection, but also zero checksum is
specifically prohibited in UDPv6 so it won't work at all there (thanks
to Gorry for reminding us of this).

Tom P.

> -----Original Message-----
> From: Michael Welzl [mailto:michawe@xxxxxxxxxx]
> Sent: Monday, November 23, 2009 11:54 AM
> To: Phelan, Tom
> Cc: gorry@xxxxxxxxxxxxxx; DCCP working group
> Subject: Re: Partial checksum support in DCCP_NAT
> 
> 
> On Nov 23, 2009, at 4:40 PM, Phelan, Tom wrote:
> 
> > [Subject changed to focus on sub-thread]
> >
> > Hi Michael,
> >
> > I've been thinking about a slight variation of option 3 below for
> > dealing with partial checksums.  Note that the intent of option 3
was
> > _not_ IP/UDP/UDP-Lite/DCCP as was mentioned in another thread.  That
> > just creates a turtles-all-the-way-down problem -- you still have
the
> > top-level UDP checksum to work around.  The intent of option 3 is to
> 
> I understood that "defining UDP-Lite-in-UDP" can't mean
> just to put it into UDP, without playing any additional tricks.
> I thought that this trick might be to use a checksum of
> zero in UDP, and include the UDP header in the UDP-Lite
> checksum ... but then there's the NAT problem again, of
> course, if the ports are included. Sigh...
> 
> 
> > make UDP-Lite changes to UDP.  Basically, just redefine the UDP
length
> > field to the semantics of the checksum coverage field in UDP-Lite.
> >
> > The variation I'm thinking of is to say this -- when a UDP port is
> > offering the DCCP_NAT service, the length field is redefined to
> > checksum
> > coverage.  To use DCCP partial checksum, set the (redefined) length
> > field to the portion of the datagram that needs protection, as
> > negotiated via the DCCP Partial Checksum feature.  This might get
> > around
> > the giant can of worms that redefining the length field everywhere
> > would
> > open.
> 
> So what you say is "for the following port numbers, UDP becomes
> UDP lite". Maybe feasible, but architecturally ugly, of course...
> I don't know how far we can stretch this sort of ugliness for the
> sake of deployability - given the current lack thereof, my tendency
> is to agree to ugly solutions, just to make things happen.
> 
> 
> > I'm not sure what setting the length field to less than the total
> > packet
> > size would do to existing end system and NAT implementations.
Looking
> > at the Linux code, UDP and UDP-Lite are integrated, so it doesn't
barf
> > on UDP length less than packet length, but it looks like you can't
use
> > the socket option to accept less checksum coverage unless it's a
> > UDP-Lite socket.
> >
> > But I don't think it matters if end systems and NATs need to be
> > upgraded
> > to support this, since links already need to be upgraded to
understand
> > partial checksums.
> >
> > Opinions?
> 
> I'm all for it (but I say "yuck!").
> 
> Cheers,
> Michael



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux