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

From: "Francois Audet" <[email-masked]>
Date: Sun, 10 Jul 2005 12:14:46 -0700 (PDT)

> > I think someone (Yutaka?) made the case that if "Inbound" 
> is true then 
> > an external attacker can keep a mapping alive without the 
> consent of 
> > the internal app by just sending packets.
> 
> [suresh] I see. Interesting. This of course makes the 
> assumption that the attacker is on the outside. Note, address 
> spoofing attacks can occur the inside as well. Anyways, 
> assuming the attacker is on the outside ony, this is likely a 
> bigger issue with Address Binding than Port Binding, because 
> IP addresses are more scarce than the port numbers.
> 
> I will also add, this requirement has the caveat that 
> applications that involve long periods of inbound-only 
> traffic can be problematic to traverse through NATs. This can 
> be particulraly concerning for these applications, as the 
> traffic path includes slow links.
> 
> In any case, I believe, the rationale for the recommendation 
> should be in the draft. Without that, the recommendation 
> seems arbitrary.

Fair enought, I'll add it to the justification.

Note that over time (assuming a NAT that doesn't restart), it could
end-up opening
all the ports on the NAT.

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 15 Jul 2005 07:26:49 -0700 (PDT)

--- Saikat Guha <saikat@xxxxxxxxxxxxxx> wrote:

> On Wed, 2005-07-13 at 17:20 -0500, Francois Audet wrote:
> > It was decided a while ago to use the term mapping because it
> > applies to both "symmetric" and "cone" NATs, which is not
> > the case for binding.

[suresh] I will ignore the rant about "it was decided a while ago", because
there was no such decision on the list.

As for the comment about "mapping" applying to both "symmteric" and "Cone" NATs
and "Binding" not, it makes no sense to me. Behave-gen draft does exactly that
- explain the nuances across "Cone" and "Symmetric" NATS in terms of Bindings
and NAT Sessions. 
 
> 
> True enough ... in that the term "mapping" has a defined value
> (I=independent,A=address,P=port,ADP=address and port) for any kind of
> NAT while the "implements binding" is equivalent to NB=I and all of
> NB=A,NB=P,NB=ADP fall under "inconsistent binding" or "does not
> implement binding" etc. So yes, the two are not interchangable without
> loss in fidelity ... but they both refer to the dynamic behavior of NATs
> in allocating an external endpoint to an internal endpoint.
> 
[suresh] Saikat - Section 2.4 of the Behave-gen draft explains "Cone" vs
Symmetric" NAT behaviors in terms of "Bindings" and "NAT Sessions". Here is a
brief.

a. Symmteric NAT - Doesnt support Bindings, only NAT Sessions.
b. All types of Cone NATs - Support Bindings and NAT Sessions.
b.1. Port Restricted Cone NAT - No wild card matches in NAT Sessions.
b.2. Address restricted Cone NAT -  Applicable only to UDP sessions. Wild-card
match on UDP port for external host in NAT Sessions.
b.3. Full Cone NAT - Applicable only to UDP sessions. Wild-card match on
external host IP address and UDP port in NAT Sessions. 

cheers,
suresh

> -- 
> Saikat

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Jul 2005 18:15:43 -0700 (PDT)

Thank you Saikat,

Your very detailed analysis confirms some of the empirical data that
was observed by Cullen and I. It explains the reason for the neutral
model (i.e., the NAT as seen from the outside) that we used
in draft-ietf-behave-nat-udp.

I am glad you managed to back it up with a concrete and verifiable
example.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Sunday, July 17, 2005 21:06
> 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: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jul 2005 14:37:38 -0700 (PDT)

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

REQ-5 addresses the timeout of mapping.

How it relates to "bindings" is implementation details not
specifically covered in the document.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 28 Jul 2005 10:05:58 -0700 (PDT)

Bryan, we have asked many times to show us exactly WHERE the word
"mapping" is used erroneously. We have tried to correct mistakes if 
there are any mistakes. And I think we did. But we keep getting pages 
of diatribe on why we should be using the -gen draft instead, and base 
the whole document on the concept of bindings.

We are using the term "mapping" the same way the NAT terminology
RFCs use it: RFC 2263, 3022, 3027 (all co-authored by Srisuresh I 
might add). It's nothing new: it's established terminology.

We have also decided to not get into the whole "binding" issue because
it doesn't seem to be useful, and not necessarily clear to everybody. 
NATs that are using "bindings" are not the ones that are causing the
worst problems (as you point out all the time).

The people who are not using bindings at the ones that need more help.
The problem is they might not know that they are not using bindings.

It is not the mandate of BEHAVE-UDP to say "YOU MUST USE BINDINGS", even
if it probably the best way to not get in trouble.

So again, if you can briefly describe exactly WHERE we use "mapping"
improperly, and how to change wording without getting into the "binding"
issue, it would be helpful. 

At this point, nobody else seems to be seeing the issue.

> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Thursday, July 28, 2005 03:43
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Cc: Audet, Francois [SC100:9T51:EXCH]; Saikat Guha; Senthil 
> Sivakumar (ssenthil)
> Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh
> 
> 
> On Tuesday 19 July 2005 23:32, Francois Audet wrote:
> > Right.
> >
> > Using bindings is a perfectly reasonable way of 
> implementing this, and 
> > people are free to do it.
> >
> > But the mandate of the BEHAVE group is NOT to mandate specific 
> > technologies for implementation. This is why the language 
> in the draft 
> > keeps it at a higher level (i.e., using "mapping" instead of 
> > "binding").
> 
> If by "higher level" you mean "vague and nowhere explicitly 
> defined", then I 
> agree.  Judging from recent discussion there is still rampant 
> confusion about 
> which uses of the term "mapping" in the draft refer to 
> something binding-ish 
> and which uses refer to something session-ish.  At least the 
> terms Binding, 
> Session, and NAT Session have very clear definitions with 
> well-established 
> precedent; as far as I can tell mapping is just a verb.
> 
> Bryan
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Jul 2005 10:26:41 -0700 (PDT)

I said that MAPPING is NOT the same as BINDING.

Everybody tought that your terminology of "binding" and
"NAT session" where confusing and therefore we don't use
it.

I really couldn't care less about emails from months ago.

Tell us what specific line in the document are wrong. You are
continuing with the pages of diatribe. It is not helpful.

We are NOT going to adopt the term NAT session and binding throughout
the document. So make sure you explain what is wrong with something
 better than "this is a NAT session".

> Pyda Srisuresh
> Sent: Friday, July 29, 2005 10:02
> To: Saikat Guha; Bryan Ford
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> --- Saikat Guha <sg266@xxxxxxxxxxx> wrote:
> 
> > On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote:
> > > This is why the language in the
> > > > draft keeps it at a higher level (i.e., using "mapping" 
> instead of 
> > > > "binding").
> > > 
> > > defined", then
> > I
> > > agree.
> > As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247 
> > defines it fairly explicitly.
> > 
> 
> [suresh] Use of the term "mapping" is inconsitent and far 
> from clear throughout the document. You had claimed in 
> several of your e-mails that Maping is same is Binding. Yet, 
> the draft, right after line 247 says Mappign is not same as 
> Binding. So much for the definition matching your 
> understanding. The same term is used to mean NAt Session in REQ-5.
> 
> Further, In the mail dated 07/26, when asked what Mapping is, 
> you said it can be either Binding or NAT Session, depending 
> upon implementation. That the term carries different 
> semantics depending upon implmentation and context of its use 
> is precisely the problem with the term. This is what Bryan is 
> referign to as vague. Below is the quote from 07/26 e-mail to 
> jog your memory.
> 
>     Suresh:: > Is that a Binding or a NAT Session? 
>     Sakat::  Depending on the implementation; it can be either. 
> 
> Now, the second half of bryan's e-mail, which you omitted in 
> your response, is really the crux. I will quote the text 
> below for convenient reference. 
> 
> "At least the terms Binding, Session, and NAT Session have 
> very clear definitions with well-established precedent; as 
> far as I can tell mapping is just a verb."
> 
> Why not use terms that have clear definition, carry precise 
> semantics and have established precedence to describe BEHAVE 
> requirements? That is really the question. The terms 
> "Binding" and "NAT Session" are consitent with earlier NAT 
> RFCs, implementation independent and adequate to describe 
> BEHAVE requirements. ford-behave-gen and 
> sivakumar-behave-nat-tcp are testaments to that. Both these 
> drafts have used the terms Binding and NAT Session to derive 
> BEHAVE requirements. It is trivial to do the same wiht behave-udp. 
> 
> cheers,
> suresh
> > --
> > Saikat
> > > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> 
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 29 Jul 2005 11:23:14 -0700 (PDT)

> Francois Audet
> Sent: Friday, July 29, 2005 1:27 PM
> To: Pyda Srisuresh; Saikat Guha; Bryan Ford
> Everybody tought that your terminology of "binding" and "NAT 
> session" where confusing and therefore we don't use it.
> 

[Senthil] Who is everybody? I haven't seen anyone complaining the above
terminology as confusing. Instead what I have heard is that why should
n't we continue to use the current terminology. The real audience these
documents are targetted towards should not get confused. That should be
the goal of the WG and the drafts this WG produces. If a
implementer/tester reads this document (who is going to implement/test
the recommendations) it should be clear on what a
binding/mapping/session means. Apparently these lengthy and
argumentative email threads indicate that such clarity does not exist
today in the document.

Senthil
> We are NOT going to adopt the term NAT session and binding 
> throughout the document. So make sure you explain what is 
> wrong with something  better than "this is a NAT session".
> 
> > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda 
> > Srisuresh
> from clear 
> > throughout the document. You had claimed in several of your e-mails 
> > that Maping is same is Binding. Yet, the draft, right after 
> line 247 
> > says Mappign is not same as Binding. So much for the definition 
> > matching your understanding. The same term is used to mean 
> NAt Session 
> > in REQ-5.
> > 
> > Further, In the mail dated 07/26, when asked what Mapping 
> is, you said 
> > it can be either Binding or NAT Session, depending upon 
> > implementation. That the term carries different semantics depending 
> > upon implmentation and context of its use is precisely the problem 
> > with the term. This is what Bryan is referign to as vague. Below is 
> > the quote from 07/26 e-mail to jog your memory.
> > 
> > Now, the second half of bryan's e-mail, which you omitted in your 
> > response, is really the crux. I will quote the text below for 
> > convenient reference.
> > 
> very clear 
> > definitions with well-established precedent; as far as I can tell 
> > mapping is just a verb."
> > 
> semantics 
> > and have established precedence to describe BEHAVE 
> requirements? That 
> > is really the question. The terms "Binding" and "NAT Session" are 
> > consitent with earlier NAT RFCs, implementation independent and 
> > adequate to describe BEHAVE requirements. ford-behave-gen and 
> > sivakumar-behave-nat-tcp are testaments to that. Both these drafts 
> > have used the terms Binding and NAT Session to derive BEHAVE 
> > requirements. It is trivial to do the same wiht behave-udp.
> > 
> > cheers,
> > suresh
> > > --
> > > Saikat