Re: NAT

[Tina Bird <tbird () iegroup com>]

Hmm, yes, looks like we're talking at cross purposes here.  In the
second example I described (sorry, not sufficiently visually oriented
here to do pictures), the firewall wasn't itself performing any
encryption, only the internal server - no wonder I/we was/were
confused!

However, it has recently been brought to my attention that there may be 
a legitimate reason for the second sort of scenario.  If one needs to
encapsulate non-TCP/IP traffic for Internet transport, say IPX, one
might want to send the IPX traffic to a PPTP encryptor first (or an 
L2TP router), then further encrypt the PPTP packets in some
stronger encryption/authentication system.  Haven't seen it in
action.  Does sound like more of a bottleneck than it might be worth,
but ought to be feasible.

Sorry for the confusion -- t.

Burden, James wrote:
> Thanks John for your reply, the URLs were good reading.
>
> Tina,
>
> May I ask what isn't true?  I had a hard time following your example ( I
> like pictures myself).  So, I am going to draw them.
>
> I think you are giving two examples.  First:
> [Outside host(encrypt)]<<--(VPN)-->>[Firewall (decrypt - NAT)]<<---clear
> text--->>[inside host]
>
> I think we can both agree that NAT does not interfere in this scenario.
> Although, NAT will always add _some_ latency to network performance, but
> this is a given.
>
> Second:
> [Outside Host(encrypt)]<<--(VPN)-->>[Firewall(decrypt - NAT -
> encrypt)]<<--VPN#2-->>[inside host(decrypt)]
>
> However, the second scenario I say is costly (kludgey - Is this the
> right spelling??).  Not that it cannot be done.  If this is done we can
> see that we are encrypting and decrypting twice.  As the security
> architectures/products are already behind the network
> infrastructure/products by 2-3 years in terms of throughput (i.e.,
> Gigabit Ethernet and ATM OC-3/OC-12.....) then the security engineers
> are in danger of impeding corporation progress and/or needs.  Vendors
> are just now able to support Fast Ethernet (FE) to a fair degree (I
> should define this as not just connecting with a FE interface, but
> supporting near line speeds).   There will be a performance hit (cost)
> taken when using scenario 2 compared to if there were no NAT and only
> encrypting & decrypting once.
>
> If I am missing something, please clue me in.
>
> Jim
>
> > -----Original Message-----
> > From: Tina Bird [SMTP:tbird () iegroup com]
> > Sent: Friday, June 12, 1998 10:33 PM
> > To:   Burden, James
> > Cc:   'Appel, John'; 'firewall-wizards () nfr net'
> > Subject:      Re: NAT
> >
> > This isn't true!  I'm aware of a large number of VPN installations,
> > both IPSec and proprietary, which work quite happily with NAT.  Even
> > PPTP is interoperable now with address translation, at least once
> > you've got your routes set up correctly.
> >
> > F'r instance:  Sidewinder firewalls perform NAT "by default" - that
> > is, you can't have a live Sidewinder that >doesn't< have address
> > translation thanks to the two-or-more NICs, and the lack of IP
> > forwarding.  Sidewinder supports IPSec in both transport and tunnel
> > modes, allowing the VPN to terminate on either the external side of
> > the firewall (in which case the unencrypted, destination side of the
> > IPSec association is the "final" destination, as far as the VPN is
> > concerned) or on the internal side of the firewall (in which case
> > the firewall hands off the traffic to the destination machine on the
> > interior network).  In either case, the firewall is the
> > decryption server, and it's only ever the external
> > firewall IP address which is visible to the public network.
> >
> > I've worked with 3 or 4 other VPN products (Alta Vista, PPTP,
> > VTCP/Secure and Signal 9) with similar success in a NAT environment.
> >
> > Tina Bird
> >
> > Burden, James wrote:
> > > John,
> > >
> > > Besides RFC1918 you can read RFC1631 - The IP Network Address
> > Translator
> > > (NAT). K. Egevang & P. Francis.
> > >      May 1994. (Format: TXT=22714 bytes) (Status: INFORMATIONAL).
> > >
> > > I am not aware of a pro/cons white paper yet.  However, VPN
> > (example:
> > > IPSEC) technologies are costly and kludgey working with NAT.  If IP
> > > headers are encrypted then a tunnel would have to begin and end any
> > > where NAT is used.
> > >
> > > Jim
> > >
> > > James Burden            Phone - 916.351.2243
> > > Security Engineer               Page - 916.814.2563
> > > California ISO                  Fax - 916.351.2181
> > > http://www.caiso.com    Email - jburden () caiso com
> > > 41DF 0E4C 26E0 2FD3 8C81  A260 5C40 280E B4AE 7420
> > > ____________________________________________
> > >    To Teach is to Learn   - Aaron Nimzovich
> > > ____________________________________________
> > >
> > > > -----Original Message-----
> > > > From: Appel, John [SMTP:AppelJ () 1st-annapolis com]
> > > > Sent: Wednesday, June 10, 1998 12:05 PM
> > > > To:   'firewall-wizards () nfr net'
> > > > Subject:      NAT
> > > >
> > > > Is there a FAQ or similar document covering the pros/cons/caveats
> > of
> > > > NAT?
> > > >
> > > > TIA,
> > > >
> > > > John

Attachment: vcard.vcf
Description: Card for Christina Bird