Subject: Re: (NAT) Host NAT issues

From: [email-masked] (Gabriel Montenegro)
Date: Mon, 7 Dec 1998 10:01:10 -0800

"Mike Borella" <[email-masked]> wrote:

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

May I add one more to the list of proposals that share the above
characteristics:

Negotiated Address Reuse (NAR). 

>
>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 NAR draft talks about how to do ipsec and ip tunnels (including
mobile ip tunnels). It was presented in chicago:

http://www.ietf.org/proceedings/98aug/slides/mobileip-montenegro-slides-98aug/index.html

I have also posted some comments to ipsec on where i see some issues here, in
particular, IKE requires the source and destination port to be fixed, which
does not allow the NAR/NAT box to map those ports to others in typical
NAT fashion.

I've added these comments and others to an updated version of the draft which
did not make it out before the I-D deadline (if anyone's interested,
just email me).

>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

fyi, the first two section in nar are a  general
framework based on a very simple but general model of
two address spaces with a border control box in the middle
as the basic building block.

The last section details how one would go about
negotiating the required stuff using SOCKS *extensions*, but the general
framework stuff does not, of course, depend on this decision.

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

I sit typing this msg in the RUTS BOF, and I think this topic is terribly
relevant. I do agree that we need a generic "border control" mechanism.
I went the track of extending SOCKS for that (and presented it in the
STP bof in Chicago). Both of you guys decided on UDP, but I've seen email
on DNAT that would indicate that perhaps some of the reliabiility of TCP
would have been useful. This is exactly the same decision point other
folks are in: COPS, L2TP (udp), PPTP (tcp), nfsv4, radius (udp),
diameter (udp, but extensions for reliability), HTTP, 

basically, in all these control protocols, it seems like what
is needed is something in between udp and tcp, and if this RUTS
bof ends up forming a WG, and producing a lightweight ruts
protocol, I would strongly suggest we build our "border control"
protocol on top of that.

-gabriel

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