Subject: Re: (NAT) Host NAT issues

From: "Mike Borella" <[email-masked]>
Date: Sun, 6 Dec 1998 20:39:38 -0600

Jeff,

The framework that is used by DNAT, and now host-NAT, consists of several
fundamental ideas:

- Tunneling between a router or device with a public IP address
     and an end host.
- Using TCP/UDP ports or some other mechansim  or combinations
     thereof to uniquely identify hosts from the private address
     space.
- Assignment of global IP addresses to hosts for them to use when
     talking with the outside world.

In proposing DNAT, our goal was to allow end-to-end communication
through a NAT box.  As it turns out, it is in theory possible to get
end-to-end
IPSEC working with DNAT as well as Mobile IP.  The fact that this framework
can be extended to support the services that host-NAT offers attests to its
power.

The PDP was meant just to distribute port numbers.  Nothing else.  In our
way of
thinking, assignment of an IP address or other parameters to a host might
as well occur using an existing extensible protocol, such as DHCP or as
part of a
tunnel establishment, rather than reproducing existing functionality.
These
parameters may require renegotiation.  See the "Perspectives"
section of the DNAT draft for a discussion of this.  The PDP is not
limited in any sense.

I recently started writing a draft about the general framework of
end-to-end
communication through a NAT, listing the issues that any solution must
address.  Here are some of the most relevant issues:

- Unique Determination of Local Destination Address
- Negotiation and/or Specification of Demultiplexing Fields
- Assignment of Parameters to Hosts by Some Device
- Tunnel Use and Establishment

There is more than one solution to each of these issues, leading to some
number of possible DNAT-like implementations, each of which
are probably incompatible with the rest.

In terms of where this should go within the IETF, I think that both the
DNAT and
Host-NAT drafts are too specific in how they describe solutions to the
end-to-end issues.  Perhaps what is needed is a generic end-to-end
NAT solution with UDP-based setup and negotiation between the hosts
and router or some other device.  Using attribute value pairs, arbitrary
parameters could be  set up and negotiated through a "control channel"
with a much more flexible packet format.  This approach may re-invent
the wheel to some respect, but it would be far more general than what
we currently have.

-Mike

Jeffrey Lo <[email-masked]> on 12/04/98 04:21:58 PM

To:   Mike Borella/MW/US/3Com
cc:   [email-masked], David Grabelsky/MW/US/3Com, Ikhlaq
      Sidhu/MW/US/3Com
Subject:  Re: (NAT) Host NAT issues

Hi,

This is sent in response to a recent comment about HNAT draft proposed to
NAT workgroup.

We are particularly interested larger scale deployment of private
addressing. A case where a band of global IP addresses are managed by the
address manager, which may or may not reside on the Host-NAT-Server. We
realised the existence of DNAT draft and attempted to apply Port
Distribution Protocol (PDP) proposed in draft-borella-aatn-dnat-01.txt in
our scenario. It is during this attempt that we find PDP insufficient and
does not support dynamic global IP address assignment. Hence our primary
motivation is to propose a more generic protocol that serves a
greater majority of the NAT community. As a result, we are proposing
Dynamic Bindings Acquisition Protocol (BDAP). Having said these, we do not
deny the fact that DBAP support port assignment as well and could be used
in places where PDP is used.

Another motivation for our draft is the fact that we feel PDP lacks many
important features which are fundamental for larger scale operation. We
don't see our differences as being minor but rather fundamental. To state
some of the differences:

Error Reporting
It is important for accurate error reporting so that Host-NAT-Clients know
about source of error. For example, is a request denied due to resource
reasons, policy reasons or other miscellaneous reasons. This is not
possible with PDP.

Max. Leased Time
It is important for Host-NAT-Client to be able to negotiate a lease time
interval with Host-NAT-Server. This is especially important in scenarios
where address management and NAT are performed by different authority.
One example is the case when private addressing is adopted by an ISP and
it wishes to delegate global address lease on an enterprise basis. In
this case, Host-NAT-Clients deamons may not be situated in end host but
may be some access routers. In this case, such global leasing may be
directly
connected to billing. In the current PDP, it is  unclear how this is done
apart from some default interval pre-selected during  configuration.

BindID
This is vital for both efficient indexing and serves as an identifier if a
Host-NAT-Client requests for more than one binds from a Host-NAT-Server.
For example, we know that IPSEC ESP does not work with NAPT, a
Host-NAT-Client
may be using a port range for IPSEC AH. When an application is started
requiring ESP security, a global address needs to be acquired. BindID is
required to correctly identify bindings on Host-NAT-Server. It
seems to us that PDP only supports a single port range bind at
this moment. Although not a major motivation, BindID also introduces a
layer of protection against security attacks.

