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

Re: Wrap-up: TCP checksum calculation



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