[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC and NAT
--- On Wed, 20 Aug 1997 10:34:14 -0400 (EDT) Tim Bass <ietf@linux.silkroad.com> wrote:
> Two interesting points were made, one related to NAT
> and one related to cryptography, which beg further disussion.
> Hence, I'll make these small arguments in hope the
> topic is appropriate to IPSEC WG:
>
> (1) Cryptography is about techniques to insure confidentality,
> integrity, non-repudiation, authentication, (all the basics
> we all know and love :) for messaging. Bulk encryption does
> this by 'not fiddling with bits' as one described in a reply.
> However, it is not clear, IMHO, that this model is a necessary
> requirement for IPSEC. Is IPSEC just an IP 'centric bulkish'
> encryption :) Hmmmm.
Cases other than "bulk encryption" (e.g. AH with RFC-1828 end-to-end authentication)
provide end-to-end protections against a packet being altered in transit. The
"end-to-end" property is important and was explicitly part of the goal/charter
of IPsec (dating back to 1991). So your assertion (1) above is imprecise
at best.
> (2) NAT is more than 'just a firewall technology'. It is a generalized
> method of translating IP address and its roots were in IP routing
> scalability issues (right?) and many use NAT as a basic tool
> for IP address space management.
Again, I'm not comfortable with your level of precision. NAT is not a firewall
technology -- its an dynamic address translation technology. Address translation
by itself has no interesting security properties and little to do with firewalls.
DHCP is a good example of basic tool for IP address space management.
> Having touched on (1,2) above, one could develop a rational argument that
> IPSEC should be designed to work with NAT, not orthogonal to NAT, because
> NAT has become a basic fact of life in both IP Firewalls and IP address
> space management. One the other hand, one could argue differently :)
Given faulty premises, even flawless logic might not reach an accurate
and precise conclusion.
> My closing thoughts are these, and correct me if I am wrong; doing address
> translation integrated into IPSEC is 'too difficult' or 'too much work'
> for the IPSEC to consider. Or, is it more like 'if IPSEC WG builds
> hooks for NAT' then the precedence has been set for 'more and more
> IPSEC requirements and accomodations'.
No.
IPsec provides an "end-to-end" security service, not a "hop-by-hop" security service.
NAT inteferes with the ability of many security protocols (smb has cited several
examples) to provide "end-to-end" security. The end-to-end security property
is necessary and must not be lost.
That said, _NAT_ implementations can and should be tweaked to accomodate IPsec.
There are a number of methods for this that have already been discussed on this list.
I suspect that major router vendors that ship both technologies would make those
changes so that they can sell more product. I believe it would be constructive
to pause this thread until Bob Moscowitz has a fair chance of getting some of his
thoughts on NAT+IPsec out into a broader view. :-)
Ran
rja@inet.org
References: