RE: PMTU and NAT-Traversal problem

["Brian Swander" <briansw@windows.microsoft.com>]

There aren't too many choices here.  General Ipsec policy securing all
traffic may disallow untrusted ICMPs from intermediate routers, so this
isn't necessarily a new problem.  

The obvious solution is black hole detection, where TCP gradually bumps
down the MTU when it doesn't get a response.  The other choice is to
bump the MTU for all connections to the peer if the ICMP actually makes
it.  

bs

-----Original Message-----
From: Lokesh N B [mailto:lokeshnb@intotoinc.com] 
Sent: Friday, June 14, 2002 5:37 AM
To: Ari Huttunen
Cc: Jan Backman; ipsec@lists.tislabs.com
Subject: Re: PMTU and NAT-Traversal problem



Implementing version 2 of UDP encaps draft doesn't solve the problem
either. -Lokesh On Fri, 14 Jun 2002, Ari Huttunen wrote:

> Note that draft-ietf-ipsec-udp-encaps-02.txt is different in this 
> respect because the 8 byte non-IKE marker was changed to a 4 byte 
> non-ESP marker. Still the UDP header itself is 64 bits.
> 
> You shouldn't be implementing the -01 version in any case.
> 
> Ari
> 
> Lokesh wrote:
> > 
> > Hello jan,
> > Thanks, but that is not the answer to my question.
> > problem is information for SA look up is not present in the returned

> > ICMP PMTU message. Hence sender cannot determine in which SA to 
> > update returned MTU. I think I should explain it bit more clearly.
> > When a IPSec packet with DF bit set, cannot be transmitted over a
link with
> > less MTU,
> > the router would send ICMP PMTU error packet back to sender which
> > contains  IP header and 64 bits of IPSec headers of faulting packet
as data.
> > sender uses the SPI and other packet selectors in the 64 bit
information to
> > look up SA's and adjust their MTU with the returned MTU value in the
ICMP
> > PMTU message.
> > Now, in case where NAT Traversal is supported, IPSec packets will be
> > encapsulated in UDP packets and 8 bytes of NON -IKE marker, the 64
bit info
> > after IP hdr will only contain UDP header using which sender cannot
> > determine SA's over which original faulting packet was sent.
> > Is there any solution exists for this problem?
> > Thanks
> > Lokesh
> > 
> > At 01:59 PM 6/10/02 +0200, Jan Backman wrote:
> > >Hi,
> > >Store the information about the encountered MTU in the NAT and use 
> > >it to reply an ICMP when the next packet in the flow arrives (that 
> > >is larger than the MTU).
> > >
> > >regards /// Jan
> > >
> > > > -----Original Message-----
> > > > From: Lokesh [mailto:lokeshnb@intotoinc.com]
> > > > Sent: Monday, June 10, 2002 12:34 PM
> > > > To: ipsec@lists.tislabs.com
> > > > Subject: PMTU and NAT-Traversal problem
> > > >
> > > >
> > > > Hi all,
> > > > Is there anybody who implemented  following  in a security
Gateway?
> > > > 1. draft-ietf-ipsec-nat-t-ike-01.txt   and
> > > > draft-ietf-ipsec-udp-encaps-01.txt
> > > > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). if

> > > > so, how did you solve following problem?.........
> > > >
> > > > For Unauthenticated ICMP PMTU message processing:
> > > >
> > > > The PMTU processing  bound to fail, since ICMP PMTU error 
> > > > message would include
> > > > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP
> > > > Encaps and NAT
> > > > Traversal drafts encapsulate ipsec packets in UDP and put a 8
> > > > byte NON IKE
> > > > marker,(totalling 16 bytes)
> > > > PMTU error message returned will not have enough information
> > > > to find the
> > > > SA's at the receiving
> > > > Security Gateway. How to solve this problem? any suggestions?
> > > > any help in this regard is highly appreciated.
> > > > Thanks
> > > > Lokesh
> > > >
> 
> --
> 
> Ari Huttunen                   phone: +358 9 2520 0700
> Software Architect             fax  : +358 9 2520 5001
> 
> F-Secure Corporation       http://www.F-Secure.com 
> 
> F(ully)-Secure products: Securing the Mobile Enterprise
>