[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and Fragmentation
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
>
>
>
>
>
Follow-Ups:
References: