Re: 2401bis Issue # 78 -- PMTU issues

[Ravi Kumar <ravivsn@roc.co.in>]

    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:
>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 pmtud@ietf.org.  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