Subject: (NAT) comments on terminology draft

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 16 Sep 1998 17:23:08 -0700 (PDT)

comments on draft-ietf-nat-terminology-00.txt

Suresh and Matt,

Thanks for this draft, this is an area with a lot of variations, and
your effort is very welcome in order to clear things up. A general
comment: it would be great if you guys added references to some of the
NAT flavors. Some of them are hard to understand, and may seem like
pie in the sky unless a hard reference is provided to go off and
read some more.

In general, I think some of the discussion would benefit from 
having a simple model to refer to. I suggest using the
model suggested by Vipul Gupta and used by the negotiated address reuse
draft (draft-montenegro-aatn-nar-00.txt), perhaps reusing some of the
terminology in the latter as well. For a diagram of the model, please
refer to:

   http://playground.sun.com/~gab/talks/nar-ietf42/sld004.htm

2.1.1. Session flow vs. Packet flow

	There is no real definition of what a "session" is, only the
	difference with "packet flow". It seems that for tcp, your
	assumption is that a "session" is equivalent to a tcp
	connection. Is this it? For non-tcp traffic you do mention
	that the definition of a session is application dependent.

2.1.6. Private/Local network

	Implies that these connect via a NAT to the global network.
	Not always true. *MAY* connect via a NAT is more like it.

	Also, I don't agree that a "local" network is equivalent to
	a "private" network. A local network may be so because of
	security considerations not because it uses rfc1918 addresses.

3. What is NAT?

	You say all NAT flavors share some transparency characteristics.
	Some of the stuff that follows may require breaking the transparency
	requirement, which according to how I understood this section, would
	mean it is no longer a NAT flavor. More below.

4.2. Two-Way NAT or Bi-directional NAT

	I'm trying to see what exactly it is that this offers in addition
	to "Traditional NAT". From section 4.1 on Traditional NAT:

	"Sessions in the opposite direction may be
   	allowed on an exceptional basis using static address maps for
   	pre-selected hosts."

	So the only additional function in Two-Way NAT is that in addition
	to static address mappings, it may be possible to establish them
	algorithmically. Is this it? If so, the only difference is in the
	address binding phase. Why not call it a different address binding
	phase instead of calling it an entirely different NAT flavor?

4.3. Twice NAT

	I don't think this would work if both routing realms are mutually
	non-routable (because the routing fabrics ignore paths to each
	other, or because some address space range(s) is (are) being
	used in both routing realms at the same time). According to
	your definition:

   Twice NAT is a variation of NAT in that both the source and
   destination addresses are modified by NAT as a datagram crosses
   routing realms.                           ^^^^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^

	That's the whole point: the routing fabric in one realm will
	choke (under mutual non-routability) when entrusted with 
	delivering a packet to the other routing real. It will simply
	drop it and return an icmp unreachable to the sending host. 
	Alternatively, if the destination address belongs to an
	address range in use within both routing realms, the routing
	fabric will simply attempt delivery within the local realm.
	It is possible to guarantee delivery to the other routing
	realm. But given that the routing fabric cannot be trusted,
	the sending host must explicitly direct the packet towards
	the NAT box at the border. This means one 

6.0. NAT operational characteristics

	You say:

	"However,
  	 end-to-end IP network level security assured by current IPsec
   	techniques is not possible, as NATs modify the IP header
   	contents in transit."

	If by "NAT" you mean translation of an IP address, I disagree
	somewhat here. Address translation is still possible if the
	variant of IPSEC being shuttled across the border is
	Tunnel mode ESP. However, it is not possible if it's either
	AH (any mode) or Transport mode ESP, as these provide cryptographic
	protection of some fields in the outer IP header (including
	IP addresses).

	Assuming that a reasonable mapping is in place, it is possible
	to translate the outer IP addresses of a Tunnel mode ESP packet.

	In order to establish such a "reasonable mapping", one would
	probably have to break transparency at some point. Hence, if you
	mean "transparency" when you say "NAT" above, then you're right,
	I don't believe one can transparently accomplish it. However,
	aatn (nat alternatives) aims at but does not require transparency,
	so it seems possible to solve this problem there.

	Please refer to;

	   http://playground.sun.com/~gab/talks/nar-ietf42/sld006.htm

tnx,

-gabriel

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