Re: IPsec and Fragmentation
"M.C.Nelson" <netsec@panix.com> Mon, 06 July 1998 17:13 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09449 for ipsec-outgoing; Mon, 6 Jul 1998 13:13:13 -0400 (EDT)
Date: Mon, 06 Jul 1998 13:29:28 -0400
From: "M.C.Nelson" <netsec@panix.com>
To: ipsec@tis.com
cc: heron@us.ibm.com
Subject: Re: IPsec and Fragmentation
In-Reply-To: <5040300017915625000002L052*@MHS>
Message-ID: <Pine.SUN.3.94.980706131409.24624A-100000@panix3.panix.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
IPSEC WG, I just want to add a parenthetic note, that PMTU seems to really be at odds with the definition and philosophy of IP, i.e. IP in general, is supposed to be able to fragment packets in route, and routes are in general subject to change. I have some difficulty understanding why an appropriate IP encryption standard that is supposed to become general usage, would require such dissonances with the general case use of its host architecture. Mitch Nelson On Mon, 6 Jul 1998, Karen Heron wrote: > > 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