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

From: "Francois Audet" <[email-masked]>
Date: Fri, 8 Jul 2005 19:25:10 -0700 (PDT)

> 1. Yes, remove 5.2 altogether.

I agree with this suggestion.

Any dissenters? If I hear none, I will remove it.

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

This was discussed ad nauseam, and the document reflects the consensus.

I don't want to change it unless there is a clear indication that
magically, everbody changed their mind.

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

This whole document is only on UDP, so I don't see your point.

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

I believe this is covered in section 4.3. We are not using the
"binding" terminology, which makes the explanation a lot simpler than
your paragraph above.

> cheers,
> suresh
> 
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > 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: Sun, 10 Jul 2005 00:28:04 -0700 (PDT)

> magically, everbody changed their mind.

[suresh] Please see my comments on the same thread in my e-mail response to
Saikat. The requirement seems rather arbitrary without proper rationale. The
following current rationale at best makes one question the requirement.

   Justification for REQ-6: Outbound refresh is necessary for allowing
      the client to keep the mapping alive.
      a) Inbound refresh may be useful for applications where there is
         no outgoing UDP traffic.

> This whole document is only on UDP, so I don't see your point.

[suresh] I believe, there was agreement on the list that we needed "general NAT
terminology & requirements" first, followed by "UDP-specific requirements".
I.e., I heard no dissent when Jon Peterson brought this up on the e-mail.
However, there was no conclusion on where the former should be addressed - 
behave-gen draft or behave-udp draft. 

If you believe, behave-udp is only on UDP, then the general requirements should
be covered in behave-gen. Else, the behave-udp should clearly state which of
the requirement in the draft are generic and which are UDP specific.

> "binding" terminology, which makes the explanation a lot simpler than

[suresh] Francois - Section 4.3 covers the refresh of a NAT Session. I am OK
with this, so long as you include the right rationale/justification to go with
it. 

However, this REQ does not cover the refresh of the "Binding". "NAT Session"
and "Binding" are different terms and two different NAT resources. Please see
my response to Saikat on this. The new requirement refers the refresh of the
"Binding".  

cheers,
suresh