Subject: Re: Session survivability over renumbering, spoofing, address overloading.

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 03 Dec 1999 21:03:54 -0500

In message <v04220804b46d1ddf1bee@[10.19.130.188]>, Steve Deering writes:
> At 5:57 PM +1100 12/3/99, Peter Tattam wrote:
> >It's fascinating that there is a strong parallel between NAT and Virtual
> >Memory.
> 
> Peter,
> 
> You're not the first to make this observation.  Here's a part of a reply
> I sent recently to someone else who had the same "insight":
> 
There's another analogy that I pointed out on the NAT mailing list, one that 
carries a serious warning -- virtual memory is only useful when the working 
set is small enough relative the size of physical memory.  When there is too 
much demand for real memory -- by analogy, too much *need* for global 
addresses -- at any one time, the system thrashes and nothing useful gets done.

I've been using virtual memory for a couple of decades now -- and I haven't 
noticed machines shipping with less memory as a result.  Quite the contrary, 
in fact.

		--Steve Bellovin

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Peter Tattam <[email-masked]>
Date: Sat, 4 Dec 1999 15:41:52 +1100 (EST)

> noticed machines shipping with less memory as a result.  Quite the contrary, 

Good points...  I agree that NAT is analogous like the bank switching
concepts...  however, it is *also* analogous to a CPU system where a user
process typically loads its program at the same address. 

There are two reasons for virtual memory.  The main one is to use more memory
than is available.  The secondary one is for protecting processes from each
other and the kernel from the users.

Much of the problem with spoofing is a result of giving the user the ability to
use raw addresses, analagous to the unprotected process having access to
unprotected address space.

The biggest argument against NAT revolves around the argument of needing
end-end connectivity with real addresses.

Computer science is littered with instances of where machine mechanisms that
are too powerful need to be tamed.

Examples:

Gotos.
	have largely been replaced by structured programming

raw pointers
	still in use, but slowly being replaced by structured
	techniques like classes and languages like Java etc.

Unprotected Memory systems.
	mainly replaced by virtual memory for most(?) OSes.  There are still
	vestiges of unprotected address space on popular desk top OSes.

Multitasking synchronization
	semaphores were invented to help, and are still in wide use, slowly
	being replaced by better mechanisms like monitors.

I know this is right outside the charter of the working group, and I would have
to agree with the arguments that NAT is perceived as bad, however, we should
not ignore the lessons that the history of computer science has shown us.

Given that the internet is far wider reaching than it was originally designed
for, and has growing numbers of participants who no longer wish to subscribe to
the philosophy of mutual cooperation that founded it, don't you think it's time
to start thinking more carefully about some of the issues of protecting the
billions of users that will potentially be using it in the next 100 years.

We can't simply ignore the fact that thousands of NATs have been grafted into
the Internet, and this has already driven protocol development to the point
where end-end connectivity is not essential for the bulk of jobs done.  Joining
the NAT islands obviously needs public addressing to do the job.  Perhaps what
I am suggesting is that we need to work out techniques that wrestle the control
of who can transmit on a public address out of the hands of the potentially
hostile attacker.

Automatic ingress filters are one solution to the spoofing problem, NAT class
solutions are another.

I contend that the growing range of network attacks is likely the result of the
Naked Internet.  Let us hope that Ipv6 does not highlight the problem any more
than it is at the moment.

Peter

--
Peter R. Tattam
[email-masked] Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210

---

From: Steve Deering <[email-masked]>
Date: Fri, 3 Dec 1999 21:07:57 -0800

At 3:41 PM +1100 12/4/99, Peter Tattam wrote:
>                                                           ...we should

Trouble is, it is possible to come up with a lesson from computer science
to support any technical or architectural argument you care to make.
I learned this a few years ago in an animated debate over the design
of a multicast routing protocol, in which four people were arguing for
completely different and conflicting approaches, each supported by a
different computer science aphorism.

Anyway, I agree with your general point that making the Internet and its
users more secure from each other is vitally important, and that ingress
filtering is an important step in that direction.  However, I don't think
that having multiple entities re-using the same address space enhances
security at all.  (It *would* if there weren't any NATs between them,
but as soon as you join "private" address space with address translators,
you open a path between them and thus create security vulnerabilities.)
In fact, re-use of address space makes it *easier* for undetected
leakage to occur between addressing domains, because you can't recognize
"foreign" addresses.

Steve

---

From: Peter Tattam <[email-masked]>
Date: Sat, 4 Dec 1999 16:40:25 +1100 (EST)

> leakage to occur between addressing domains, because you can't recognize

Ok.  I concede defeat on this one.

I'd like to explore the possibility of automated ingress filtering though.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210