[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