Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 19 Jul 2005 14:33:21 -0700 (PDT)

> -----Original Message-----
> From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] 
> Sent: Tuesday, July 19, 2005 5:11 PM
> To: Senthil Sivakumar (ssenthil)
> Cc: Behave
> Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh
> 
> On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote:
> > You could definitely have an
> > implementation that does not use any bindings, so the end 
> user could 
> > get a different address for every session
> 
> It is not as simple as that. What behave-udp currently requires is:
> 
> - you MUST get the same address for every "session" as long 
> as there is
>   even one live session from the same internal endpoint.
> 
> behave-udp does not say what happens after all live sessions timeout.
> you may or may not get the same address, say a couple of 
> hours after the last session expires. That is what "bindings" 
> proposal mandates. In particular, the binding requirement 
> translates to:
> 
> - you MUST get the same address for every "session" as long 
> as there is
>   even one live session from the same internal endpoint. 
>   (same as behave-udp)
> - in addition, you MUST get the same address for a new 
> session initiated
>   within some time-window since the last live session expired.
>   (where the time-window is defined by the so-called binding-timer)
> 
> So it is not true that if you do not use binding then you get 
> a different address for every session (see the Linux mail earlier). 

How did you know you have to give the same address to the same endpoint?
You have to maintain some information that this endpoint was assigned
this address for a previous session. This is what I call as binding. You
want to call it something else that is your call. 

I just wanted to point out that there are bindings and there are binding
timeouts. I don't understand the point of this discussion whether
bindings should exist or not? Do we want to recognize that there are
bindings and recommend a timeout? If no, vendors will implement their
own timeouts just like today. If we don't want to recongize bindings
should exist and hence binding timeouts are not needed the vendors who
have implemented bindings will just ignore the recommendation and stick
to their implementation. 

Senthil

> 
> The first and foremost concern everyone has -- that 
> concurrent "sessions" from the same internal endpoint all get 
> the same address -- is explicitly handled by both proposals. 
> 
> --
> Saikat
>

---

From: Saikat Guha <[email-masked]>
Date: Tue, 19 Jul 2005 14:56:41 -0700 (PDT)

> want to call it something else that is your call.

By binding, I am referring to the binding definition in behave-gen. I
agree with you that "some information" needs to be maintained -- and may
be stored in as binding entry (the (a) entry in suresh's example
earlier), or may be stored redundantly in the per-connection 7-or-more-
tuple that Linux has (see earlier post).  

This difference in implementation is abstracted by "mapping" as defined
in behave-udp but it is not abstracted by "binding" and "binding timer"
as defined in behave-gen. That is all this discussion is about -- what
to call it. 

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 20 Jul 2005 06:22:20 -0700 (PDT)

> want to call it something else that is your call. 

[suresh] Well said, Senthil. The key is recognizing Binding as a NAT resource
and not getting caught up in implementation details of how Binding is
implemented in Linux. 

> have implemented bindings will just ignore the recommendation and stick
[suresh] Good point. I agree. The Behave drafts will become irrelevant if they
dont address what is basic to NATs. Vendors will do what they choose to do and
simply ignore the Behave recommendations. 

cheers,
suresh

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 20 Jul 2005 06:50:50 -0700 (PDT)

> tuple that Linux has (see earlier post).  
[suresh] Saikat - You continue to bring up implementation issues and mix them
up with the implementation-independent stuff.  What Senthil is refering to and
what I had alluded to in the past is that "Binding" is a different type of NAT
resource than "NAT Session". Some implementations may use different data
structures, one for Binding entries and another for NAT Sessions; and others
(as in Linux) may choose to use the same data structure to store the Binding
entries as well as the NAT Sessions, or have ways to derive Bindings out of NAT
Sessions if they donot implement non-zero Binding timeouts. But, that is an
implementation detail, and not relevant to the discussion. 

Are we in agreement that a NAT device needs to maintain the equivalent of
"Binding", and "NAT Session" entries?
 
> as defined in behave-gen. That is all this discussion is about -- what

