Re: [Gen-art] Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS)

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Wednesday, January 19, 2011 1:36 AM
> To: Lars Eggert; Dan Wing (dwing)
> Cc: The IESG; [e-mail]; [e-mail]; 6lowpan-
> [e-mail]; [e-mail]
> Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with
> DISCUSS)
> 
> Hi Lars,
> 
> >
> > On 2011-1-18, at 20:41, Pascal Thubert (pthubert) wrote:
> > > I'm still unhappy since the text allows a middle point to
> recomputed
> the
> > checksum which then might be delivered erroneously to the wrong IP or
> > port.
> > > This was done to ensure that a packet that flows on the Internet
> would
> > 'look right' to middle boxes and end points.
> >
> > right. This is very much related to the ongoing discussion in BEHAVE
> about
> > how IPv4/IPv6 translator boxes should treat IPv4 packets that come in
> with
> > UDP checksum zero. If they calculate a UDP checksum for the outgoing
> UDP
> > packet, they might "upgrade" that packet to a level of assurance that
> the
> > original didn't have.
> >
> [Pascal] I'll copy Dan, and forward the previous mail unicast.
> 
> > I'm not sure what the current thinking in BEHAVE is, but it would
> make
> sense
> > for this ID to follow their thinking.

Because 6MAN had not finished deciding exactly what it wanted to do
regarding zero checksums in UDP, we sidestepped the issue as much
as we could.

BEHAVE allows a configuration option to (a) drop an IPv4 UDP packet 
without a checksum, or (b) have the translator calculate the checksum:

http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-23#section-4.5

That document has finished IESG review.

-d


> > > It  is probably OK for most 802.15.4 cases since L2 security is
> almost always
> > on and protects the frames a lot better than 2 octets of checksum.
> >
> > Against transmission corruption, but not necessarily against
> corruption during
> > on-node processing during forwarding; think faulty RAM (yes, rare.)
> 
> [Pascal] Well:
> 
> 1) 2 bytes checksum is not exactly a great protection anyway. When I
> was
> younger, I've had a sad experience on a SNA MLTG that would hang
> because
> of the 2 bytes CRC of SDLC. 65535 out of 65536 errors would be caught.
> Even on T1 lines, that proved insufficient.
> 
> 2) The memory error can also happen in the transmitter before checksum
> or on the receiver application.
> 
> > > But if there's no security at work, it would probably be better to
> let the
> > packet go with a zero checksum and add some text on authorizing that
> an
> > arbitrary end point.
> >
> > You mean let an IPv6 UDP packet go with a zero checksum? That's at
> the
> > moment not allowed by RFC2460. The 6MAN WG is discussing just this
> topic.
> 
> [Pascal] Exactly. Without that 6MAN work, we had to reform a normal UDP
> packet, thus the current text.
> But now, with the 6MAN work (on tunnels mostly as it goes), there might
> be an opening.
> How would you suggest we move forward?
> 
> >
> > Lars