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

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Jun 2005 18:20:41 -0700 (PDT)

Yutaka,

Would Saikat's proposal below for a new requirement address your concern?

> -----Original Message-----
> From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] 
> Sent: Monday, June 13, 2005 07:53
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'; 'Behave'
> Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6
> 
> 
> On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote:
> > 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)
>

---

From: [email-masked]
Date: Mon, 13 Jun 2005 20:07:32 -0700 (PDT)

Saikat caught my concerns correctly.

> Scope" behavior of "Per Session".
Do I agree with this... Not exactly, because of the definition of 
"session" in this document refers to RFC 2663, that says:

"TCP/UDP sessions are uniquely identified by the tuple of (source IP 
address, source TCP/UDP port, target IP address, target TCP/UDP port)."

As Saikat himself realizes, "Per session" means nothing to EF=I. 
Similarly, EF=AD only cares target IP addresses, not exactly a 
"session". The term "Per session" only makes sense if it is EF=APD.

Specifically speaking, there are three possible scopes:
(RS: Refresh scope)
RS=Any: refresh is done by interaction with any remote
        hosts (equivalent to the current "Per mapping")
RS=A  : refresh is done by interaction with remote hosts
        at specific addresses)
RS=AP : refresh is done by interaction with remote hosts
        at specific sets of address and port ("sessions")
Now, we have following chart to discuss further:

       | RS=Any | RS=A   | RS=AP  |
-------+--------+--------+--------+
EF=I   |x or n/a|  n/a   |  n/a   |
-------+--------+--------+--------+
EF=AD  |  Bad   |   x    |  n/a   |
-------+--------+--------+--------+
EF=APD |  Bad   |  Bad   |   x    |
-------+--------+--------+--------+
In the combinations marked with "n/a", enforcing the refresh means 
nothing. The combinations with "Bad" are the cases that I am concerned 
about. The combinations with "x"  are the most reasonable and natural 
behaviors to be implemented.

Thought about introducing above new refresh scopes in 4.4 and 
recommending combinations with "x" with the details (why "Bad" is bad, 
etc) in 12.1, however, this might be overspecifying. Just removing 6b is 
fine by me. 4.4 and 5.2 need to be taken care of though... Any thoughts?

Thanks,
- Yutaka

Francois Audet wrote:
Yutaka,

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 16 Jun 2005 10:12:13 -0700 (PDT)

Yutaka,

I agree with your comment about the semantics of the term "Session" being
inconsistent with RFC 2663. I believe, the term "NAT Session" is the
appropriate term to use here. Also, I believe, the following req captures what
you say.

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

my comments inline.

cheers,
suresh

> address, source TCP/UDP port, target IP address, target TCP/UDP port)."
[suresh] Right. I believe, the intended term here is "NAT Session".

> "session". The term "Per session" only makes sense if it is EF=APD.
[suresh] Right. The NAT Session parameters differ between EF=A and EF=I in the
way the NAT Session uses wild card for external UDP-port vs External IP Address
 & External UDP-Port.

A NAT Session can be as fine grained as a NAT device chooses (EF=AP, EF=A or
EF=I). When it comes to idletime monitoring, a NAt device does this on a NAT
Session basis. 

All UDP packets that match a NAT Session will reset the idletime of the NAT
Sesson. I.e., refresh the liveness of the NAT Session. 

>         | RS=Any | RS=A   | RS=AP  |

[suresh] Right. It Seems, the refresh scope loosely refers to idletime
monitoring of a NAT Session. 

cheers,
suresh

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