[suresh] The differences in implementations are abstracted by the two terms -
"Binding" and "NAT Session". "mapping" is not an abstract term. By using the
term "mapping", behave-udp is not able to distinguish between idle timeout for
a Binding vs. an idle timeout for a NAT Session. 

In other words, I do believe, the behave terminology must not assume specific
implementations and use terminology that is implementation neutral. "Bindings"
and "NAt Sessions" are implementation independent. These are the terms used n
NAT-MIB (RFC 4008)

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Thu, 21 Jul 2005 13:26:29 -0700 (PDT)

> "Binding", and "NAT Session" entries?

The "equivalent of", yes. Drawing an explicit distinction between
"binding" and "session" is unnecessary. The "mapping" captures the
_equivalent of_ bindings and sessions as you seek. 

> By using the

As you yourself said, the terminology doesn't need to capture anything
and everything that NATs do today. It just needs to capture enough to
remove the non-determinism we care about. In particular, behave-udp does
not care about how ports are allocated long after *all* mappings for an
internal endpoint expires. If you feel that it should, I am sure
everyone would appreciate a concrete example where bindings and binding
timers allow an application to work where it would not otherwise given
the mapping terminology.

In particular, consider that a session timeout of 5 minutes and a
binding timeout of 5 minutes, is abstracted away with a mapping timeout
of 10 minutes. So it is not true that more timers make it more general.

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 22 Jul 2005 13:03:16 -0700 (PDT)

> _equivalent of_ bindings and sessions as you seek. 

[suresh] Saikat - "Binding" and "NAT Session" are distinct NAT entities. A
single term "mapping" cannot mean "Binding" in one context and "Nat Session" in
another context. 

> remove the non-determinism we care about. 

[suresh] Sure.

>                                           In particular, behave-udp does

[suresh] Here is an example with DNS ALG, where an idle timeout for an Address
Binding is required independent of the idle timeout for associated NAT
Sessions.

1. Say, the NAT device is configured with an address map as "10.0.0.0/8 mapped
to 198.76.29.0/24". 10.0.0.0/8 is the private domain and 198.76.29.0/24 is the
external address pool for assignment by the NAT. Say, the DNS Server for the
private domain is inside the private domain and NAT has a static Binding for
the DNS Server to direct DNS queries from external domain to the DNS server and
vice versa.

2. Say, an external host (Host-Y) needs to run an application with "Host-X".
Say, Host-X is inside the private domain bearing an address of 10.0.0.7. Host-Y
firt initiates a DNS query for "Host-X".

3. NAT redirects the DNS query to the DNS Server inside the private domain.

4. DNS Server responds with an A type RR for Host-X with an IP address of
10.0.0.7. 

5. The DNS_ALG would intercept the response packet and request the NAT to
create an Address Binding for 10.0.0.7. Say, the NAT created an Address Binding
to Bind 10.0.0.7 with 198.76.29.1. DNS-ALG would use the Binding to replace
10.0.0.7 with 198.76.29.1 and redirect the response packet to the external
host. 

At this point, until Host-Y initiates the application with Host-X, the NAT
device will not have any NAT Sessions using this Binding. The Binding will
however stay alive and not expire until the idle timeout setting. 

> of 10 minutes. 

[suresh] That is an implementation choice, though not advised. The above
implementation choice is possible only in some cases with UDP NAT Sessions.
But, it would be wrong to do this with TCP NAT Sessions. TCP NAT sessions have
distinct connect, runtime and closing states. So, it woudl be a security
violation to keep the TCP NAT Session alive much after the end-2-end session
expired in one of "connect phase" or "Closing phase", just to keep the TCP Port
Binding alive.   
 
>                So it is not true that more timers make it more general.
>

[suresh] Please see my notes above. You do need two idle timers.

Idle timeout for Binding is somewhat akin to what DHCP does after lease expiry.
DHCP servers often retain an IP address association with a PC's MAC address for
a period of time, even after the lease had expired. Some NAT devices retain
Bindings for longer duration even when there are no NAT Sessions using it.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Mon, 25 Jul 2005 18:29:05 -0700 (PDT)

> Binding is required independent of the idle timeout for associated NAT

Equivalently, the NAT can create a "mapping" when the DNS query is made
and can associate the mapping timer with it.

That said, the implementation of ALG's is out of scope of this draft. If
the NAT needs to implement bindings to support the DNS-ALG, it is
welcome to do so.

> a period of time, even after the lease had expired. 

Agreed. Can you point me to a RECOMMENDATION or a MUST clause that asks
DHCP servers to do so?

> Some NAT devices retain

... and they certainly are more than welcome to continue to do so.

-- 
Saikat
Attachment:
signature.asc

---

From: Karlheinz Wurm <[email-masked]>
Date: Tue, 26 Jul 2005 01:32:36 -0700 (PDT)

Hi everyone,

I am new in the B E H A V E mail group and want to support it with all 
the necessary research. It would be nice if someone can give me a quick 
briefing in what work are already done and what research still have to 
be done.

My special interest is in symmetric NAT 's or bad behave NAT's. I want 
to find out, how the different NAT vendors allocate there ports in order 
to create a common pattern and get a better port "prediction" for the 
hole punching process. Maybe there is already some work done. I would be 
very thankful for any kind of source in this topic.

Hope we can get some work done.

regards,

Karlheinz Wurm

---

From: Saikat Guha <[email-masked]>
Date: Tue, 26 Jul 2005 02:21:22 -0700 (PDT)

Hi Karlheinz,

Glad to have you onboard. Below is a collection of links to get you
started. The UDP NAT standards draft is nearing consensus (hot on the
mailing list), a bunch of TCP drafts and measurement studies are
available and work on multicast standardization has just recently been
started. I believe, some ICMP behavior has been moved out of UDP draft
and is search for a new home. 

On Tue, 2005-07-26 at 11:34 -0700, Karlheinz Wurm wrote:
> a quick 

Mail archives: http://list.sipfoundry.org/archive/ietf-behave/

and a really old status update: 
  o http://list.sipfoundry.org/archive/ietf-behave/msg00311.html

UDP:
- WG draft: draft-ietf-behave-nat-udp-03.txt
- Some research/measurements:
  o draft-jennings-behave-test-results-01.txt
  o http://www.brynosaurus.com/pub/net/p2pnat/

TCP:
- Proposed WG drafts:
  o draft-sivakumar-behave-nat-tcp-req-01.txt
  o draft-hoffman-behave-tcp-02.txt
  o draft-modadugu-nat-tcp-00.txt
- Some research/measurements:
  o http://www.guha.cc/~saikat/stunt-results.php
    (http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf)
  o http://www.brynosaurus.com/pub/net/p2pnat/

Multicast, SCTP, Gen etc drafts:
  https://datatracker.ietf.org/public/pidtracker.cgi?
command=search_list&sub_state_id=6&search_filename=behave&search_button=SEARCH

IETF 62 Minutes and presentations:
 o http://ietf.cse.ucsc.edu/behave/behave62/
 o https://datatracker.ietf.org/public/proceeding_interim.cgi?
meeting_num=62 ... look for BEHAVE

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 26 Jul 2005 20:14:24 -0700 (PDT)

> and can associate the mapping timer with it.
[suresh] When DNS query is made, the TCP/UDP DNS qeury session is between the
query initiator and the DNS Server. Neither of the endpoitns has anything to do
with the hostname (Host-X) for which the DNS query was made. What do you mean
by "the NAT can create a mapping when DNS query is made"? What is mapping here?
  Is that a Binding or a NAT Session? What are the endpoints you are talking
about in mapping? Further, NAT, by definition, does not touch payloads. ALGs
do. When DNS_ALG requests the NAT to create a Binding, the NAT may do so, if it
knows to create Bindings.

I did all I could to explain the need to distinguish between Binding and NAT
Session. Seeing your above response, it seems, I am going nowhere. Enough said.

> the NAT needs to implement bindings to support the DNS-ALG, it is
[suresh] Support for DNS-ALG is a SHOULD.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Tue, 26 Jul 2005 23:13:27 -0700 (PDT)

