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

From: "Matthews, Philip (Philip)" <[email-masked]>
Date: Wed, 4 Jan 2006 13:32:07 -0800 (PST)

Francois:

Thanks for the pointer to the mailing list archives.
I read through it, and have a better understanding now of why you
took REQ-6b out.

As you said, it seems like an application needs to refresh all
the individual mappings.

Thanks again for your help.

- Philip

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

Hi everyone,

Since I recently got confronted with the following behavior, i think one 
definition is missing at point 4.1 ...  The following address and port 
mapping behavior are defined: ...

I would call it a Port Dependent Mapping which means:

   +------+                 +------+  x
   |  Y1  |                 |  Y2  |  t
   +--+---+                 +---+--+  e
      | Y1:y1            Y2:y2  |     r
      +----------+   +----------+     n
                 |   |                a
         X1':x1' |   | X2':x2'        l
              +--+---+-+
   ...........|   NAT  |...............
              +--+---+-+              I
                 |   |                n
             X:x |   | X:x            t
                ++---++               e
                |  X  |               r
                +-----+               n
                                      a
      Port Dependent Mapping:
         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external Port address, regardless of the external IP.
         Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals
         y1.
Kind regards,

--
Karlheinz Wurm,
Skype Technologies S.A.
callto://wurm
+372 536 48 166
Get Skype from http://www.skype.net
We're hiring http://www.skype.net/company/jobs
--
This electronic transmission and any attached files are solely for the
intended recipient and may contain information that is privileged,
confidential or otherwise protected from disclosure. Any review,
retransmission, dissemination or other use, including taking any
action concerning this information by anyone other than the intended
recipient, is prohibited. If you are not the intended recipient or
have received this communication in error, please immediately notify
the sender and destroy this communication.
begin:vcard
fn:Karlheinz Wurm
n:Wurm;Karlheinz
email;internet:karlheinz.wurm@xxxxxxxxx
tel;work:+1 (415) 508-3653
tel;cell:+372 536 369 75
x-mozilla-html:FALSE
version:2.1
end:vcard