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

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jun 2005 17:47:59 -0700 (PDT)

I think you have a good point in favor of eliminating 6b.
It does mean that applications will have to keep all sessions alive, but you may
be right that it's the price to pay.

Anybody objects to removing 6b in light of this?

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Thursday, June 09, 2005 17:29
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6
> 
> 
> 
>  > 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:
> > 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: Saikat Guha <[email-masked]>
Date: Mon, 13 Jun 2005 08:24:38 -0700 (PDT)

> Anybody objects to removing 6b in light of this?

Yes. I messed up. :-p I pointed Yutaka-san to the wrong requirement; the
document addresses his concerns in section 5.2, not 4.3. 4.3 is fine as
is. 5.2 needs changing in light of his concerns.

(section 4.3)
> NAT mapping timeout implementations vary but include the timer's
> value and the way the mapping timer is refreshed to keep the mapping
> alive.

(section 5.2)
> 5.2  NAT Filter Refresh
>
>   The time for which a NAT filter is valid can be refreshed based on
>   packets that are inbound, outbound, or going either direction.

As far as I understand, "mappings" for a NB=I NAT are determined based
only on the internal source address and port. Even if a internal endpoint (X:x)
sends packets to hundreds of destinations, the NAT has exactly _one_
mapping (X:x => X1:x1).

The NAT "filter" however depends on both the internal and external
endpoint. If the NAT is EF=A, and the host (X:x) connects to 100
external addresses (Yn:yn), then the NAT needs to remember 100 "filter"
tuples of the form (X:x, Y1), (X:x, Y2), ... (X:x, Y100) so
it can enforce the filtering policy. This filter state is different from
the mapping state. It is this filtering state that Yutaka is concerned
about:

On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> Since the NAT is EF=A, it has to remember all 
> the remote host's addresses for the endpoint filtering

Concerning this, UDP draft in its present form says in section 5.2 that:
> In the case of "External Filtering" of "Address dependent" or "Address
> and port dependent" NATs, the scope of the refresh could include the
> filters for just the particular port and destination or for all the
> ports and destinations sharing the same external address and port on
> the NAT.

I believe what Yutaka-san is suggesting is to add the recommendation:

REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope"
behavior of "Per Session".

In fact changing REQ-6b in section 4.3 to "per session" is a null
operation. It has no effect because of the NB=I requirement. If you
expire the "mapping" for an inactive session (X:x => X1:x1), then the
NAT cannot reclaim the mapping as long as there are other sessions that
are active that also use the (X:x => X1:x1) mapping.

-- 
Saikat
(who is stranded in LA)
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 16 Jun 2005 09:39:27 -0700 (PDT)

Sorry, I am a bit late on this thread. Just catching up after a long hiatus. I
havent necessarily read all the e-mails on this thread. Just a cautionary note
:-)

My comments below inline.

cheers,
suresh

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

<... stuff deleted>

> the mapping state. It is this filtering state that Yutaka is concerned

[suresh] Right. The difference between EF=A and EF=I is that the number of NAT
sessions. The term "NAT Session" is explained in ford-behave-gen-01 draft,
section 2.3. Essentially, as Saikat explains above, The EF=A case results in
100 NAT Sessions, whereas the EF=I case results in a a single NAT Session. 

> > the remote host's addresses for the endpoint filtering

[suresh] Right.

> behavior of "Per Session".
[suresh] I suggest rewording this as below using the terminology of "NAT
Sessions". I suspect, this is what Yutaka intended as well. I might also add
this is a fairly basic aspect of how NATs operate, as described in section 2 of
the ford-behave-gen-01 draft. Lastly, the requirement is transport independent
and pertains to both the TCP and UDP NAT Sessions.

REQ-x: It is RECOMMENDED that a NAT device monitor the idle-time on all NAT
Sessions. 

> are active that also use the (X:x => X1:x1) mapping.
[suresh] yes.

cheers,
suresh

> -- 
> Saikat
> (who is stranded in LA)
> > _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>