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

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Jul 2005 09:03:12 -0700 (PDT)

Should we remove 5.2 altogether?

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Thursday, July 07, 2005 05:49
> To: Audet, Francois [SC100:9T51:EXCH]; Behave
> Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh 
> 
> 
> 
> Basically, it makes no sense to discuss refreshing a filter 
> in the context of NATs.  Here is why. 
> 
> You donot refresh an entity you donot have. NATs donot have 
> filters. Filtering is a behavior you observe on certain types 
> of NATs (most notably, Traditinal NATs), not all NAT types. 
> The filtering behavior is a direct result of the Address map 
> configuration and the Bindings. So, it makes no sense to 
> discuss refreshing a filter in the context of NAT.
> 
> The term "Address and Port mapping" that you use in your 
> document loosely refers to "NAT Session" (as defined in RFC 
> 4008), which is a NAT resource. So, it does make sense to 
> discuss refreshing a NAT Session. 
> 
> Another resource that NATs do manage as a resource is 
> "Address/Port Binding" (also defined in RFC 4008). NATs do 
> refresh the Bindings. Your document makes no mention of this. 
> 
> There is a more fundamental problem in that the behave-udp 
> draft does not use the right terminology.
> 
> cheers,
> suresh
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > 
> > 
> > > Francois,
> > > 
> > > You have section 4.3 refering to "Mapping Refresh" behavior
> > > and a req-6 that follows it. And, section 5.2 refering to 
> > > "Filter refresh" with no requirement that follows it. 
> > 
> > Please go read the archive for why we don't have a requirement for 
> > Filter refresh.
> > 
> > 
> > > Why does section 5.2 have no requirement associated with it?
> > 
> > Because people don't think we need one.
> > 
> > > Also, w.r.t. req-6, why is the refresh required only on the 
> > > outbound?
> > 
> > Please go read the archives. We discussed this before.
> > 
> 
> 
> 
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 8 Jul 2005 07:02:35 -0700 (PDT)

1. Yes, remove 5.2 altogether.

2. As for section 4.3, Req-6, the refresh (i.e., liveness) should not be tied
to traffic in one direction over the other. The NAT Session should be refreshed
(i.e., considered live) when associated packets traverse the NAT in either
direction. 

Further, the refresh process is transport independent, i.e., not UDP specific. 
This requirement is currently buried under the same section (section 4.3) that
discusses UDP specific timeouts (REQ-5).

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. 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. A
dynamically created NAT Binding may expire when there is no live NAT session
associated with it. A NAT may choose to use an expiry time largen than 0 secs
for the Bindings.

cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 8 Jul 2005 07:24:25 -0700 (PDT)

Francois,

In section 1, titled "applicability Statement", you state the following.

   The requirements of this specification apply generally to all NAT
   variations, including the ones described in RFC 2663 [3] (Traditional
   NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed
   NATs).  However, it is not within the scope of this specification to
   address all issues specific to all possible NAT variations.

Yet, in section 3, you state:

                          In this specification, the term "NAT" refers
   to both "Basic NAT" and "Network Address/Port Translator (NAPT)".

For the reminder of the document, you use the above definition for NAT in
deriving the Behave requirements. 

If the scope of applicability is beyond Traditional NATs, then the requirements
do not do justice to that, as they assume traditional NAT. You will need to
spell out which of the requirements are generic and which are specific to Basic
NAT and/or NAPT.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Fri, 8 Jul 2005 14:01:37 -0700 (PDT)

> (i.e., considered live) when associated packets traverse the NAT in either

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. If a different application is
later started that binds to the same local port on the internal host
then the attacker now has an attack vector that the internal app cannot
close. 

> 3. Lastly, the document is missing a key requirement on Bindings. 

Just so I understand, this refers to the global IP address to internal
host IP relation, correct? And therefore is stronger than cone in that
all mappings from the same internal host get the same global IP address,
which ofcourse would only affect NATs with multiple external IP
addresses? 

If that is the case, I am not sure what benefits that provides. If an
internal application opens two ports locally and talks to a remote
host ... under the above requirement, it would need to tell the remote
host of its two mapped ports and only one mapped IP. Without that, it
would need to provide both the IPs. Since the internal application needs
to find both its external port mappings (STUN etc), it automatically
finds both its external IPs as well ... so as I see it, it seems that
all this saves is sending over 4 extra bytes. Alternatively, the remote
endpoint could be using the IP address as some security key ... to allow
the second port from accessing something without any authentication;
that in any case is horribly broken since even with the above
requirement two hosts could get the same IP. Am I missing something? 

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 9 Jul 2005 23:50:04 -0700 (PDT)

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:

> 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.
 
>                                       If a different application is
[suresh] So long as the NAT Session is alive for an application-x, the port
binding would stay alive. SO, there is no chance of another application-y
reusing the same external port while NAT Session from application-x is kept
alive. The worst thing that could happen is that the internal host closed
application-x on its local port, but the associated port binding stays alive on
the NAT. But, I agree, the damage can be more when the Binding is address based
(not port based).  

> which ofcourse would only affect NATs with multiple external IP
[suresh] No. It would be Port Binding in case of NAPT; And, Address Binding in
case of Basic NAT. 

> requirement two hosts could get the same IP. Am I missing something? 

[suresh] Sounds like you completely misunderstood what I said. frankly, I do
not even follow your logic. 

Req-1 reads as follows

REQ-1: A NAT MUST have an "External NAT mapping is endpoint
      independent" behavior.

The above requirement does not address the associated Port Binding (or) Address
Binding (whichever maybe the case) as a NAT resource. Applications such as
DNS-ALG (which is a recommended default ALG) would require the Binding to be
unexpired for a period of time even when the Binding has no NAT Sessions
asosciated with it. Same would be the case with several Peer-to-peer
applications. That a NAT may choose to use an expiry time largen than 0 secs
for the Bindings is reflected in the following requirement text.

A dynamically created Binding (Address and/or Port Binding) MUST be refreshed,
when there is at least one live NAT Session using the Binding. A NAT may choose
to use an expiry time larger than 0 secs for a Bindings, when there is no live
NAT session associated with the Binding.

cheers,
suresh

---

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

On Sat, 2005-07-09 at 23:50 -0700, Pyda Srisuresh wrote:
> the NAT. 

I am confused. Can you define "port binding" and "NAT session" in the
context of your mail or point me to the RFC that defines them; since I
suspect it differs from that in the UDP draft.

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 12 Jul 2005 06:08:36 -0700 (PDT)

> suspect it differs from that in the UDP draft.

[suresh] Saikat - Take a look at draft-ford-behave-gen-01.txt, section 2.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Wed, 13 Jul 2005 15:23:10 -0700 (PDT)

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

On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: 
> 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). 

> Alternately, once a Binding
> 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.

-- 
Saikat
Attachment:
signature.asc