RE: NAT Traversal and packet reassemble

[michael lin <michaell@servgate.com>]

You are right. I can only reassemble the fragmented UDP datagrams whose
destination IP is my Gateway IP and there is a tunnel between source IP and
my Gateway. So the only non-IPSec datagrams would be IKE packets, and most
likely it's with certificate. Suppose it will not affect performance, unless
under attack.

Michael

> 
> How much of a problem is this?
> 
> If you reassemble packets before checking then the only 
> impact is if you're
> being hit with fragmented UDP datagrams that you don't need.  
> This should
> not happen unless under attack.
> 
> I don't see reassembly of non-IPSEC datagrams as being a 
> major impediment to
> performance.
> 
> Chris
> 
> > -----Original Message-----
> > From: michael lin [mailto:michaell@servgate.com]
> > Sent: 08 May 2002 00:27
> > To: 'ipsec@lists.tislabs.com'
> > Subject: NAT Traversal and packet reassemble
> > 
> > 
> > Hi,
> > 
> > To support IPSec fragment packets, the only thing, VPN 
> > gateway should do, is
> > to reassemble AH and ESP packets. In NAT Traversal, all IPSec 
> > packets are
> > encapsulated by UDP header (port 500 or 4500). For first 
> fragment, VPN
> > gateway can only keep the packet with UDP port 500 and 
> > non-IKE marker. But
> > for the second fragment, there is no UDP header. There is no 
> > way to know
> > this fragment is UDP encapsulated IPSec packet or other UDP 
> > packets. That
> > means VPN gateway should try to reassemble all UDP packets. 
> > This will affect
> > VPN gateway throughput. 
> > 
> > It seems no way to solve this problem, right?
> > 
> > Michael
> > 
> 
> 
> --------------------------------------------------------------
> ---------------------------------------------------
> The information contained in this message is confidential and 
> is intended 
> for the addressee(s) only.  If you have received this message 
> in error or 
> there are any problems please notify the originator immediately.  The 
> unauthorized use, disclosure, copying or alteration of this 
> message is 
> strictly forbidden. Baltimore Technologies plc will not be 
> liable for direct, 
> special, indirect or consequential damages arising from 
> alteration of the 
> contents of this message by a third party or as a result of 
> any virus being 
> passed on.
>  
> This footnote confirms that this email message has been swept 
> for Content
> Security threats, including computer viruses.
> 
> http://www.baltimore.com
>