[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt
"jshukla" <jshukla@trlokom.com> writes:
> ----- Original Message -----
> From: "Markus Stenberg" <mstenber@ssh.com>
> > from 5.3:
> >
> > The drawbacks of this approach are that it will require
> > modifications to existing NAT implementations, and will have
> > overhead in book-keeping to ensure that no two hosts use the same
> > port number.
> >
> > To be specific, it does NOT require changes to the intervening NAT devices
> > on network path between IPsec endpoints. One endpoint MAY need to contain
> > NAT implementation, which obviously is nonstandard as it performs
> > (host,port) <> internal-host mapping in some cases.
> As you explained yourself, it does NOT require ANY changes to the
> NAT devices.
Yes.. But I think I was pointing out that 'it will require modifications to
existing NAT implementations' sentence does not seem to quite apply in this
case.
> In the situations where the effect of NAT must be
> reversed, some additional functionality is needed and that can be
> implemented without any modifications to the NAT.
.. yes..
> I think you are
> thinking of merging this functionality with the NAT implementation,
> which is not the case.
(as far as the draft spoken about in 5.3 goes)
What I meant was that only NAT implementation which is _added_ (not
changed) is the NAT-merged-with-responder-end-IPsec (which _CANNOT_ be
separated, if transport mode support is desired in all cases).
Otherwise you are unable to support case where two initiators (behind
dynamic NAPTs) with same configured ip (10.0.0.1, for example) attempt to
converse with responder using transport mode.
Separate NAT wouldn't work because it couldn't distinguish between the
remote end entities as unique ip+port information would not survive the
decapsulation process in case of ICMP, for example.
The IPsec-merged-with-NAT is only needed if transport mode is desired, and
that does not seem to be common trend nowadays. Reasonable use of tunnel
mode would lead to unique IPs by using say,
<any-get-IP-across-tunnel-method like DHCP-over-tunnel-mode, config mode,
et al> or some static network address configuration.
-Markus Stenberg
(I hope the next version of that draft, which I will probably submit today,
is bit clearer on some points.. :-)
--
Simplicity does not precede complexity, but follows it.
>From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams
in Programming", by Alan J. Perlis of Yale University.
References: