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

From: "Francois Audet" <[email-masked]>
Date: Wed, 4 Jan 2006 13:37:47 -0800 (PST)

The wording of REQ-8 reflects the agreement of IETF 63, and is what will
be published.

Please read the meeting report if not clear.

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Wednesday, January 04, 2006 12:23
> To: Audet, Francois [SC100:9T51:EXCH]; Matthews, Philip 
> (Philip); Cullen Jennings
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] Question about 
> draft-ietf-behave-nat-udp-04 in aP2P application
> 
> 
> 
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > 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.
> > 
> 
> [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
> 
> 
> > 
> > 
> > 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 14:21:44 -0800 (PST)

I did read the IETF63 agreement and donot have a problem with that. I am
refering to the implication from the wording of REQ-8 that a NAT device with a
filtering behavior of EF=P is behave compliant.

Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to have been
reviewed and approved by the WG and the IESG? 

cheers,
suresh