[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and Fragmentation
> Path MTU discovery is a required feature of any compliant IPsec
> implementation. While PMTU discovery doesn't "fix the problem", it
> permits originating hosts (be they secured or not) to deflate their MTUs
> according to the actually observed MTU in the pathway.
> We calculate an MTU by subtracting IPsec header/trailer expansion octets
> from the known MTU of the path. (It was a "bug" in our implementation
> until I was charged with implementing PMTU discovery in our IPsec...)
> In your example, the failure in step 6 should cause backpropagation
> (sorry!), by ICMP CANT_FRAG packets, of the MTU to the originator of the
> excessively-large packet. A good question to ask at this point is
> how ICMP CANT_FRAG packets are needed to propagate the real path MTU to
> the originating host.
The problem with SG1 returning a Packet Too Big message with MTU=1500 to H1
is that H1 already sees the Path MTU as 1280 (which is the MTU for the
tunnel). H1 won't increase its PMTU in response to receiving a Packet Too
Big message, but even if H1 did, it would then not be able to send the
packets through the tunnel.
Karen Heron writes:
>> In draft-ietf-ipsec-arch-sec-05, AppendixB, section B.2, Fragmentation, it
>> states that "Fragmentation MUST be done after outbound IPsec processing." I
am
>> seeing a problem when doing this. I have the following setup:
>>
>> +--------------------------------------------------------+
>>
H1---|----MTU=2000-----RTR------MTU=1280------|------SG1-----MTU=1500-----H2
>> +--------------------------------------------------------+
>> SA, tunnel mode
>>
>>
>> H1, H2 - hosts
>> RTR - intermediate router in the secure tunnel
>> SG1 - security gateway
>>
>> What I've tried to show is a tunnel mode SA between H1 and SG1 that will
secure
>> packets from H1 to H2. The
>> MTU in the tunnel will be 1280. Here's what I see happening:
>>
>> 1. H1 sends 1800 bytes to H2. It is secured (it has an outer header) and
sent
>> into the tunnel.
>> 2. A packet too big is sent back from RTR with an MTU of 1280.
>> 3. H1 sends 1800 bytes to H2. It is secured and has an outer header from H1
>> to SG1. It is fragmented and
>> sent into the tunnel.
>> 4. SG1 receives the fragments and reassembles.
>> 5. SG1 de-capsulates the packet and attempts to forward to H2.
>> 6. This fails since the packet is 1800 bytes and the MTU on the output net
for
>> SG1 is 1500 bytes.
>>
>> Have I implemented something incorrectly? It appears that I am following the
>> architecture for H1 (i.e., securing
>> and then fragmenting), but I don't see how I can get these large packets to
H2
>> unless I fragment and then secure
>> in H1. Any help would be appreciated. By the way, my example is for IPv6
(no
>> fragmentation allowed by
>> intermediate routers) although the same problem exists for IPv4 with the DF
bit
>> set in the inner and outer headers.
>>
>> Karen Heron
>> Router Development
>> IBM, RTP, NC
Follow-Ups: