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

Re: Wrap-up: TCP checksum calculation




El 15/03/2007, a las 7:24, Erik Nordmark escribió:

marcelo bagnulo braun wrote:

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.

Same is true for the ICMPv6 pseudo-header. And I think the statement is a lot more general than an enumeration of protocols. All protocols sitting above the SHIM6 sub-layer would operate based on the ULIDs. Thus if you had a hypothetical middle-box that cracked open IKE and verified that the ESP/AH packets IP addresses + SPI that matched the IKE exchange, they could also potentially be confused by shim much the same way the TCP checksum verifying middlebox would be.

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 have a hard time understanding the issue from the text. Could we make it a bit more explicit that the TCP and UDP packets aren't modified, but what is modified is relationship between the TCP/UDP/ICMP/ESP/etc header that follows the shim6 header, and the IPv6 header?

   Erik




Section X.X Middle-boxes considerations

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. On the other hand, the upper layers of the peers involved in the communication operate on the ULID pair presented by the Shim6 layer to them, rather on the locator pair contained in the IPv6 header of the actual packets. It should be noted that the Shim6 layer does not modify the data packets, but because a constant ULID pair is presented to upper layers irrespective of the locator pair changes, the relation between the upper layer header (such as TCP, UDP, ICMP, ESP, etc) and the IPv6 header is modified. In particular, if those data packets are TCP, UDP or ICMP 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 try to verify the validity of upper layer sanity checks of the packet on the fly. If they do that based on the actual source and destination addresses contained in the IPv6 header without considering the Shim6 context information (in particular without replacing the locator pair by the ULID pair used by the Shim6 context) such verifications may fail. Those middle-boxes need to be updated in order to be able to parse the Shim6 payload header and find the next header header after that. It is recommended that firewalls and other middle-boxes do not drop packets that carry the Shim6 Payload header with apparently incorrect upper layer validity checks that involve the addresses in the IPv6 header for their computation, unless they are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair for the verification of the validity check.

In the particular case of TCP, UDP and ICMP checksums, it is recommended that firewalls and other middle-boxes 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 are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair to determine the checksum that must be present in a packet with addresses rewritten by shim6.

would that be better?

Regards, marcelo