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

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jun 2005 10:37:14 -0700 (PDT)

This whole thing is confusing because what we mean is "Endpoint session" as 
opposed to "NAT session".

Backing off a little, perhaps we should just not talk about the "Refresh scope"
at all.

It seems to me that people are doubting the usefulness of having a "Refresh
scope" that is different from the Mapping. We could simply delete 4.4 (and 6b) 
altogether. And also, we could remove the last phrase of 5.2 (after the comma) 
on the scope of the refresh.

The consequence would be that Applications would need one refresh per "endpoint 
session" all the time. It would be something for the application document. The 
rationale is that we need to implement this for support Address and Port Dependent
Filtering.

So, here is the question:

Do people agree with deleting 4.4, Requirement 6b, and the last phrase of 5.2 
(everything after the comma).

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Monday, June 13, 2005 20:07
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Saikat Guha'; 'Behave'
> Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6
> 
> 
> Saikat caught my concerns correctly.
> 
>  > REQ-x: It is RECOMMENDED that a NAT have "NAT filter 
> Refresh  > 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,
> > 
> > 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: "Francois Audet" <[email-masked]>
Date: Thu, 23 Jun 2005 13:29:15 -0700 (PDT)

Yes. The whole sentence.

All right, looks like we nailed REQ-6.

> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Thursday, June 23, 2005 00:07
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'; 
> 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'
> On Wednesday 22 June 2005 02:45, Francois Audet wrote:
> > Hi Brian,
> >
> > Can you clarify what you mean by you agree with the "ongoing 
> > discussion" to resolve it?
> >
> > I was proposing the following:
> >     Do people agree with deleting 4.4, Requirement 6b, and the last
> >     phrase of 5.2 (everything after the comma).
> >
> > Is this what you are agreeing with?
> 
> Seems reasonable to me, although deleting just the last 
> phrase of 5.2 seems to 
> leave a meaningless sentence fragment ("In the case of ... 
> NATS").  Maybe I'm 
> looking at a different version of the text than you are 
> referring to...
> 
>    The time for which a NAT filter is valid can be refreshed based on
>    packets that are inbound, outbound, or going either direction.  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.
> 
> Did you mean to just delete the whole second sentence?
> 
> At any rate, I don't have a strong opinion as to how exactly 
> this issue is 
> resolved, as long as it doesn't leave NAT vendors between a 
> rock and a hard 
> place like it does at the moment.
> 
> > As for the rest of your notes below, I'm assuming that you are not 
> > proposing actual new text for the document, and that the 
> comments were 
> > targetted at the mailing list, right?
> 
> Correct.
> 
> Thanks,
> Bryan
> 
> > > From: Bryan Ford [mailto:baford@xxxxxxx]
> > > Sent: Tuesday, June 21, 2005 09:20
> > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > Cc: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Audet, Francois 
> > > [SC100:9T51:EXCH]
> > > 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
> > >
> 
>