If you have some ideas or implementations that suits our purpose, we would
be glad to hear about it. We feel that it is unfair for the authors to
claim something that has not being documented.

Thanks.

Jeff

On Thu, 3 Dec 1998, Mike Borella wrote:

>
>
> A couple of notes regarding the recent host NAT draft:
>
> - We presented distributed NAT (DNAT) at the Chicago IETF in the
>   ngtrans WG.  Host NAT is DNAT with only some very minor modifications.
>   Interested parties should look at:
>
>
http://search.ietf.org/internet-drafts/draft-borella-aatn-dnat-01.txt
>
> - DNAT has been implemented (from the draft description) by a third
party.
>   It works quite well.
>
> - The draft makes some incorrect comments about DNAT.  In particular,
>   the authors claim that DNAT does not allow the sharing on multiple IP
>   addresses, but it does.  This misconception seems to be the motivating
>   factor of the (very minor) differences between DNAT and host NAT.
>
> In case it isn't obvious, my point is that this scheme has already
> been proposed and presented at IETF.  I do not think that host NAT is
> significantly different from DNAT, though I'll happily entertain
> arguments to the contrary.
>
> -Mike
>
>
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.
>

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 1998 20:32:19 -0500

-----BEGIN PGP SIGNED MESSAGE-----

  [I'm going to appologize in advance for cross posting so widely.
I'm feeling a bit like every working group I attend is dealing with
the same problems. 
  I also, due to fog, missed both nat and aaa this morning. I heard
the aaa BOF didn't arrive at any clear conclusions, and I'm glad there
wasn't a fire drill during the NAT meeting or someone might have been
trampled. ]

    Mike> Jeff,

    Mike> The framework that is used by DNAT, and now host-NAT,
    Mike> consists of several fundamental ideas:

    Mike> - Tunneling between a router or device with a public IP address
    Mike> and an end host.

  DNAT specifically supported IPsec tunnelling to the NAT device. This
is important to a number of environments where they actually want
authenticated outbound firewall traversal.

    Mike> - Using TCP/UDP ports or some other mechansim  or combinations
    Mike> thereof to uniquely identify hosts from the private address
    Mike> space.
    Mike> - Assignment of global IP addresses to hosts for them to use when
    Mike> talking with the outside world.

  I want to note that this problem is essentially *IDENTICAL* to do
the IPsec road warrior configuration problem. It is also a variation
of the problem that Luis et al. designed their security policy system to
solve. (draft-ietf-ipsec-sps-00.txt coming to a draft directory near
you. I don't have the URL handy right now)
  
    Mike> The PDP was meant just to distribute port numbers.  Nothing
    Mike> else.  In our way of thinking, assignment of an IP address
    Mike> or other parameters to a host might as well occur using an
    Mike> existing extensible protocol, such as DHCP or as part of a
    Mike> tunnel establishment, rather than reproducing existing
    Mike> functionality.  These parameters may require renegotiation.
    Mike> See the "Perspectives" section of the DNAT draft for a
    Mike> discussion of this.  The PDP is not limited in any sense.

  The SPS policy server could well assign numbers.
  And yes, DHCP could do it. This was suggested for client
configuration in the road warrior case. 
  In addition, extensions to ISAKMP are being suggested to do client
configuration.

    Mike> I recently started writing a draft about the general
    Mike> framework of end-to-end communication through a NAT, listing
    Mike> the issues that any solution must address.  Here are some of
    Mike> the most relevant issues:

  I want to point out that IPsec security gateways are essentially
stateful routers. Alas, we reinvent ATM! As such, the end-to-end
issues with NAT and with IPsec are essentially the same. (ignoring the
fact that NAT and IPsec often sit on the same box)
  As far as I'm concerned, the IP address in protocol problem typified
by FTP, IRC (dcc), RealX, is less of a problem. These problems are
simple and easily solved both at the NAT stage (after protocol design)
and at the protocol design stage. But, getting rid of IP addresses in
the TCP data flow doesn't solve anything: The question that should be
asked by the IAB is does ICMP work through a NAT/IPsec box. 

  The real issue is not, can NAT work in the presence of end-to-end
IPSEC (DNAT and host-NAT are existence proofs that it is possible
to do something), nor is the issue that IPsec makes traditional NAT
hard to do, but that IPsec and NAT both introduce stateful
routing. diffserv tries to not introduce more state.

  I think, the model that we have essentially converged upon in IPsec,
NAT, diffserv, intserv, rap, aaa, qos... is of the end host going out
to the network *policy* server and saying: "I'd like to do X"
  The policy server responds and says: "I'll let you do X, but to do
so you will have to perform the following things: A, B, C."
  If I'm not mistaken (and I probably am, since the closest I ever got to
an actual telephone switch, a DMS100, was when I once fixed the test
guy's lab Xterminal many years ago), SS7 provides similar types of
conversations.  
 
  To recap, there are multiple protocols (or proposals) so far for
carrying questions from the end systems to the intermediate systems:
	1. RSVP 
	2. ISAKMP 
	3. host NAT, DNAT, DHCP
	4. router/prefix discovery stuff in v6.
	5. BBN's SPS protocol
	6. SOCKS
	7. ARP, ND

  [You may think that ARP doesn't belong, but I think that it does
because it is something that one does prior to sending a packet to the
node in question. There is no IS unless you consider a bridge to be a
layer 2 IS]

  From intermediate systems to policy servers we have:
	1. COPS
	2. SPS
	3. radius
	4. AAA
	5. did I miss something?

  A significant thing about the SPS work is that it operates both from
ES to IS, and from IS to IS, and from IS to policy server. In
addition, it permits *discovery* of IS systems and associated policy
servers in the forwarding path, which isn't something that I see in
the other protocols.
  I would like to see COPS and SPS merged somehow, and I wonder if
this can provide the common AAA protocol, as well as the common
DNAT/host-NAT, IPsec tunnel end point discovery, ... protocol. I don't
know what this does to RSVP in the diffserv border router model.

  hmm. Pizza is here.

]              At IETF43. Continental sucks                     |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 07 Dec 1998 18:50:09 -0800

>wasn't a fire drill during the NAT meeting or someone might have been

Sorry to reply to such a cross-post, but I didn't want anyone to read this
and think that we had a NAT meeting. NAT did not meet today and will meet
as scheduled, Wednesday at 1pm.

Matt Holdrege		http://www.ascend.com	[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Dec 1998 11:59:54 +0000

Just replying to NAT list:

I want to observe that e2e IPSEC and e2e NAT share an annoying
characteristic: you have to modify the software in the hosts.

If NAT has an advantage, it's the same one as gateway IPSEC:
you only have to put the magic in the gateways. That's why 
traditional NAT has been fairly widely deployed. Figuring out
how to live with traditional NAT is a very different game from
trying to deploy DNAT/HNAT/whatever.

Michael Richardson wrote:
...
> routing. diffserv tries to not introduce more state.

They introduce state, but I don't see how it can be called
stateful routing. It's more like call state. By the same token,
traditional NAT and gateway IPSEC introduce single points of
failure.

Diffserv also may cause state to be created at certain boundary
nodes such as classifiers and shapers; it's stateless in the
core.

   Brian Carpenter
-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 1998 17:05:55 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Just replying to NAT list:

    Brian> I want to observe that e2e IPSEC and e2e NAT share an
    Brian> annoying characteristic: you have to modify the software in
    Brian> the hosts.
  
  This is, in my opinion, why there is no point in providing *any*
help in IPsec for traditional NAT. Similar arguments apply to all the
things that IPsec makes hard (diffserv in particular comes to mind).

    Brian> If NAT has an advantage, it's the same one as gateway
    Brian> IPSEC: you only have to put the magic in the
    Brian> gateways. That's why traditional NAT has been fairly widely
    Brian> deployed. Figuring out how to live with traditional NAT is
    Brian> a very different game from trying to deploy
    Brian> DNAT/HNAT/whatever.

  Agreed. 

    Brian> They introduce state, but I don't see how it can be called
    Brian> stateful routing. It's more like call state. By the same

  If I don't route my packets back to the same border router, they
don't work. I, as a host, must always send the same packets in the
same direction. I can not fail over to another route that I learn via
BGP, etc.

    Brian> Diffserv also may cause state to be created at certain
    Brian> boundary nodes such as classifiers and shapers; it's
    Brian> stateless in the core.

  Yes. This is why diffserv wins where RSVP failed because it is clear
how to put some state in IS at the borders, and ideally, move it all
the way back to the ES. DNAT/host-NAT does the same thing for NAT.

]              At IETF43. It's sure humid.                      |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-

---

From: Jeffrey Lo <[email-masked]>
Date: Tue, 8 Dec 1998 20:59:13 -0800 (PST)

Mike,

> - Tunnel Use and Establishment

Sorry for the short delay in replying to this email. Yes, a framework
document is needed.

> the wheel to some respect, but it would be far more general than what

