[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