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

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 19 Jul 2005 08:00:24 -0700 (PDT)

Looks like the discussion on timeouts would never end. Just wanted to
quickly point out that the bindings (1-1 address binding) are used
extensively in large deployments. These bindings are then used to make
other policy decisions in the network. You could definitely have an
implementation that does not use any bindings, so the end user could get
a different address for every session as long as connectivity to the
public network is the only requirement. That is not always the case.

The characteristics of the bindings is different from the
characteristics of the sessions. The bindings don't track the state, but
do have a timer (which is usually much larger than the session timeout).

Senthil

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Monday, July 18, 2005 12:06 AM
> To: Behave
> Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh
> 
> On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: 
> > Most NAT devices use a Binding
> > refresh timeout of 0 secs for all kinds of Bindings
> 
> Can you point me to a study that shows that? What percentage 
> of NATs use a binding timer of 0? What percentage use a larger value? 
> 
> In fact, can you even point me to something that shows that 
> the NATs that you claim "use a Binding refresh timeout of 0 
> secs" _even use_ bindings and binding timers in the first place?
> 
> Instead, let me point you to the Linux source that:
> 1. DOES NOT use bindings
> 2. DOES NOT use a binding timer
> 3. Is a NAT that is behave compliant
> 4. Would _appear_ to use bindings and a binding timeout of 0 
> but DOES NOT
> 
> In the Linux implementation, there _is_ "mapping reuse (behave-udp)".
> For each "NAT session (behave-gen)" there is a mapping. That 
> mapping is reused -- the reuse gives the _illusion_ of a 
> "binding". That mapping has an associated timer (that would 
> appear as "NAT Session timer (behave-gen)" in your test). 
> That mapping is refreshed (when a packet is accepted on that 
> mapping -- i.e. when the packet is not filtered). When a new 
> connection arrives, existing mappings are checked and their 
> mapped address and port values _reused_. When a mapping 
> expires -- thats it, the mapping expires -- nothing else is 
> touched or refreshed. No binding state is reaped. As long as 
> there is even one live mapping when a new connection arrives 
> from the same internal endpoint the values from that mapping 
> are reused. When all the mappings are gone, a new mapping is 
> created for the new connection and there is no reuse. This 
> gives the _impression_ of having a "binding refresh timeout 
> of 0" ... but in reality, there is NO binding timeout. I 
> invite you to reconfirm this in the Linux 2.6.11 NAT code 
> (annotated below).
> 
> Not to be rude, but the fact remains that talking of a 
> "binding timeout"
> as something that absolutely MUST exist in a NAT and MUST be 
> standardized is absurd! A vendor's particular implementation 
> may use "bindings" and "binding timeouts" to implement the 
> requirements specified in behave-udp .... but claiming that 
> "bindings" and "sessions"
> are the one true terminology that descries what NATs do is 
> unjustified.
> 
> 
> ---- Linux implementation details / code walkthrough ----
> 
> When determining what NAT'ed IP and port to use for a new 
> connection, Linux does the following:
> 
> 1. Look through each existing session until it finds one where
>    the internal src ip and port matches the new connection.
> 2. Use the NAT'ed ip and port of that connection.
> 
> See:
> get_unique_tuple calls (ip_nat_core.c#L230) 
> find_appropriate_src that iterates over (ip_nat_core.c#L146) 
> existing connections (ip_nat.h#L61) and for each connection, 
> calls same_src (ip_nat_core.c#L147) that checks protocol, 
> internal IP and port for equality (ip_nat_core.c#L128).
> find_appropriate_src returns after the first match 
> (ip_nat_core.c#L155).
> 
> (add http://lxr.linux.no/source/net/ipv4/netfilter/ before 
> the file#Lline links above to view online)
> 
> There is *no table of "bindings"* that it checks. It only 
> checks live "NAT sessions (behave-gen)". 
> 
> When a packet is sent or received:
> 1. The timer for that connection "NAT session (behave-gen)" 
> is refreshed. (ip_conntrack_proto_udp.c#L73 for UDP,
> ip_conntrack_proto_tcp.c#L972 for TCP)
> 
> The connection timer is the only one it ever touches. If 
> there was a binding timer, then it would require at least two 
> timers to be changed
> -- that is not the case.
> 
> Further, when a connection expires:
> The death_by_timeout(ip_conntrack_core.c#L509) function is 
> called that only deletes the timer associated with that "NAT 
> session" (ip_conntrack_core.c#L267). 
> 
> It does NOT check whether other "NAT sessions (gen)" with the 
> same "binding (gen)" are alive or not. It does not refresh or 
> set some new "binding timeout". There is no binding timeout. 
> 
> 
> --
> Saikat
> (huff, pufff)
>

---

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

On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote:
> You could definitely have an
> 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). 

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
Attachment:
signature.asc