Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jun 2005 15:49:46 -0700 (PDT)

OK for the comment about s/Direction/Scope. I will make the fix.

As for the comments on 6b, I'm not sure I share your concern. It just means
that as long as the inside endpoint is using the port (regardless of how any
endpoints are sending to it from the outside), it will remain opened. The
"cleanup" of the sessions is only going to happened when the inside endpoint
stops sending packets (to anywhere). But I don't really care either way.

As for 6a, the idea was for unidirectional sessions (see Justification).
I have no problem removing 6a however or making it NOT RECOMMENDED.

Any comments from others?

----------------------------------------------
6a- Opinions on 6a:
        i) Keep it as is
        ii) Remove it completely
        ii) Replace MAY by NOT RECOMMENDED

6b- Opinions on 6b:
        i) Keep as is
        ii) Remove it completely
----------------------------------------------

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> Sent: Tuesday, June 07, 2005 10:21
> To: 'Behave'
> Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6
> 
> 
> I have some comments on REQ-6.
> 
>     REQ-6  The NAT mapping Refresh Direction MUST have a "NAT Outbound
>            refresh behavior" of "True".
>            a) The NAT mapping Refresh Direction MAY have a 
> "NAT Inbound
>               refresh behavior" of "True".
>            b) The NAT mapping Refresh Direction MUST have a 
> "NAT refresh
>               method behavior" of "Per mapping" (i.e. refresh all
>               sessions active on a particular mapping).
> 
> There's a typo in 6b: "Refresh Direction" -> "Refresh Scope" 
> Somewhat I missed what 6b exactly meant when I read it 
> before, I assumed 
> that the definition of "mapping" for EF=A was a tuple of local IP 
> address, local port, protocol and destination IP (4-tuple).
> 
> To me, requiring "per mapping" refresh for EF=A is problematic. Say, 
> there is a host behind a EF=A NAT communicating with many 
> remote hosts 
> from the same local port. If one or more sessions are always 
> active for 
> a long time, the number of destination IP addresses stored in 
> the memory 
> in the NAT for filtering will accumulate. When it hits the maximum 
> number of the destination address the NAT can remember, the 
> design must 
> need to consider overwriting the existing destination address 
> table but 
> there is no criteria for which one can be overwritten without a timer 
> per session. In another word, it cannot be assumed in NAT design that 
> communications would be made to limited number of destinations during 
> the lifetime of the mapping. So, I think 6b should be removed.
> 
>  From the security point of view, the sessions that are no 
> longer in use 
> should preferably be closed. Similarly, I feel 6a can be "NOT 
> RECOMMENDED" to prevent from an attacker maintain a session 
> that is no 
> longer in use by an application.
> 
> 
> - Yutaka
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: [email-masked]
Date: Thu, 9 Jun 2005 17:28:57 -0700 (PDT)

> The "cleanup" of the sessions is only going to happened
> when the inside endpoint stops sending packets (to anywhere).
This is the point I am concerned about. What if the inside endpoint does 
not stop sending to some remote hosts for a long time?

Let me explain again with an example:

Consider host S is behind EF=A/NB=I NAT, providing video streaming 
service, for example, from the same local port to *anyone*, like 
forever... Accumulative number of connections could be thousands or 
millions over time if instantaneous number of connections happens to be 
one or more whole time. Since the NAT is EF=A, it has to remember all 
the remote host's addresses for the endpoint filtering until the binding 
is destroyed. I do not believe that a NAT can store millions of 
addresses in memory practically. Then a design might be determined to 
have a limit like 256 addresses at maximum for a binding, but is 256 
enough? It is hard tell.

The MUST in 6b imposes above problem to implementors. 6b is sure 
attractive, but I cannot help anticipating that this may cause another 
non-dereministic behavior of NAT. Considering the essential reason to 
choose EF=A over EF=I, the sessions no longer in use should be closed. 
Actually, an application cannot assume that the NAT it is behind a 
behave compliant NAT, 6b is not so useful anyways..

- Yutaka

Francois Audet wrote:

As for the comments on 6b, I'm not sure I share your concern. It just means
that as long as the inside endpoint is using the port (regardless of how 
any
endpoints are sending to it from the outside), it will remain opened. The
"cleanup" of the sessions is only going to happened when the inside 
endpoint
stops sending packets (to anywhere). But I don't really care either way.

---

From: Bryan Ford <[email-masked]>
Date: Tue, 21 Jun 2005 07:20:19 -0700 (PDT)

On the REQ-6b issue, I fully agree with Yukata's concerns and support the 
ongoing discussion to resolve it.  As a side note, though, I just wanted to 
point out that this presents us with yet another reason we should encourage 
EF=I NATs as much as possible, and strongly recommend that NATs at least be 
configurable to EF=I by the administrator whatever their default 
configuration.  Since as a practical matter any EF=A NAT must have 
per-session keepalive timers (or at any rate finer than per-binding 
granularity), applications behind EF=A NATs have to send per-session 
keepalives.  For applications with a lot of neighbors (e.g., apps running 
distributed hash table algorithms and the like), that can amount to  a LOT of 
keepalive traffic.  Applications behind EF=I NATs, in contrast, besides being 
"first-class citizens" that can help other nodes punch holes, also only have 
to send keepalives on one session to maintain all their mappings, thereby 
substantially reducing their "background" traffic load on the Net.

Of course this still doesn't make applications simpler, since we know in 
practice applications have to support both EF=A and EF=I NATs.  But in 
situations where the app is smart enough to detect and take advantage of EF=I 
behavior anyway (e.g., in order to become a supernode on a P2P network), it 
can easily leverage this knowledge further by reducing the keepalive traffic 
it generates to a single session.  Less useless keepalive traffic is good for 
users and for the Internet.  EF=I is good for users and for the Internet.  
Nuff said.

Bryan