Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 8 Aug 2001 09:07:41 -0700

NAT is here and will stay irregardless of what the IETF might want.

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.

On the home user front the popularity of NAT is increasing as people
discover that a $100 box from Frys allows them to plug four computers into
the home network instead of one.

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.

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'? 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.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 9:15 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary 
> 
> 
> [email-masked] said:
>   | Or accept the reality that enforcing PA as the 'only' 
> approach is  in
>   | direct conflict with the ultimate goals of the consumer.  
> 
> The ultimate goals of the consumer are surely to have a 
> stable internet
> connection that works, and allows all available services.
> 
> Or for many perhaps at an even higher level, to make lots of 
> money however
> it can be made, and care about very little else.
> 
> Very few ultimate consumers care at all about renumbering, 
> except to the
> extent that it interferes with one of the above real goals.   
> They care
> even less about the format of DNS resource records of course.
> 
> If renumbering is forced, and that causes problems, and NAT 
> seems to allow
> those problems to be avoided, then NAT is what people will 
> do.  Once NAT
> is seen as an inappropriate solution (which it will be once 
> people start
> wanting most of their systems to be available as servers, not 
> just clients,
> for at least some protocols) then they'll look to find 
> something else that
> works.   Geographic based addresses, with their likely 
> increased costs might
> be the solution.
> 
> Of course, if we can keep on working and get renumbering to 
> work so easily
> and cleanly that it ceases to be any kind of real cost, then perhaps
> enforcing PA won't be seen as being in direct conflict with 
> anything any
> more - as no-one (at the ultimate consumer level) will even notice it
> happening.
> 
> That's what we should be working towards, what's more, it should be an
> attainable target - there's nothing so complex about configuring an IP
> address that it needs to be seen as some kind of black art, to be done
> once and never repeated.  The only real problems are that with IPv4 we
> allowed the IP addresses to be configured everywhere, we assumed they
> were a fixture (more permanent that even a domain name, as they have
> essentially no vanity value) - and that has made the update process
> absurdly difficult.   We just need to make sure that everyone is aware
> that the only places an IPv6 address should ever be written are in the
> DNS zone files and in router configs for networks (and there, 
> in a form
> that router renumbering can update).   Anywhere else you're 
> ever tempted
> to enter an IPv6 address we need to find an alternative.
> 
> kre
> 
> 
> 
> to unsubscribe send a message to 
> [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2001 21:05:30 -0400

> 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.

> use can be supported without denying the end user a substantial degree of

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.

> 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

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 14:10:32 +0200

In your previous mail you wrote:

=> this is easy for TCP (or any connected transport, cf the tcp
established of Cisco routers) but I can't see a way to do this for
UDP without keeping state... Of course this argument doesn't apply
if a real firewall is used (stateless firewalls are out of the market
or should be ASAP).

Regards

[email-masked]