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

From: "Matthews, Philip (Philip)" <[email-masked]>
Date: Tue, 3 Jan 2006 11:21:50 -0800 (PST)

Francois:

Thanks very much for your reply.

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

Do you really mean REQ-9 "Hairpinning"?

It sounds like this issue was already discussed on the mailing list.
Can you give me a pointer so I can go back and read the discussion?

- Philip

> -----Original Message-----
> From: Francois Audet [mailto:audet@xxxxxxxxxx] 
> Sent: January 3, 2006 14:06
> To: Matthews, Philip (Philip); Pyda Srisuresh; Cullen Jennings
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] Question about 
> draft-ietf-behave-nat-udp-04 in aP2P application
> 
> 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: "Francois Audet" <[email-masked]>
Date: Tue, 3 Jan 2006 13:07:47 -0800 (PST)

> Do you really mean REQ-9 "Hairpinning"?

Oops, I meant REQ-8. Sorry.

> It sounds like this issue was already discussed on the 
> mailing list. Can you give me a pointer so I can go back and 
> read the discussion?

Section 4.4 of draft-ietf-behave-nat-udp-01
(http://www.faqs.org/ftp/internet-drafts/draft-ietf-behave-nat-udp-01.tx
t) talked about this. REQ-6b covered
this particular point.

The following archive shows when both 4.4 and 6b where removed:
http://list.sipfoundry.org/archive/ietf-behave/msg00799.html

> > application, it was out-of-scope of draft-behave-nat-udp to 
> talk about
> > applications. 
> > > 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:
> > > 
> > > 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-ford-behave-app-01.txt> has the following in 
> section 3.1 to 
> > > > address your question. Hope
> > this helps.
> > > > 
> > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx