Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application

From: "Francois Audet" <[email-masked]>
Date: Tue, 3 Jan 2006 11:05:44 -0800 (PST)

REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE 
group agreed-to, and supercedes what is said in behave-app if there is
a conflict. It does not mandate Address Restricted Cone NAT. 

So the statement you are refering to needs to be modified in the
ford-behave draft.

To answer your original question on refreshing the mapping by the
application, 
it was out-of-scope of draft-behave-nat-udp to talk about applications. 
That's why we didn't mention it. In a much earlier version of the draft,
we
did talk about it and try to impose a "one packet refreshes all
mapping" policy.

We eventually came to the conclusion that unfortunatelly it would be
impossible (we couldn't get everybody to agree). It is essentially a 
consequence of allowing for all "filtering" behaviors (see REQ-9).

Therefore, I believe you need to refresh all ndividual mappinga. This 
particular statement is not made in the document because it is an
application issue.

Hope this helps.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Matthews, Philip (Philip)
> Sent: Wednesday, December 21, 2005 08:29
> To: Pyda Srisuresh
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] Question about 
> draft-ietf-behave-nat-udp-04 in aP2P application
> 
> 
> Suresh:
> 
> Thanks very much for replying with your pointer
> and reminding me about draft-ford-behave-app-01.
> 
> I took a quick look through draft-ford-behave-app-01.txt and
> in addition to the text you quote below, I saw the following
> statement:
> 
>    BEHAVE-compliant NATs are required to support Address Restricted 
>    Cone NAT Behavior, which essentially resets the idle timer for ALL
>    sessions for a particular binding (i.e., involving a particular
>    private port) whenever outbound traffic is seen from that private
>    port on ANY such session.
> 
> What is the justification for this statement? 
> 
> That is, where in draft-ietf-behave-nat-udp-04 is a statement 
> to this effect made?
> 
> Given that draft-ford-behave-app-01 is not yet a WG document,
> I think it would be good to have some statement in 
> draft-ietf-behave-nat-udp-04.
> 
> - Philip
> 
> 
> > -----Original Message-----
> > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx]
> > Sent: December 21, 2005 11:16
> > To: Matthews, Philip (Philip)
> > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Ietf-behave] Question about 
> > draft-ietf-behave-nat-udp-04 in a P2P application
> > 
> > Philip,
> > 
> > The application design guideline draft,
> > <draft-ford-behave-app-01.txt> has the
> > following in section 3.1 to address your question. Hope this helps. 
> > 
> > REQ-6  Applications wishing to accept connections from other peers
> >        after registering via UDP with one or more rendezvous servers
> >        MUST send periodic outgoing UDP "keep-alive" packets to at
> >        least one rendezvous server, at least once within the 
> >        BEHAVE-compliant NAT UDP timeout (2 minutes).
> > 
> > cheers,
> > suresh
> > 
> > --- "Matthews, Philip (Philip)" <matthewsp@xxxxxxxxx> wrote:
> > 
> > > Francois and Cullen:
> > > 
> > > I have a question about the behavior of a NAT "N" that is 
> compliant 
> > > with draft-ietf-behave-nat-udp-04.
> > > 
> > > Say that NAT N implements the more stringent filtering 
> behaviour of 
> > > "Address dependent filtering" (REQ-8), and say that, 
> despite this, I 
> > > am trying to write a peer-to-peer application A which is located 
> > > behind NAT N and which maintains UDP connections with 20 
> other peers 
> > > B,C,D,.... Application A uses the same address and port for all 
> > > these
> > connections.
> > > 
> > > To maintain the appropriate bindings in NAT "N", so that
> > application A
> > > can receive
> > > packets from each of these peers, must application A send a
> > UDP packet
> > > to all 20 peers B,C,D,... every 2 minutes, or can
> > application A send a
> > > UDP packet
> > > to just one of these peers every 2 minutes?
> > > 
> > > (For simplicity, assume NAT "N" has a "NAT inbound refresh
> > behavior" of
> > > False).
> > > 
> > > I am hoping, of course, that a packet every 2 minutes to
> > just ONE peer
> > > will be
> > > sufficient to maintain all these mappings. However, I 
> cannot seem to 
> > > find any words one way or another about this in the 
> document. Am I 
> > > missing something?
> > > 
> > > - Philip
> > > 
> > > _______________________________________________
> > > Ietf-behave mailing list
> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > > 
> > 
> > 
> > 
> > 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 4 Jan 2006 12:23:06 -0800 (PST)

> So the statement you are refering to needs to be modified in the

[suresh] You are right. REQ-8, as it stands, does not mandate Address
restricted Cone NAT. This need to be fixed. I.e., a statement that says that
NAT MUST enforce one of "Endpoint independent filtering" behavior or "Address
dependent filtering"
behavior should be added to the current REQ-8. As I recall, there was a long
discussion on whether to mandate Address restricted Cone NAT (EF=A) or Full
Cone NAT (EF=I). But, I belive, everyone agreed it must be one of these two.
The final text missed this subtility and implies that a minimally compliant NAT
device doesnt have to be either of the two. As it stands, even a NAT device
with EF=P would be behave compliant. That is not right.

Below is how REQ-8 currently reads:

REQ-8: If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint independent filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address dependent
      filtering" behavior.
      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

cheers,
suresh