I agree that some form of "control protocol" would be necessary. That's
what we have been trying to drive at. In particular, the following issues
should be considered.

1. Built on existing protocol (DHCP, ICMP, COPS??)
   Is there already something in the existing protocols that we can
   exploit or do we absolutely have to build from scratch? 
2. Generality
   Where should the line be drawn? How much do we want the protocol to do?
3. Extensibility

In the context of HNAT/DNAT, the protocol should enables the following.

1. Acquisition of multiplexing fields
   Global IP address, TCP/UDP port, Protocol ID 

2. Negotiation of tunnel types
   A default tunnel type could probably be chosen

3. Negotiation of HNAT related parameters
   Max Lease Time, NAT Type

4. Registration of client agent and specification of client type
   Client ID assignment

5. Subnet enquiry?
  
I think using a common control protocol like this would ensure
interoperability. 

Framework and protocol should probably be addressed in separate documents.

Thanks.

Jeff

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 28 Dec 1998 14:29:47 -0800 (PST)

Hi,

Sorry to be late on this thread. Still catching up with my e-mail
after the IETF.

I mostly agree with the observations in your e-mail below. But, I would
like to add a couple of comments.

1. Clearly, an IP packet traversing the Internet is subject to Policy 
   based networking. There are a variety of policies in place. IPsec, 
   QOS, NAT, firewall, BGP etc. to name a few and many of these policies
   require some kind of state on the enforcement nodes.
   
   At the same time as policy based networking is becoming pervasive, 
   there is growing desire to make end-nodes smarter and network/policy 
   aware. To that end, the SPS draft identifies a mechanism to offer 
   policy service to end nodes and intermediate nodes alike. 
   
   However, SPS is only a policy server, not an enforcement point.
   You do need protocols and enforcement points that execute specific
   policies. In particular,  a Host-NAT protocol that can be used by 
   private hosts to attain temporary external address to connect to
   external nodes is required.

2. There are parallels between Host-NAT and Mobile-IP. I agree. 
   But, there are many differences. The goal of Mobile-IP is to preserve 
   home-address based connectivity as a node roams outside its network. 
   To that end, a MN uses a temporary Care-of-Address to tunnel home-address 
   based end-to-end packets to HA.  The goal of Host-NAT, on the other hand, 
   is to facilitate end-to-end packets without requiring translation enroute. 
   To that end, a Host-NAT-client uses temporarily assigned external 
   address to frame end-to-end packets (not to encapsulate in).
   
   Unlike Mobile-IP, Host-NATs deal predominantly with private address 
   spaces. In the case of Host-NAPT, multiple private nodes share the 
   same global address with different TCP/UDP port. 

   Also, Unlike a Home Agent (HA) node in Mobile-IP, a NAT node serving 
   as Host-NAT server does not need to be a tunnel end point to route 
   end-to-end packets within private realm. (Ref: NAT Terminology draft for 
   alternative forms of Host-NAT operation). 

3. I also agree with Brian Carpenter's observation (in a follow-on
   e-mail) that Host-NAT, Mobile-IP, IPsec and other end-to-end
   preservation softwares share the characteristic of requiring mods 
   to host software (unlike traditional NAT).

cheers,
suresh
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
> 
> iQBVAwUBNmyBlx4XQavxnHg9AQH2AgH/f5ltwjZS94Tiw3z8fJReRyBJXCiypQbX
> si7pz5NxK+TnQxj5DwmeJydFAxd8hTaYhEzA7eSLyPa7zn0B34MZQg==
> =IusE
> -----END PGP SIGNATURE-----
> -

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 28 Dec 1998 16:09:03 -0800 (PST)

Mike, Jeff, Gabriel et. al,

Host-NAT framework/requirements draft is fine. The goal is to find, 
design or converge on a protocol that enables Host-NAT operation. 
Jeff has apparantly identified some requirements in the e-mail below
and in his HNAT draft. So did Mike and Gabriel in their respective 
DNAT and NAR drafts. There is some commonality amongst the three drafts. 
There is also plenty of room for making the requirements firm.

I suggest gathering requirements specifically for Host-NAT and Host-NAPT. 
If the resulting protocol happens to have wider applicability beyond
Host-NAT, that is fine. But, wider applicability in itself should not 
be the goal.

The NAT-API draft has requirements/framework for wider applicability
(including ALGs, Host-NAT clients and management applications) as far as
NAT interfacing is concerned. I suggest, you take a look at 
(a) NAT Terminology draft, and (b) NAT API draft for some additional 
thoughts.

Have a nice day.

cheers,
suresh

-