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


To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
cc: "'Randy Bush'" <randy@psg.com>, alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 08 Aug 2001 21:05:30 -0400
In-reply-to: Your message of "Wed, 08 Aug 2001 09:07:41 PDT." <2F3EC696EAEED311BB2D009027C3F4F40154CA5F@vhqpostal.verisign.com>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

> The principal benefit of NAT to many businesses is that it is a very
> effective means of cutting off approximately 80% of network security
> problems at a stroke. Less functionality is precisely what these users want.

Understood.  But very little of that security benefit is really due to NAT;
most of it is due to the fact that connections have to be initiated from
within.  That's certainly an artifact of NAT (actually NAPT) but it can 
be done just as easily without translating addresses.

> Rather than demanding that the network change to match the protocols it is
> time to accept the fact that for the next twenty years at least NAT is going
> to be a part of the infrastructure and look for ways in which that mode of
> use can be supported without denying the end user a substantial degree of
> functionality.

You may be right about NAT being here to stay.  Problem is, once you have 
a NAT in the signal path there's no way to repair the damage that has been 
done.  That substantial degree of functionality (not to mention reliability)
is inherently lost.

> Since the only part of a TCP/IP session that needs the external address is
> the initial setup, why not design protocols that allow that part to be
> delegated to a third party 'connection server'? 

Your premise is false.  TCP/IP doesn't need the external address at all; 
it's happy as long as each end sees consistent source and destination
addresses throughout the entire connection.  It's the applications that 
need globally usable and stable endpoint identifiers. 

> After all any personal
> presence type protocol will need some form of static server since the user
> will hop between devices even if the devices themselves had static
> addresses. The trick would be to find some way to get the NAT boxes to
> cooperate.

With this approach you need the NAT boxes to explicitly support
every protocol, and that makes new protocols difficult to deploy.

The alternative is to teach the NAT boxes to support 6to4, which
any v6 protocol can use.

But you make a good point about security.  If people get the idea 
(correctly or not) that they're sacrificing security by supporting v6,   
they won't bother deploying it.  We need to have v6 border routers
that deliver the same degree of security as NATs do, without actually
translating addresses.

Keith

Home | Date list | Subject list