[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC Security Gateways & NAT

Honestly, I'm not 100% sure how IKE works in this configuration.  At
least in this method the initiator can be behind a NAT.  It's unclear
how it would work if the responder is behind a NAT.  In the
architecture I described, the initiator is behind a NAT but the
responder is not.

Once an IKE SA is available, the peers must keep the NAT 'live',
mostly by forcing some traffic across the UDP "connection".  The IKE
daemons can just cache the port mappings (it means the responder will
not necessarily see the initiator coming from port 500).

The good thing is that one can multiplex both IKE and ESP onto the
same UDP port pairs.

-derek

"Chen, David" <dchen@ellacoya.com> writes:

> Derek,
> Thanks for the explanation.
> Its seems difficult for IKE to traverse NAPT in ESPoUDP. (the address/port
> changed)
> Does ESPoUDP only apply to data channel?
> Regards,
> --- David
> 
> 
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@mit.edu]
> Sent: Friday, June 08, 2001 2:46 PM
> To: Chen, David
> Cc: 'jshukla'; ipsec@lists.tislabs.com
> Subject: Re: IPSEC Security Gateways & NAT
> 
> 
> My understanding was that ESPinUDP == ESPoUDP which is basically an
> encapsulation of ESP packets (_ANY_ ESP packet) in a UDP header.  So,
> you use UDP as the transport mechanism to get the ESP packet from host
> A to host B through whatever NATs are in the way.  The end-hosts
> decapsulate the packets, and then process the ESP as they normally
> would.  This implies ALL protections and features you would get from
> normal ESP.
> 
> The benefit is that this works 100% in a one-sided-NAT or Road-Warrior
> system.  E.g., if you have something like:
> 
>   RW - NAT - <I-Inet> - SG
> 
> The Road Warrior can setup a NAT traversal by sending UDP packets
> (that happen to contain ESP), and the SG can reply back to the host
> (through the NAT) back to the original UDP port.
> 
> -derek
> 
> "Chen, David" <dchen@ellacoya.com> writes:
> 
> > Jayant,
> > Does "ESPinUDP" apply to both transport and tunnel mode?
> > Where is the draft?
> > Thanks,
> > --- David
> > 
> > -----Original Message-----
> > From: jshukla [mailto:jshukla@earthlink.net]
> > Sent: Friday, June 08, 2001 2:00 PM
> > To: Chen, David; ipsec@lists.tislabs.com
> > Subject: Re: IPSEC Security Gateways & NAT
> > 
> > 
> > 
> > ----- Original Message ----- 
> > From: "Chen, David" <dchen@ellacoya.com>
> > 
> > > Jayant,
> > > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets?
> > 
> > Almost! ESPinUDP inserts an extra UDP header in IPSec packets. 
> > In IPSec, the ESP header follows the IP header. In ESPinUDP 
> > a UDP header follows the IP header and ESP header comes after 
> > that.
> > 
> > IP header | UDP header | ESP header | encrypted payload
> > 
> > regards,
> > Jayant
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
Follow-Ups: References: