Subject: Re: (NAT) Host NAT issues and Security Policy Servers

From: "Mike Borella" <[email-masked]>
Date: Thu, 7 Jan 1999 11:36:53 -0600

This message reminded me of something I've been
thinking about for a while now.

There seems to be a need for a generic method with
which a host can "go out and get stuff" where
'stuff' is configuration info, policy info, security
info, addressing info, AAA, etc.  Most of the
interactions are pull, but some may be push.

Currently we have BOOTP/DHCP, RADIUS/DIAMETER/IPCP, COPS
and perhaps several others (e.g., IP telephony requires
similar components but the signaling is still being worked
out).  These protocols all try to be (or have been forced
to be) general and extensible.

In the continuing DNAT/HostNAT work, we are defining
yet another protocol, this one for passing info back to a
NAT-client.  While we will continue developing the
protocol because it will help us determine the parameters
that need to be supported in DNAT/HostNAT, it seems as
if this is getting redundant all over again.

Obviously, all of these are candidates for whatever RUTS turns out.

Thoughts and suggestions?

-Mike

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 07 Jan 1999 09:53:16 -0800

Mike

> Thoughts and suggestions?

It is quite obvious that there are more and more cases where a host
needs to "go out and get stuff" from a network, before the host starts
to use the network. Since there is a diversity of "stuff" that the host
could get from the network, one could use this as a justification for
more than one protocol. However, if this diversity has a fairly common
set of mechanisms, then perhaps one protocol (or a small number of
protocols) that implement these mechanisms should be the preferred
choice.

As a first step perhaps we should look at the mechanisms used by the current
protocols and see if there is enough commonality among these
mechanisms.

Yakov.
-

---

From: "Michael C. Richardson" <[email-masked]>
Date: Thu, 07 Jan 1999 13:13:59 -0500

>>>>> "Mike" == Mike Borella <[email-masked]> writes:
    Mike> Obviously, all of these are candidates for whatever RUTS turns out.

  RUTS may be fine for getting the info once you know where to get it from.

  In your HostNAT work, how do you determine if you need to do NAT or not?
What if there are multiple NAT gateways?

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
	ON HUMILITY: To err is human, to moo bovine.

-

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 7 Jan 1999 18:40:28 +0000 (GMT)

> if this is getting redundant all over again.

Bite the bullet with a NAT MIB?

L.

as if NAT isn't complex enough already.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

-

---

From: Rick Cobb <[email-masked]>
Date: Thu, 07 Jan 1999 10:46:02 -0800

I wonder if the server-location stuff mightn't be used here?  Seems
slow to me, but the drafts published yesterday about location of
name services (argh, 
http://www.ietf.org/internet-drafts/draft-ietf-svrloc-naming-directory-scheme-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-svrloc-nis-scheme-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-svrloc-nisplus-scheme-00.txt
) 
seem to presume that server location responses are somehow both
reasonably fast, and locally scoped.  I admittedly haven't done
my homework here -- in particular, I wonder how svrloc manages
that scope, and secondly, how one would discover e2e NAT boxes 
on the way to the discovery of the various services -- but 
it certainly seems more general than, say, RAS (gatekeeper)
discovery in H.323....  Guess it's off to do the homework.

-- ReC
Rick Cobb
WarpSpeed Communications

> 'unsubscribe nat' in the body of the message.

-- ReC

The sun sets over Lake Washington as the party winds down.  There are
lots of kinds of light, but only one darkness in the House of Bill.
						-- [email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 8 Jan 1999 09:59:01 -0800 (PST)

> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
A NAT management application could certainly address the configuration 
issues being raised here (host-NAT) and by other applications interfacing
with NAT. The elements of NAT that can be managed are identified in the 
NAT-API draft (<draft-ietf-nat-api-00.txt>).

Any volunteers to do the NAT MIB specification?

cheers,
suresh
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 8 Jan 1999 11:37:26 -0800 (PST)

Mike,

May I suggest we use a single term - "Host-NAT" to discuss Host-NAT 
issues. It is confusing to use 2 terms (DNAT and Host-NAT) describing 
the same thing. The NAT terminology draft uses "Host-NAT" term. Unless 
there are differences in semantics, I suggest retiring the DNAT term.
It is particularly important to converge on a single term, as you folks 
are embarking on a framework document. 

Thanks.

cheers,
suresh

-

---

From: Jeffrey Lo <[email-masked]>
Date: Fri, 8 Jan 1999 12:18:26 -0800 (PST)

Suresh,

On behalf of our group working on HNAT/DNAT documentation, may I suggest
that we use end-to-end NAT (e2eNAT) to replace HNAT/DNAT and to request
change to the terminology draft? This is because concepts of HNAT/DNAT
essentially involve delegation of NAT from NAT-Server to NAT-Client, where
NAT-Client could be either intermediate entity or end host. We have a
section detailing a cascaded scenario in our new draft. HNAT seems to
restrict the concept to end hosts.

Jeff

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 8 Jan 1999 12:55:53 -0800 (PST)

I have issues with the semantics you are assuming. 

First, Host-NAT does not mean that the Host-NAT client node is 
implementing NAT.  NAT is not delegated from the server to client.
It simply means it has an address (and port, optionally) that belongs 
to the same realm its peer belongs to. The address may or may not 
have been delegated by a NAT device. A NAT router enroute may simply 
be used to facilitate packet routing across and within realms.
Delegation of NAT  functionality is not Host-NAT. It simply is 
another NAT, like between 2 backup NAT devices.

Second, Host-NAT does not impose any behaviour on the parner nodes. 
I.e., there is no reason to believe that Host-NAT client will not 
be communicating with a NAT node on the other end. It could be.

I dont see how Host-NAT is restricting.  If we need to discuss this 
some more, I suggest, we do this off-line. Thanks.

cheers,
suresh

-

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 8 Jan 1999 22:03:44 +0000 (GMT)

> I have issues with the semantics you are assuming. 

Likewise, but for me semantics confusion set in rather earlier.

Since we're discussing choices of terminology, I'd just like to note
that I find _bidirectional NAT_ and _twice NAT_ as defined in the NAT
Terminology and Considerations draft to be easily confused terms. In
particular, _twice NAT_ leads me to ask what _once NAT_ is
supposed to be.

The draft needs to clearly define which variation of traditional NAT
is considered as one-way/unidirectional NAT, and contrast it with
two-way/bidirectional NAT.

'single NAT' and 'double NAT' are still available!

L.

who thinks of twice NAT as janus NAT - the gateway that looks both ways.

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 8 Jan 1999 15:10:50 -0800 (PST)

We had gone over this before with others. These were the best terms
we could come up with. 

Traditional NAT    ==> NAT Sessions allowed outbound only.
                       Header translation on a packet limited to src info 
		       or dest info, but not both.

Bi-Directional NAT ==> NAT Sessions allowed in both directions.
                       Header translation on a packet limited to src info 
		       or dest info, but not both.

Twice NAT          ==> NAT Sessions allowed in both directions.
                       Header translation applied to both src info 
		       and dest info. So, the translation here is 
		       twice that of Traditional NAT or Bi-Directional NAT.

We tried to say all of this clearly with illustrations in the draft.

Hope this helps.

cheers,
suresh

-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 1999 10:58:57 +0000

Well, since you raise it, let me say something that's been in my mind
for a couple of weeks.

I find it very confusing that H-NAT or D-NAT are called "NAT" at all.
There is no network address translation involved. What is happening
is a new form of dynamic address allocation, where the address
just happens to be allocated from a globally routeable pool of 
addresses.

As Vern Paxson has pointed out to me in private mail, the topology and
routing considerations are similar to those for NAT, but the address
has e2e significance, which means that many of the concerns about
traditional NAT don't apply. 

The role and potential of H-NAT/D-NAT would be much clearer if
renamed, to something with the flavour of Dynamic Global Adressing.

   Brian
-

---

From: [email-masked] (Pyda Srisuresh)
Date: Mon, 11 Jan 1999 08:52:54 -0800 (PST)

Brian,

Below is the rationale behind choosing the term "Host-NAT".

The goal of NAT (along with ALGs, in some cases) is to provide 
applicaion transparency for hosts across different realms. In that
sense, the intelligence necessary for providing this realm transparency
is centralized in NAT routers, so end nodes do not have to be realm 
aware. In other words, NAT is really identified with "realm-transparency".

With Host-NAT,  we are shifting the "realm-transparency" intelligence 
from NAT back to end-nodes that are realm-aware.

Lastly, some folks do feel that the term "Host-NAT" is intuittive in 
terms of how they can relate to what it does.

Together, I believe, these are the reasons behind chosing the term 
"Host-NAT".

Anyways, do let us know if you still feel this is a misnomer. I also 
invite you to offer other terms you think would better suit this. Thanks.

cheers,
suresh

-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 1999 17:06:51 +0000

No, in fact these arguments illustrate exactly why I think
the term is confusing and wrong.

Before we had private addresses, the network was indeed transparent;
that was the triumph of the catenet model invented in the 1970s.
Dynamic allocation of global addresses to hosts helps to restore
that transparency; this has absolutely nothing to do with
address translation. "H-NAT" is not NAT. 

  Brian

-

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 11 Jan 1999 12:15:06 -0800 (PST)

I agree with brian, and have expressed so before: calling *NAT* something which
goes to great lengths *NOT* to do NAT is very misleading. the moment you
do NAT, you lose. furthermore, one of the main advantages of NAT
(and one of the reasons we see more and more of it) is the fact that it
is transparent to the end node whose addresses are being NAT-ted.

hnat/dnat or nar are no longer transparent to the application.

in my draft, i suggested the term "negotiated address reuse", but as
someone pointed out, negotiation is not a requirement, as you can
use conventions to bypass that phase. furthermore, "address reuse"
is not a requirement either (the border box could have a pool of
addresses to dole out, none of which would get reused).

brian had suggested "dynamic global addressing" which to me implies
going from a private address space to a public address space (the internet).
in my mind, this is only one of the applications of these technologies.
you could do the reverse, or go from one private to another private
address space, it doesn't matter. 

essentially, a node in one address space temporarily acquires a virtual presence
in another address space (which may imply more than just obtaining or
reusing an address). so how about: virtual dynamic presence (or some such)?

this is my .01 cent (had to use the other one to pay for the new increased
postage).

-gabriel

-

---

From: John Bartas <[email-masked]>
Date: Mon, 11 Jan 1999 12:42:24 -0800

Hi all,

>in my draft, i suggested the term "negotiated address reuse", but as

	Pardon the Newbie question, but where can I find this draft? I searched
some interdraft draft achives a few weeks ago, but seem to have missed this
one. It's of interest to me, because I've been supporting a software packet
for a couple of years which combines NAT & a local DHCP server (of 10-net
addresses) to make an easy to configure branch office router. If there's a
standard emerging for this, I'd like to be aware of it.

TiA,

-JB-

-JB-

#############################################################
          H
(==)o(==) H John Bartas - Main Propeller head
   _I_    H InterNiche Technologies Inc. (408) 257-8014
  /   \   H 21801 Stevens Creek Blvd. Suite 5
  -----   H Cupertino, Ca. 95014
   O O    H [email-masked] (remove foo)
    "     H <http://www.iniche.com/>www.iniche.com
  \___/   H 

-

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 11 Jan 1999 20:48:42 +0000 (GMT)

On Mon, 11 Jan 1999, Gabriel Montenegro wrote:

>[..] 

"ghost addressing"? where the projections of the hosts in other
realms are viewed as ghosts?

L.

ghosts might be translucent, but not transparent.

-

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 11 Jan 1999 13:03:59 -0800 (PST)

> 	Pardon the Newbie question, but where can I find this draft? 

http://search.ietf.org/internet-drafts/draft-montenegro-aatn-nar-00.txt

-

---

From: Jeffrey Lo <[email-masked]>
Date: Tue, 12 Jan 1999 15:27:22 -0800 (PST)

This draft seems to have expired. Are you updating it?

Jeff

-

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 13 Jan 1999 11:38:36 -0800 (PST)

yes, i've resubmitted it just now. not
much different just some fixes and more details in the ipsec
section.

should appear soon as draft-montenegro-aatn-nar-01.txt

-gabriel

-