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

RE: Towards closure on NAT traversal.



Hallam-Baker, Phillip wrote:
> The IESG should do no such thing. IPSEC needs to fix their
> protocol.

There is nothing wrong with the IPsec protocol in an environment that
doesn't include NAT (read IPv6 here).

>
> I am probably more aware of the extent of IPv6 deployment than
> you are. Yes it does exist, no the extend and pace of deployment
> does not support your argument that we can all wait for IPv6
> to happen.

Hard to believe, but I would never claim to be aware of everything that
is happening in the deployment space. If you are basing your perceptions
on the allocation rate for IPv6 prefixes to ISPs, you really don't
understand the implications of RFC-3056 or draft-ietf-ngtrans-shipworm.

>
> Having been part of the transitioning of a much smaller network
> from DECNET to OSI I think I have a more realistic understanding
> of what is involved.

Been there, done that (actually that was number 3 of network protocol
transitions), and never did get a T-shirt, but I do have a nice leather
case with DIGITAL on the side. :)  While that transition worked to some
degree in a limited enterprise context, the only way to pull it off in a
global multi-administration context would have been to preconfigure then
stage a global power outage.

The piece that is missing from the IPv6 deployment picture today is the
porting of applications to the new APIs. Since this will happen as
people attempt to 'shut up' the compiler that is bitching at them for
using an obsolete API, it is only a matter of time. If the IPsec WG
focused more of its energy into making sure the IPv6 deployability was
clean, than fighting a loosing battle where even the participants
acknowledge that the outcome will never be right, we would probably be
making more progress on getting app developers motivated in doing the
API port.

>
> The people who want IPSEC are often different from the people
> performing NAT attacks on them.

I don't understand your point. For IPsec to work, both parties have to
be willing and interested. If one of those parties puts up a NAT, they
obvoiusly aren't interested.

>
>
> This is sophistry. IPSEC needs to address the NAT problems
> that IPSEC introduces. MidCom is not about to go fixing IKE
> to work through NATs.

It appears your perspective of reality is simply backasswards. NAT is
the one introducing the problems to IPsec, there is nothing IPsec did
that caused a problem for NATs.

I would not wish fixing IKE on MidCom (independent of getting it through
a NAT), but the real issue is finding a generalized NAT traversal which
IPsec can use. If every WG does a one-off, it is less likely that any
given path will contain the right set of NAT hacks to make any
applications work.

>
> Again it is very clear that what you are really trying to do
> here is to kill NAT by some bizare IETF machinations. Won't
> work, been there tried that. All that approach would do is
> cause the vendors to diverge further.

No I am not trying to kill NAT, look at RFC-2993 if you still don't
understand. If I was really trying to kill off NAT, the first thing I
would do is spin up 50 WGs to create as divergent and demanding a set of
requirements for implementation as possible. In reality we have MidCom
trying to figure out a common set of requirements that make it
reasonable for NAT vendors to implement them. In that context, this
group should be feeding requirements to MidCom, and leaving the details
to others.

>
> I don't think that it is rational to expect NAT + IPSEC to
> provide greater connectivity than NAT alone. NAT reduces the
> functionality of IP, IPSEC + NAT currently eliminates the
> functionality of IP, the objective of IPSEC has to be to
> get IPSEC + NAT to give equivalent functionality to plain NAT.

Again, your perspective seems warped. IPsec + NAT doesn't eliminate the
functionality of IP, NAT eliminates the functionality of IPsec. This
thread has been about how to remove that blockage, which duplicates the
work of two other WGs. In those cases their charter is explicitly to
make it possible to get through NAT, while the charter here is to focus
on securing the communications path.

Tony