Subject: 2401bis Issue # 78 -- PMTU issues

From: Karen Seo <[email-masked]>
Date: Fri, 26 Sep 2003 23:04:35 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	78

Title:		PMTU issues

Description:
============
In addition to the issue of how to handle ICMP error messages in 
general, there is the specific question of is there some way that 
systems can do Path MTU discovery other than by relying on ICMP error 
messages (PMTUs) from untrusted sources?  Note that we are much more 
concerned about ICMP messages arriving w/o IPsec protection from the 
public Internet vs. such messages arriving from a router "behind" an 
SG.

Proposed approach:
==================
1. Add controls to allow an administrator to configure the IPsec 
system to set a threshold for the minimum size to which the PTMU can 
be set via processing an ICMP PMTU from a public Internet source. The 
default is that the ciphertext size would be 576 bytes (IPv4) or 1280 
(IPv6). These values are likely to be sufficient in almost all cases; 
and one might adopt the Ethernet MTU of 1500 bytes for IPv4 and IPv6.

2. Develop a red side PMTU discovery protocol, for tunnels, to avoid 
the PMTU attack problem, and switch to red side fragmentation 
(fragmenting before IPsec is applied but allowing for IPsec headers), 
vs. black side fragmentation, to minimize the DoS problems for 
receivers. If we put this mechanism into IPsec, each peer can 
determine whether the peer at the other end of an SA supports this 
capability (via IKE) and the SA can provide the protected path. There 
is another working group working on this problem -- see PMTUD WG, 
email [email-masked].  We propose to put this task on hold until 
they're finished.

Thank you,
Karen

---

From: Ravi Kumar <[email-masked]>
Date: Tue, 30 Sep 2003 17:02:32 +0530

Hi,
       I am OK with postponing. But, we can recommend
       'Fragmentation before encapsulation' while sending out the packet and
       MUST not drop incoming redside IP fragment.
        I observed some implementation don't interoperate when we do this.
       .By keeping the above statement, hopefully
       other implementation take care of reassembling the de-secured IP 
fragments
       before matching up with inbound security policies.
    Regards
    Ravi

At 11:04 PM 9/26/03 -0400, Karen Seo wrote:
>In addition to the issue of how to handle ICMP error messages in general, 
>there is the specific question of is there some way that systems can do 
>Path MTU discovery other than by relying on ICMP error messages (PMTUs) 
>from untrusted sources?  Note that we are much more concerned about ICMP 
>messages arriving w/o IPsec protection from the public Internet vs. such 
>messages arriving from a router "behind" an SG.
>
>Proposed approach:
>==================
>1. Add controls to allow an administrator to configure the IPsec system to 
>set a threshold for the minimum size to which the PTMU can be set via 
>processing an ICMP PMTU from a public Internet source. The default is that 
>the ciphertext size would be 576 bytes (IPv4) or 1280 (IPv6). These values 
>are likely to be sufficient in almost all cases; and one might adopt the 
>Ethernet MTU of 1500 bytes for IPv4 and IPv6.
>
>2. Develop a red side PMTU discovery protocol, for tunnels, to avoid the 
>PMTU attack problem, and switch to red side fragmentation (fragmenting 
>before IPsec is applied but allowing for IPsec headers), vs. black side 
>fragmentation, to minimize the DoS problems for receivers. If we put this 
>mechanism into IPsec, each peer can determine whether the peer at the 
>other end of an SA supports this capability (via IKE) and the SA can 
>provide the protected path. There is another working group working on this 
>problem -- see PMTUD WG, email [email-masked].  We propose to put this 
>task on hold until they're finished.
>
>
>Thank you,
>Karen

The Views Presented in this mail are completely mine. The company is not 
responsible for what so ever.

----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA

ROC HOME PAGE:
http://www.roc.co.in