Subject: [Ipsec] Native host and plaintext side fragmentation

From: <[email-masked]>
Date: Wed, 27 Jun 2007 14:41:17 +0200

Hi,
 
Reading RFC4301 regarding fragmentation in a native host implementation puzzles me.
How can we avoid fragmentation on the plaintext side ?

Regard a scenario like

      H1                     SG                         H2
    +-----+                +-----+                    +-----+
    |     |                |     |                    |     |
    |     |<--ESP tunnel-->|     |<--small MTU link-->|     |
    +-----+                +-----+                    +-----+

where H1 (a native host with IPSec) sends packets to H2 via an IPSec tunnel to SG.
The packets send by H1 is from an UDP based application which is not able to segment the packets, but rely on the IP layer fragmentation.

If H1 only makes fragmentation after IPSec, i.e. on the ciphertext side, then these fragments are reassembled at SG before IPSec decapsulated.
The packets might now be too large to forward to H2, and at least for IPv6 is SG not allowed to fragment the packet before forwarding it, but SG must send an ICMP error message to H1.
H1 listen to this ICMP error, and fragments the packets into smaller chunks, but if this fragmentation is done after IPSec processing, then again SG reassembles the packets, and can not forward it.

How can we avoid that H1 must do plaintext fragmentation down to the pmtu received in IPSec protected ICMP errror messages ?
If H1 do plaintext fragmentation then also native host implementations have the problems with mapping non-initial fragments to the correct SA.
 
Can someone please point out where my misunderstanding is ?
 
best regards
Inger Bohlbro
 
TietoEnator A/S
Skanderborgvej 232
DK-8260 Viby J
Denmark
 
Mobile:    +45 30 91 84 63
E-mail:    [email-masked]
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 27 Jun 2007 07:42:49 -0600

Inger, RFC 4301 section 5.1 alludes to logic to determine whether to 
fragment before or after encapsulation:

"Note that the SA PMTU value, plus the value of the stateful fragment 
checking flag (and the DF bit in the IP header of the outbound packet) 
determine whether the packet can (must) be fragmented prior to or after 
IPsec processing, or if it must be discarded and an ICMP PMTU message is 
sent."

Section 8 describes in more detail what should happen in tunnel mode:

"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."

The RFC mentions configuration in case 2, but we can also derive some 
behavior from common sense.  It is necessary to fragment before 
encapsulation (either for a security gateway or for H1 in your diagram) 
based on the known PMTU to the final destination -- as you point out, 
failure to do this can prevent the packet from reaching the final 
destination.  (Here is where the possibility of configuration enters into 
the picture -- if the security and network administrators know a priori 
that this will not be a problem then the pre-encapsulation fragmentation 
can be skipped and all of the problems dealt with by section 7 and 
appendix D are conveniently bypassed.)  It may also be necessary to 
fragment after encapsulation if the packet's new route to the remote 
security gateway indicates a smaller PMTU.  It is thus possible to 
fragment both before and after encapsulation; however, if fragmentation 
occurs before encapsulation, it would be prudent to use the known "outer 
header" PMTU as feedback into that fragmentation so that further 
fragmentation is not necessary after encapsulation.

In short, we cannot avoid fragmentation on the cleartext side without 
jeopardizing the flow of traffic.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/

<[email-masked]> 
06/27/2007 08:41 AM

To
<[email-masked]>
cc

Subject
[Ipsec] Native host and plaintext side fragmentation

Hi,
 
Reading RFC4301 regarding fragmentation in a native host implementation 
puzzles me.
How can we avoid fragmentation on the plaintext side ?

Regard a scenario like

      H1                     SG                         H2
    +-----+                +-----+                    +-----+
    |     |                |     |                    |     |

where H1 (a native host with IPSec) sends packets to H2 via an IPSec 
tunnel to SG.
The packets send by H1 is from an UDP based application which is not able 
to segment the packets, but rely on the IP layer fragmentation.

If H1 only makes fragmentation after IPSec, i.e. on the ciphertext side, 
then these fragments are reassembled at SG before IPSec decapsulated.
The packets might now be too large to forward to H2, and at least for IPv6 
is SG not allowed to fragment the packet before forwarding it, but SG must 
send an ICMP error message to H1.
H1 listen to this ICMP error, and fragments the packets into smaller 
chunks, but if this fragmentation is done after IPSec processing, then 
again SG reassembles the packets, and can not forward it.

How can we avoid that H1 must do plaintext fragmentation down to the pmtu 
received in IPSec protected ICMP errror messages ?
If H1 do plaintext fragmentation then also native host implementations 
have the problems with mapping non-initial fragments to the correct SA.

best regards
Inger Bohlbro
 
TietoEnator A/S
Skanderborgvej 232
DK-8260 Viby J
Denmark
 
Mobile:    +45 30 91 84 63