Templin, Fred L writes:
> > I believe this is referring to mapping of ICMP "too big" messages. When
> > a tunnel end-point receives a "too big" message, it would have to map
> > the message to an ICMP message for the original host. I believe this
> > could be done in a stateless manner using the packet quoted in the
> > message. (RFC2463 says the "too big" message will include "As much of
> > invoking packet as will fit without the ICMPv6 packet exceeding the
> > minimum IPv6 MTU")
>
> But, if the packet-in-error encapsulated in the ICMP
> PTB message is encrypted and not complete (i.e., only
> the leading 1200 or so bytes of the encrypted packet
> are included), how will the tunnel ingress know how to
> decrypt it in order to do the stateless translation?
If we are talking about IPsec, then that ICMP packet will have the SPI
of the packet, so the gateway can find the related IPsec SA for the
the packet which caused the PTB message to be sent. After that it
simply stores the maximum path MTU it got from the ICMP message to the
IPsec SA.
When the next packet comes through which is bigger than what the MTU
stored for the SA (where the MTU is already modified accordingly to
match the overhead of IPsec headers), it will directly send PTB
message back to the original sender of the packet.
I.e. it will dynamically find out the PMTU for each IPsec SA (taking
the overhead in to account, as it does know the overhead), and then
send PTB messages if packet is bigger than that.
See section 8.2.1 of RFC4301:
----------------------------------------------------------------------
8.2.1. Propagation of PMTU
When an IPsec implementation receives an unauthenticated PMTU
message, and it is configured to process (vs. ignore) such messages,
it maps the message to the SA to which it corresponds. This mapping
is effected by extracting the header information from the payload of
the PMTU message and applying the procedure described in Section 5.2.
The PMTU determined by this message is used to update the SAD PMTU
field, taking into account the size of the AH or ESP header that will
be applied, any crypto synchronization data, and the overhead imposed
by an additional IP header, in the case of a tunnel mode SA.
In a native host implementation, it is possible to maintain PMTU data
at the same granularity as for unprotected communication, so there is
no loss of functionality. Signaling of the PMTU information is
internal to the host. For all other IPsec implementation options,
the PMTU data must be propagated via a synthesized ICMP PMTU. In
these cases, the IPsec implementation SHOULD wait for outbound
traffic to be mapped to the SAD entry. When such traffic arrives, if
the traffic would exceed the updated PMTU value the traffic MUST be
handled as follows:
Case 1: Original (cleartext) packet is IPv4 and has the DF
bit set. The implementation SHOULD discard the packet
and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation SHOULD fragment (before or
after encryption per its configuration) and then forward
the fragments. It SHOULD NOT send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation
SHOULD discard the packet and send a PMTU ICMP message.
--
[email protected]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
