Re: IPsec and Fragmentation
Karen Heron <heron@us.ibm.com> Mon, 06 July 1998 15:36 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09044 for ipsec-outgoing; Mon, 6 Jul 1998 11:36:57 -0400 (EDT)
From: Karen Heron <heron@us.ibm.com>
To: ipsec@tis.com, leonard_samuelson@ascend.com
Subject: Re: IPsec and Fragmentation
Message-ID: <5040300017915625000002L052*@MHS>
Date: Mon, 06 Jul 1998 11:49:58 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> 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
- IPsec and Fragmentation Karen Heron
- Re: IPsec and Fragmentation Karen Heron
- Re: IPsec and Fragmentation Dan McDonald
- Re: IPsec and Fragmentation Karen Heron
- Re: IPsec and Fragmentation Dan McDonald
- Re: IPsec and Fragmentation M.C.Nelson
- Re: IPsec and Fragmentation C. Harald Koch
- Re: IPsec and Fragmentation Michael C. Richardson
- Re: IPsec and Fragmentation Karen Heron
- Re: IPsec and Fragmentation Stephen Kent
- Re: IPsec and Fragmentation Karen Heron
- Re: IPsec and Fragmentation Stephen Kent
- Re: IPsec and Fragmentation Stephen Kent
- Re: IPsec and Fragmentation Len Samuelson