On Tue, 2005-07-26 at 20:14 -0700, Pyda Srisuresh wrote:
> What is mapping here? 

At the risk of beating a dead horse, "mapping" is (as defined in the
draft) "the translation between an external address and port and an
internal address and port".

> Is that a Binding or a NAT Session? 

Depending on the implementation; it can be either. It can be implemented
as a 4-tuple that you would call a "binding" or a 7-tuple that you would
call a "NAT session" (with garbage values for the fields that it doesn't
have values for) or even with a consistent hash function. Doesn't
matter. The functionality is the same one way or the other.

The only difference, that I've pointed out repeatedly, is the "binding
timer". If you implement mappings with 4-tuples, it makes sense to talk
of a separate binding timer. If you implement it with only 7-tuples then
the binding timer is implicitly fixed at zero. If you implement it with
a consistent hashing function, the binding timer is infinite (modulo
collisions). The draft does not specify a fixed binding timer.

-- 
Saikat
(who'll shut up now. :-p)

Attachment:
signature.asc

---

From: Bryan Ford <[email-masked]>
Date: Thu, 28 Jul 2005 04:10:54 -0700 (PDT)

> internal address and port".

OK, then what exactly is "a translation", in its usage above as a noun?  It's 
pretty obvious that NATs somehow, at some point, "translate" internal 
addresses and port numbers into external addresses and port numbers - but 
what exactly is _a_translation_?  Does "the translation" refer to the NAT's 
momentary action of translating the addresses in a packet as it crosses the 
wire?  Obviously not; the pervasive usage of "mapping" and "translation" 
throughout the document imply that a "mapping" or "translation" is some kind 
of persistent abstract entity, but the document never clearly defines what 
that entity is.  And to good reason: because _sometimes_ "mapping" refers to 
the abstract entity defined in prior RFCs as "binding", and _some (other) 
times_ "mapping" refers to the abstract entity defined in prior RFCs as 
"Session" or "NAT Session".  In other words, it's just a dysfunctional term 
that's inadequately trying to play the role of multiple existing and 
perfectly well-defined terms.  The current pseudo-definition of "mapping" in 
the UDP draft is simply circular.

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Thu, 28 Jul 2005 04:36:44 -0700 (PDT)

On Thu, 2005-07-28 at 13:11 +0200, Bryan Ford wrote:
> OK, then what exactly is "a translation", in its usage above as a noun? 

Not to be pedantic, but just for clarity:
  mapping n.
     1. A function such that for every element of one set there is a
        unique element of another set
  function n.
    1. A variable so related to another that for each value assumed by
       one there is a value determined for the other.
  translation n.
    2. A translated version of a text.

Reading the draft, I take mapping to mean the abstract mathematical
notion of a mapping or a function or a translation.

The input to this mathematical function is the internal IP and port and
the output is the external IP and port to use. One example would be a
hash function.

The NAT has infinite (well not quite) choices of defining such a
function. An input IP:Port X:x can be "mapped" to 
        f1(X:x) => X':x'
        f2(X:x) => Y':y'
        f3(X:x) => Z':z' ... so on.

When it sees the packet, it must choose one and only of these. That
fixes how the NAT maps X:x in the near future.  Next time it sees a new
packet from the same internal endpoint but to a different remote host,
it no longer has the freedom of choosing a new mapping -- it must reuse
the mapping it committed itself to earlier (as per the draft).

It continues to reuse it as long as even a single connection is alive
that is using that mapping.

As long as a mapping is alive, the NAT is forbidden from choosing a
mapping for a different endpoint that has the same output (external
IP/port). This is enforced by the port overloading requirement.

What happens after all connections stop using the mapping is left
undefined. The NAT can reserve the unused mapping for some idle time, or
it may discard it instantly and allow it to be chosen for other internal
hosts. The draft doesn't say what happens after all connections stop
using the mapping.

-- 
Saikat
(who really really tried to honor his last vow to shut up. :( )
Attachment:
signature.asc