Re: Wrap-up: TCP checksum calculation

[Brian E Carpenter <brc@zurich.ibm.com>]

On 2007-03-14 11:53, marcelo bagnulo braun wrote:
> El 13/03/2007, a las 22:30, Erik Nordmark escribió:
>
> > marcelo bagnulo braun wrote:
> >
> > > The problem is that shim6 payload packets that carry locators 
> > > different than ULIDs, will have the checksum calculated based on the 
> > > ULIDs and not on the actual addresses carried in the ipv6 header. 
> > > This would imply that any device in the middle (from NIC to middle 
> > > boxes (firewalls and TCP relays)) will fail the checksum verification 
> > > (and drop the packet). It is possible that TCP checksum verification 
> > > is more common, since there is no IP checksum in IPv6.
> > I don't understand what the issue is.
> >
> > The shim6 packets have a protocol/nexthdr field which is shim6 and not 
> > TCP, UDP, etc.
> > Thus an unmodified middlebox doesn't see a TCP packet - it seems a to 
> > it unknown IP protocol.
> > Only if the middlebox is modified to know about shim6 would it be able 
> > to skip the shim6 header to find the TCP, UDP, etc header.
> > And a middlebox which is modified to know about shim6 could be aware 
> > that the TCP/UDP etc checksums are different when there is a shim6 
> > payload message before the TCP/UDP header.
> >
> > > Proposed approach:
> > > First: Add a new section titled "Middle-boxes considerations" with 
> > > the following text.
> > > It is recommended that firewalls and other middleboxes do not drop 
> > > TCP, UDP and ICMP packets with apparently incorrect checksums based 
> > > on that fact alone unless they implement (monitoring of) the full 
> > > shim6 protocol and are able to determine the checksum that must be 
> > > present in a packet with addresses rewritten by shim6."
> > If the above sentence was expanded to say that these TCP etc headers 
> > are the ones that follow a shim6 header, then it would be a useful 
> > addition.
> Add a new section titled "Middle-boxes considerations" with the 
> following text.
> Data packets belonging to a Shim6 context carrying the Shim6 Payload 
> Header contain alternative locators other than the ULIDs in the source 
> and destination address fields of the IPv6 header. However, if those 
> data packets are TCP or UDP packets, the presudoheader used for the 
> checksum calculation will contain the ULID pair, rather than the locator 
> pair contained in the data packet.
> It is possible that some firewalls or other middle boxes verify the 
> TCP/UDP checksum. Those middleboxes need to be updated in order to be 
> able to parse the Shim6 payload header and find the TCP/UDP header after 
> that. It is recommended that firewalls and other middleboxes do not drop 
> TCP, UDP and ICMP packets that carry the Shim6 Payload header with 
> apparently incorrect checksums when using the addresses in the IPv6 
> header for the pseudoheader computation, unless they implement 
> (monitoring of) the full shim6 protocol and are able to determine the 
> checksum that must be present in a packet with addresses rewritten by 
> shim6.
> would this be ok/enough?
I don't know how TCP relays work. If (as seems logical) they correctly
terminate the first hop of TCP, they could be shim6-capable (in which
case they will do the right thing). If they are not shim6-capable,
then shim6 will never be used by the originating host and we have
no problem.

On the other hand, if TCP relays mess with addresses and checksums
like a NAT does, the above text should apply.

So I think we are OK.

    Brian