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

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 15 Jul 2005 06:56:48 -0700 (PDT)

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

> Thanks to suresh's pointer on the definitions, I think I understand
> "bindings" now. Correct me if I am wrong; I believe "Bindings" (draft-
> ford-behave-gen-01.txt) mean more or less the same as "Mapping" (per
> draft-ietf-behave-nat-udp-02.txt). They are both something that is
> created dynamically at the NAT in response to the first outbound packet
> from a particular internal address and port. 

[suresh] Saikat - I had ascribed the term "mapping" in the draft to mean "NAT
Session" based on its usage in REQ-5 & REQ-1, as follows. Howevver, I do agree,
the term was not used consistently to mean the same throughout.

Say, a private host with a tuple of X:x (assume UDP port x) initiates 3
outgoing UDP Sessions with 3 external tuples Y1:y1, Y2:y2 and Y3:y3. Say, the
NAPT device enroute asigned a Port Binding of N:Nx for X:x. In this scenario,
the NAPT will have created 4 resources as follows:

a) Port Binding-1:: (X:x, N:Nx)
b) NAT Session-1 :: ((X:x->Y1:y1) Xlates to (N:Nx->Y1:y1) using Port Binding-1)
c) NAT Session-2 :: ((X:x->Y2:y2) Xlates to (N:Nx->Y2:y2) using Port Binding-1)
d) NAT Session-3 :: ((X:x->Y3:y3) Xlates to (N:Nx->Y3:y3) using Port Binding-1)

In the above scenario, it is possible for NAT Session-1, which uses Port
Binding-1 to expire after the 2-minute idle timeout. But NAT Session-2 and NAT
Session-3, both of which also use the same Port Binding-1 may remain active.
So, the Port Binding-1 itself will be alive. When X:x initiates yet another
outgoign session to Y4:y4, the NAT would reuse port Binding to crate a new NAT
Session.

Section 4.3, REQ-5 reads as follows.
  REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 minutes.

If you take the above example and refer REQ-5, you will note that the term
"mapping" in REQ-5 refers to timing inidividual "NAT Sessions". The REQ says, a
mapping (i.e.,a specific NAT Session) may be expired after 2 mins. But, that
does not mean that the associated Binding has expired.

Now, let us take Section 4.1. Please refer the following text in the section. 

                        Let's assume that the internal IP address and
   port X:x is mapped to X1':x1' for this first session.  The endpoint
   then sends from X:x to an external address Y2:y2 and gets a mapping
   of X2':x2' on the NAT.

The above text refers to maping on a per-session basis. Session 1 using a
maping of X:x to X1:x1' and Session 2 using a maping of X;x to X2':X2. Once
again, the term "mapping" is used in a per session context, just as is the case
with "NAT Session". 

The draft goes on define "Endpoint Independent Mapping" as follows.

      Endpoint Independent Mapping:
         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to any
         external IP address and port.  Specifically, X1':x1' equals
         X2':x2' for all values of Y2:y2.

When multiple NAT Sessions emanating from the same private host tuple, use the
same private host tuple transalation, that is when that NAT is said to be using
"Port Binding" for the private host tuple. So, I believe, the term "Endpoint
Independent Mapping" is the closest equivalent of "Port Binding" in this draft.

>                                              "Mapping" (as per draft-
> ford-behave-gen-01.txt) is a static administrator-configured entry,
> usually from a port-forwarding or internal-service screen in many NAT
> interfaces. draft-ietf-behave-nat-udp-02.txt does not mention anything
> about these static entries.
> 
[suresh] Right.

> On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: 
> > 3. Lastly, the document is missing a key requirement on Bindings. A
> dynamically
> > created Binding (Address and/or Port Binding) MUST be refreshed, when there
> is
> > is at least one live NAT Session using the Binding. 
> 
> I believe this is what REQ-5 addresses (but uses the term "mapping" as
> defined earlier instead of "binding" ... but has the same meaning). 
> 
[suresh] Please refer my text above. I believe, REQ-5 refers to "NAT Session".

No matter, the bottom line is that a behave-compliant NAT device MUST have two
types of NAT resources - a) Bindings and b) NAT Sessions. 

Both resources are created dynamically (Well, not exactly. Static 1-to-1
address maps would result in static Bindings). So, both resources ought to be
refreshed for their liveness. 

SO, I think, you will agree, there ought to be two requirements, one addressing
the refresh of "NAT Session" and another addressing the refresh of "Bindings". 
  That was the gist of my comment on 07/08.

> 
> > Alternately, once a Binding
> > is created in relation to an endpoint and a NAT Session, subsequent NAT
> > Sessions associated with the endpoint MUST reuse the same Binding.
> 
> I believe this is what REQ-1 addresses. It says that the dynamically
> created mapping/binding/whatever must be reused for new sessions
> originating from the same internal endpoint.
> 
[suresh] As I said earlier, "Endpoint Independent Mapping" is the closest
equivalent of "Port Binding" in this draft. So, I read REQ-1 to mean that NATs
must support Port Bindings. But, the draft makes no mention of the refresh
charcateristics of the Bindings.

"Binding" and "NAT Session" are two basic NAT resources. By using these
standard terms to characterize NAT behvaioral requirements, you are able to a)
avoid the use of Cone/Symmteric NAT terminology, b) qualitatively address the
exppected behavioral requirements in terms of NAT resources, and c) avoid using
conflicting terms with existing RFCs.

cheers,
suresh
> -- 
> Saikat

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 15 Jul 2005 08:02:11 -0700 (PDT)

<... stuff deleted>

> conflicting terms with existing RFCs.
[suresh] I wanted to point out additional benefit to using standard terinology.

Standard terms are used to distinguish between various NAT types. As such, use
of standard terms in the behave drafts makes the recommendations applicable to
all NAT types, including Traditional NATs, Bi-directional NATs, twice NATs, and
the newly coined HairPin NATs. Ford-behave-gen and sivakumar-behave-nat-tcp
drafts have the requirements written using Bindings and NAT Sessions. As such,
the requirements in these drafts are not restricted to Traditional NATs, except
as noted. 

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

---

From: Saikat Guha <[email-masked]>
Date: Fri, 15 Jul 2005 15:57:51 -0700 (PDT)

On Fri, 2005-07-15 at 06:56 -0700, Pyda Srisuresh wrote:
> In this scenario,

This is implementation dependent. I can think of an implementation where
a) is not created as a separate object but rather inferred from b-d.
Note that each of b-d have the full information given by a). What data
structures/organization a NAT uses is, no doubt, up to the vendor.

> the refresh of "NAT Session" and another addressing the refresh of 

Yes. That has always been the case. The "Bindings (behave-gen)"
addresses the same issue as "Mappings (behave-udp)".   "NAT Session
(behave-gen)" addresses the same issues as "NAT Filter Refresh".

Your requirement that "Bindings" be refreshed is exactly what
REQ-1 and REQ-5 say. In particular, REQ-1 says "Bindings must be
implemented" and REQ-5 says "bindings must be refreshed".

> [suresh] Please refer my text above. I believe, REQ-5 refers to "NAT Session".

I do not believe so. REQ-5 still talks about "mappings (behave-udp)" which is 
similar to 
"bindings (behave-gen)".

"NAT sessions (behave-gen)" are introduced in Section 5 (not related
between REQ-5 by the way). Your requirement that "NAT Sessions" be
refreshed used to be in Section 5.2 "NAT Filter Refresh (behave-udp)". I
think 5.2 has since been removed as per your request (July 8 mail). If
you feel that the July 8 mail was due to a misunderstanding of
terminology, I am sure FranÃois can resurrect the section.   

As for which terminology to use, I strongly prefer the behave-udp
terminology since it can actually differentiate between the types of
NATs I actually see in the wild. The behave-gen terminology shoehorns
many of them into "symmetric" ... and not all "symmetric" NATs are
behave the same way. Indeed I find that NB=A NATs have a 100% traversal
success rate when paired up with NB=I NATs, but NB=ADP NATs don't. Both
NB=A and NB=ADP are "symmetric" and hence it is not possible to make the
observation above if the old terminology is used. 

-- 
Saikat
Attachment:
signature.asc