From huang-ming.pan at comcast.net Sat Jul 1 00:47:41 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 30 Jun 2006 21:47:41 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> Message-ID: <000701c69cc9$7cab2bb0$899cfea9@comcast.net> Thanks for the understanding. There are different ways to say an "egg", but an egg can never become an elk, I guess. Classifications (terms) can change but capabilities won't. There seems rare "sorts" of NATs behind which a node can act as SN w/o nightmare. Peter ----- Original Message ----- From: Adam Fisk To: Peter Pan Cc: Cullen Jennings ; p2p-sip at cs.columbia.edu Sent: Friday, June 30, 2006 8:53 PM Subject: Re: [p2p-sip] STUN (rfc3489) My understanding is that those terms for NATs have been deemed inadequate for describing NAT behavior in the field. I'm not up to speed on latest STUN drafts, but I believe Cullen's link gives the appropriate descriptions of the newer, more accurate NAT classifications. -Adam On 6/12/06, Peter Pan wrote: > On Jun 12, 2006, at 10:24 AM, Peter Pan wrote: > > > Is it possible to realize a STUN sever defined by > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > > discover > > the NAT type before a STUN client? > > I have no idea what you mean by NAT type but if what you mean is the > classification in RFC 3489, then NO. If what you mean is enough to > detect connectivity such as used by ICE, then YES. By NAT type I meant those terms such as "full-cone", "ip-restricted", "port-restricted" and "symmetric" that seem widely used in voip industry. ( http://www.voip-info.org/wiki-STUN, or http://en.wikipedia.org/wiki/Symmetric_NAT) Never mind it. Sounds like P2PSIP no more needs that info. _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From gregd at research.panasonic.com Sun Jul 2 16:29:00 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Sun, 02 Jul 2006 16:29:00 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <000701c69cc9$7cab2bb0$899cfea9@comcast.net> References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> Message-ID: <44A82C8C.80205@research.panasonic.com> Peter Pan wrote: > Thanks for the understanding. > > There are different ways to say an "egg", but an egg can never become an > elk, I guess. > > Classifications (terms) can change but capabilities won't. > > There seems rare "sorts" of NATs behind which a node can act as SN w/o > nightmare. But unless the system knows beforehand, it can't use this capability, as it cannot be reliably detected. Working for unknown subsets of NATs isn't a useful requirement IMO. Greg From lowekamp at cs.wm.edu Sun Jul 2 22:56:38 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Sun, 2 Jul 2006 22:56:38 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <44A82C8C.80205@research.panasonic.com> References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> Message-ID: On 7/2/06, Greg Daley wrote: > Peter Pan wrote: > > There seems rare "sorts" of NATs behind which a node can act as SN w/o > > nightmare. > > But unless the system knows beforehand, it can't use this capability, > as it cannot be reliably detected. > > Working for unknown subsets of NATs isn't a useful requirement IMO. > > Greg My experience has been that most of the current cheaper home-model NATs tend to be this desireable type (independent mapping, independent filtering), so I wouldn't say they're rare. But they might be behind an ISP's firewall or the actual node might be running iptables, so things can be a lot more complex, but it certainly isn't an unusual case to find a node behind a NAT that can participate fully in an overlay. I don't think we need to worry about resolving this right now. There are ways that nodes behind NATs can participate fully in an overlay, and some systems may wish to figure out which can do so, others with central servers wouldn't. Figuring that out is an issue for those deploying a system, not for those of us trying to work out a protocol. Bruce From gregd at research.panasonic.com Sun Jul 2 23:01:10 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Sun, 02 Jul 2006 23:01:10 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> Message-ID: <44A88876.3070107@research.panasonic.com> Hi Bruce, Bruce Lowekamp wrote: [cut] >> But unless the system knows beforehand, it can't use this capability, >> as it cannot be reliably detected. >> >> Working for unknown subsets of NATs isn't a useful requirement IMO. >> >> Greg > > My experience has been that most of the current cheaper home-model > NATs tend to be this desireable type (independent mapping, independent > filtering), so I wouldn't say they're rare. But they might be behind > an ISP's firewall or the actual node might be running iptables, so > things can be a lot more complex, but it certainly isn't an unusual > case to find a node behind a NAT that can participate fully in an > overlay. > > I don't think we need to worry about resolving this right now. There > are ways that nodes behind NATs can participate fully in an overlay, > and some systems may wish to figure out which can do so, others with > central servers wouldn't. Figuring that out is an issue for those > deploying a system, not for those of us trying to work out a protocol. On this I agree, let's not spend time trying to work out the protocol details of such a system. We've probably got ways for devices behind NATs to get access to P2P services, through Super Peers and STUN Relays (TURN). Greg From sgurminder at gmail.com Mon Jul 3 05:32:25 2006 From: sgurminder at gmail.com (Gurminder) Date: Mon, 3 Jul 2006 15:02:25 +0530 Subject: [p2p-sip] sip in ad-hoc n/ws In-Reply-To: <44A55379.2050405@research.panasonic.com> References: <44A55379.2050405@research.panasonic.com> Message-ID: Thanks to jose and Greg, for showing me the way. yes, I understand now the point that how sip in Ad-hoc n/ws and p2p-sip differ. With refernce to your suggestions, I will use DHT for data(Ipaddress) storage. The Idea goes like this. I have a softphone as application, AODV implementation and a DHT implementation. When a node will come up, its presence will be stored in network, using concept of key-> data mapping. Key in this case will be name of person and data will be the Ip address. Softphone will get a list of all the nodes in the network as the keys. Instead of querying for data as is case in filesharing systems which search the key index for filename key, we will allow the DHT implementation to show all the data to softphone in a list form. For this aim in mind I am not able to decide which DHT implementation will serve my purpose, Ofcourse I have to do changes in present implementations Like Bamboo, Chord, Tapastry...etc. I am looking for something with implementation in C. Please give me your valuable suggestions to solve the purpose....sorry if it appears Offtopic. Gurminder Singh. On 6/30/06, Greg Daley < gregd at research.panasonic.com> wrote: > > Hi Gurminder, > > The issues of Adhoc network deployment and application/session > layer SIP deployment are logically separate. > > The DAD/Address configuration operations you mention are > required for every application, not just SIP. > > It may be that in general on the Internet, additional > configuration may be passed along with address configuration, > as in DHCP, but this is not strictly a function of > networking or addressing configuration. > > So we should probably not assume analogous operations > exist in Ad-hoc networks. > > And we had better not rely on anything like them for P2P-SIP > networks. > > All P2P-SIP needs is addressing and packet carriage services, > like other applications. Its in no way relies on special > properties of the Ad-hoc network. > > Let's not conflate Ad-hoc and P2P-SIP concepts at this > formative stage. > > It's an interesting application domain, but should have no > bearing on the protocols. > > Greg > > > Gurminder wrote: > > Hi, > > I am working on an application which requires decentralised > > sip. Actually it is, providing VoIP services in Ad-hoc n/ws as in > > Disaster scenario, also I have seen this objective in one of slides of > > David, Bruce and Ensuoo. > > > > Before knowing about this p2p-sip project, we tried a design for this > > kind of application. > > > > Scenario is wireless mobile Ad-hoc n/ws using 802.11 b > > > > #To communicate to each other all nodes need to have unique IP, (thought > > of using Duplicate Address Detection) > > #Routing of messages will be done using AODV, so all should support it, > > #Each node should broadcast its presence to all others in network. > > > > Issues: > > * How to do DAD? > > * Does node need proxy services? > > As such there can be no centralised proxy server so every node will have > > > a proxy server on it, > > So job of proxy server will be to perform lookups (in my view). > > > > Work Done: > > Tested voice call using Sip on multihop mobile n/w using AODV. > > > > So please tell me how this objective can be achieved or any other better > > > design or idea for such application. > > > > Waiting for all of your valuable suggestions > > Gurminder Singh > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060703/4e203d6d/attachment.html From huang-ming.pan at comcast.net Mon Jul 3 11:23:58 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 3 Jul 2006 08:23:58 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> Message-ID: <001b01c69eb4$b7cb1740$030aa8c0@comcast.net> > But unless the system knows beforehand, it can't use this capability, > as it cannot be reliably detected. > > Working for unknown subsets of NATs isn't a useful requirement IMO. > Capability detection of NAT (or more appropriate to say, of node) seems a well-known technology for many years. Or, nothing would be worth $ billions. I don't mind at all any newer definition of the technology, just as I cannot forbid the sky from raining or my mother from remarrying :) Peter From huang-ming.pan at comcast.net Mon Jul 3 12:26:56 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 3 Jul 2006 09:26:56 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> Message-ID: <004601c69ebd$80a1e920$030aa8c0@comcast.net> > I don't think we need to worry about resolving this right now. When can this start to be worried? > There are ways that nodes behind NATs can participate fully in an overlay, Will ways other than "direct p2p link" jeopardize the initiative of "P2P"SIP? > and some systems may wish to figure out which can do so, others with > central servers wouldn't. Do these "others with central server" fall into P2PSIP category? (why they P2P SIP w/o P2P?) > Figuring that out is an issue for those > deploying a system, not for those of us trying to work out a protocol. > Is "a" protocol enough? It sounds SO SIMPLE :) From gregd at research.panasonic.com Mon Jul 3 16:06:20 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Mon, 03 Jul 2006 16:06:20 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <001b01c69eb4$b7cb1740$030aa8c0@comcast.net> References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> <001b01c69eb4$b7cb1740$030aa8c0@comcast.net> Message-ID: <44A978BC.40106@research.panasonic.com> Dear Peter. Peter Pan wrote: >> But unless the system knows beforehand, it can't use this capability, >> as it cannot be reliably detected. >> >> Working for unknown subsets of NATs isn't a useful requirement IMO. >> > > Capability detection of NAT (or more appropriate to say, of node) seems a > well-known technology for many years. Or, nothing would be worth $ billions. The issue isn't about new devices. If new devices are deployed, they can be IPv6 capable, or UPNP. It's about writing protocols that work with legacy services which cannot be upgraded. The existing NAT Detection in RFC3489 is deprecated in the draft precisely because the unreliability of the detection decreases its worth. > I don't mind at all any newer definition of the technology, just as I cannot > forbid the sky from raining or my mother from remarrying :) I hope that you get your wish in both cases anyway. Greg From huang-ming.pan at comcast.net Mon Jul 3 17:08:25 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 3 Jul 2006 14:08:25 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> <000701c69cc9$7cab2bb0$899cfea9@comcast.net> <44A82C8C.80205@research.panasonic.com> <001b01c69eb4$b7cb1740$030aa8c0@comcast.net> <44A978BC.40106@research.panasonic.com> Message-ID: <004701c69ee4$d3ca2410$7f0010ac@pi2000> > >> But unless the system knows beforehand, it can't use this capability, > >> as it cannot be reliably detected. > >> > >> Working for unknown subsets of NATs isn't a useful requirement IMO. > >> > > > > Capability detection of NAT (or more appropriate to say, of node) seems a > > well-known technology for many years. Or, nothing would be worth $ billions. > > The issue isn't about new devices. > If new devices are deployed, they can be IPv6 capable, or UPNP. Wow.... Regardless of new/old devices, I would rather count on you than on the better-looking IPv6 or uPnP |o|. > It's about writing protocols that work with legacy services which > cannot be upgraded. > > The existing NAT Detection in RFC3489 is deprecated in the draft > precisely because the unreliability of the detection decreases > its worth. NMW, RFC3489 should be deprecated here since it cannot fit P2P well, IMU. > > I don't mind at all any newer definition of the technology, just as I cannot > > forbid the sky from raining or my mother from remarrying :) > > I hope that you get your wish in both cases anyway. Your blessings is too late for the *blessed* communist (Chairman Mao of China) who expressed the two wishes in his sparkling sayings after his dear comrade had fled for Russia : -(O) Peter From spencer at mcsr-labs.org Tue Jul 4 09:07:42 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 4 Jul 2006 08:07:42 -0500 Subject: [p2p-sip] Fw: STUN (rfc3489) Message-ID: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> Rather than just posting an "I agree with Greg on this one" note, I'll ask the more charter-related question - is it our intention to let other people work on NAT traversal while we work on P2P-SIP without much focus on NAT traversal, and then look at the state of NAT traversal when we've done our own work? Thanks, Spencer ----- Original Message ----- From: "Greg Daley" To: "Peter Pan" Cc: Sent: Monday, July 03, 2006 3:06 PM Subject: Re: [p2p-sip] STUN (rfc3489) > Dear Peter. > > Peter Pan wrote: >>> But unless the system knows beforehand, it can't use this capability, >>> as it cannot be reliably detected. >>> >>> Working for unknown subsets of NATs isn't a useful requirement IMO. >>> >> >> Capability detection of NAT (or more appropriate to say, of node) seems a >> well-known technology for many years. Or, nothing would be worth $ >> billions. > > The issue isn't about new devices. > If new devices are deployed, they can be IPv6 capable, or UPNP. > > It's about writing protocols that work with legacy services which > cannot be upgraded. > > The existing NAT Detection in RFC3489 is deprecated in the draft > precisely because the unreliability of the detection decreases > its worth. > > >> I don't mind at all any newer definition of the technology, just as I >> cannot >> forbid the sky from raining or my mother from remarrying :) > > I hope that you get your wish in both cases anyway. > > Greg > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From bryan at ethernot.org Tue Jul 4 09:14:31 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 4 Jul 2006 09:14:31 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> Message-ID: <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> My personal hope is that we consider NAT traversal as an important and integral issue, but any actual new work in the area be done in other working groups. I think we should architect our protocols to work with NATs, and if needed refer problems (if any) with the current suite of tools to other WGs (BEHAVE, MMUSIC, or what have you). David On 7/4/06, Spencer Dawkins wrote: > Rather than just posting an "I agree with Greg on this one" note, I'll ask > the more charter-related question - is it our intention to let other people > work on NAT traversal while we work on P2P-SIP without much focus on NAT > traversal, and then look at the state of NAT traversal when we've done our > own work? > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Greg Daley" > To: "Peter Pan" > Cc: > Sent: Monday, July 03, 2006 3:06 PM > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > Dear Peter. > > > > Peter Pan wrote: > >>> But unless the system knows beforehand, it can't use this capability, > >>> as it cannot be reliably detected. > >>> > >>> Working for unknown subsets of NATs isn't a useful requirement IMO. > >>> > >> > >> Capability detection of NAT (or more appropriate to say, of node) seems a > >> well-known technology for many years. Or, nothing would be worth $ > >> billions. > > > > The issue isn't about new devices. > > If new devices are deployed, they can be IPv6 capable, or UPNP. > > > > It's about writing protocols that work with legacy services which > > cannot be upgraded. > > > > The existing NAT Detection in RFC3489 is deprecated in the draft > > precisely because the unreliability of the detection decreases > > its worth. > > > > > >> I don't mind at all any newer definition of the technology, just as I > >> cannot > >> forbid the sky from raining or my mother from remarrying :) > > > > I hope that you get your wish in both cases anyway. > > > > Greg > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From spencer at mcsr-labs.org Tue Jul 4 10:22:52 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Tue, 4 Jul 2006 09:22:52 -0500 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> Message-ID: <00b101c69f75$563a5010$0300a8c0@china.huawei.com> My hope as well - that's why I'm asking! Spencer > My personal hope is that we consider NAT traversal as an important and > integral issue, but any actual new work in the area be done in other > working groups. I think we should architect our protocols to work with > NATs, and if needed refer problems (if any) with the current suite of > tools to other WGs (BEHAVE, MMUSIC, or what have you). > > David From enrico.marocco at telecomitalia.it Tue Jul 4 10:30:26 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Tue, 04 Jul 2006 16:30:26 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> Message-ID: <44AA7B82.5030009@telecomitalia.it> Spencer Dawkins wrote: > Rather than just posting an "I agree with Greg on this one" note, I'll ask > the more charter-related question - is it our intention to let other people > work on NAT traversal while we work on P2P-SIP without much focus on NAT > traversal, and then look at the state of NAT traversal when we've done our > own work? Mechanisms for NAT traversal -- binding discovery, connectivity check, binding keepalive as well as media connectivity establishment -- will be those defined by BEHAVE and MMUSIC WGs. What we have to start thinking from the beginning is if/when/how it's worth adopting such mechanisms for allowing peers behind NATs to participate in distributed service implementation. Enrico From tjc at ecs.soton.ac.uk Tue Jul 4 10:28:29 2006 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 4 Jul 2006 15:28:29 +0100 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00b101c69f75$563a5010$0300a8c0@china.huawei.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> Message-ID: <20060704142829.GA1723@login.ecs.soton.ac.uk> On Tue, Jul 04, 2006 at 09:22:52AM -0500, Spencer Dawkins wrote: > My hope as well - that's why I'm asking! > > Spencer > > > My personal hope is that we consider NAT traversal as an important and > > integral issue, but any actual new work in the area be done in other > > working groups. I think we should architect our protocols to work with > > NATs, and if needed refer problems (if any) with the current suite of > > tools to other WGs (BEHAVE, MMUSIC, or what have you). But how much complexity is "architecting our protocols to work with NATs" going to add? -- Tim/::1 From huang-ming.pan at comcast.net Tue Jul 4 14:09:52 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Tue, 4 Jul 2006 11:09:52 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com><8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com><00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> Message-ID: <002c01c69f95$0c267bf0$030aa8c0@comcast.net> > > > My personal hope is that we consider NAT traversal as an important and > > > integral issue, but any actual new work in the area be done in other > > > working groups. I think we should architect our protocols to work with > > > NATs, and if needed refer problems (if any) with the current suite of > > > tools to other WGs (BEHAVE, MMUSIC, or what have you). >> Mechanisms for NAT traversal -- binding discovery, connectivity check, > >binding keepalive as well as media connectivity establishment -- will be > >those defined by BEHAVE and MMUSIC WGs. What we have to start thinking > >from the beginning is if/when/how it's worth adopting such mechanisms > >for allowing peers behind NATs to participate in distributed service > >implementation. > But how much complexity is "architecting our protocols to work with NATs" > going to add? > Perhaps you would not like to exclude the preludes for P2PSIP to dance with these WGs. RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is used to discover the STUN server following these procedures...The DNS SRV service name is 'stun' (1)...The default port for STUN requests is 3478 (2)...STUN makes use of a shared secret between client and server(3)... A: This is the "change IP" flag. If true, it requests the server to send the Binding Response with a different IP address than the one the Binding Request was received on(4) " ASSUMING no central STUN server but many SNs acting as *volatile* STUN servers (VSS), these can be regretful among others: (1). DNS may be infeasible in serverless world, not to mention SRV. (2). Any well-known port (3478) or ephemeral private port is unreachable if most VSSs are to be behind NATs. (3). Shared secrets between STUN clients and VSSs may turn to a chicken or an egg. (4). All goodness of the "change IP" flag vanishes with normal single-IP VSSs w/o *hard wires* between. (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs. Maybe I've decipered the bis wrong or maybe P2PSIP has reserved more seats for central servers than for serverlessness, otherwise wish these odds and sods weren't considered deployment-specific. Peter From gregd at research.panasonic.com Wed Jul 5 11:21:11 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Wed, 05 Jul 2006 11:21:11 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <002c01c69f95$0c267bf0$030aa8c0@comcast.net> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com><8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com><00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> Message-ID: <44ABD8E7.3050904@research.panasonic.com> Hi Peter Peter Pan wrote: [cut] > > Perhaps you would not like to exclude the preludes for P2PSIP to dance with > these WGs. > > RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is used to > discover the STUN server following these procedures...The DNS SRV service > name is 'stun' (1)...The default port for STUN requests is 3478 (2)...STUN > makes use of a shared secret between client and server(3)... A: This is > the "change IP" flag. If true, it requests the server to send the Binding > Response with a different IP address than the one the Binding Request was > received on(4) " > > ASSUMING no central STUN server but many SNs acting as *volatile* STUN > servers (VSS), these can be regretful among others: > > (1). DNS may be infeasible in serverless world, not to mention SRV. Discovery will have to be done another way. My guess is that we will use the same mechanisms which are needed for Super Peer (SP) discovery. > (2). Any well-known port (3478) or ephemeral private port is unreachable if > most VSSs are to be behind NATs. This has no impact on the protocol itself, and can be included in the discovery information gleaned previously. > (3). Shared secrets between STUN clients and VSSs may turn to a chicken or > an egg. That's not true. The Shared-Secret establishment in STUN allows previously unknown hosts to gain binding access. As a STUN Relay, it's feasible to use a different authentication mechanism (perhaps based on the credentials to contact a Super Peer) but this is not strictly necessary. I know, we've implemented STUN Relay with the short term passwords, as described in RFC3489bis. > (4). All goodness of the "change IP" flag vanishes with normal single-IP > VSSs w/o *hard wires* between. "Change IP" is not needed in RFC3489bis. > (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs. Neither is the case. We have running code. Greg From huang-ming.pan at comcast.net Wed Jul 5 12:08:47 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 5 Jul 2006 09:08:47 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) Message-ID: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> By the way, could you also reveal your *standard* way of distributing *different* shared-secret between *different peer pairs* for stronly secure STUN operation to proceed? Your kindness can also save us many exchanges of spits on a topic that has lasted for so long time. I'm sure everyone here will appreciate it very much if it is indeed all standard and working. ^_^ Peter ----- Original Message ----- From: "Peter Pan" To: "Greg Daley" Sent: Wednesday, July 05, 2006 8:58 AM Subject: Re: [p2p-sip] Fw: STUN (rfc3489) > Hi Greg, > > Thanks for the comments. > > May I know how you are using RFC 3489bis or which existing RFC(s) you are > using, without the "change IP" flag, to learn a node behind some *friendly > types* of NAT can act as a SN? > > Peter > ----- Original Message ----- > From: "Greg Daley" > To: "Peter Pan" > Cc: "Tim Chown" ; "Spencer Dawkins" > ; > Sent: Wednesday, July 05, 2006 8:21 AM > Subject: Re: [p2p-sip] Fw: STUN (rfc3489) > > > > Hi Peter > > > > Peter Pan wrote: > > [cut] > > > > > > Perhaps you would not like to exclude the preludes for P2PSIP to dance > with > > > these WGs. > > > > > > RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is > used to > > > discover the STUN server following these procedures...The DNS SRV > service > > > name is 'stun' (1)...The default port for STUN requests is 3478 > (2)...STUN > > > makes use of a shared secret between client and server(3)... A: This > is > > > the "change IP" flag. If true, it requests the server to send the > Binding > > > Response with a different IP address than the one the Binding Request > was > > > received on(4) " > > > > > > ASSUMING no central STUN server but many SNs acting as *volatile* STUN > > > servers (VSS), these can be regretful among others: > > > > > > (1). DNS may be infeasible in serverless world, not to mention SRV. > > > > Discovery will have to be done another way. > > My guess is that we will use the same mechanisms which are > > needed for Super Peer (SP) discovery. > > > > > (2). Any well-known port (3478) or ephemeral private port is unreachable > if > > > most VSSs are to be behind NATs. > > > > This has no impact on the protocol itself, and can be included in the > > discovery information gleaned previously. > > > > > (3). Shared secrets between STUN clients and VSSs may turn to a chicken > or > > > an egg. > > > > That's not true. > > > > The Shared-Secret establishment in STUN allows previously unknown hosts > > to gain binding access. > > > > As a STUN Relay, it's feasible to use a different authentication > > mechanism (perhaps based on the credentials to contact a Super Peer) > > but this is not strictly necessary. > > > > I know, we've implemented STUN Relay with the short term passwords, > > as described in RFC3489bis. > > > > > (4). All goodness of the "change IP" flag vanishes with normal single-IP > > > VSSs w/o *hard wires* between. > > > > "Change IP" is not needed in RFC3489bis. > > > > > (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs. > > > > Neither is the case. > > > > We have running code. > > > > Greg > From enrico.marocco at telecomitalia.it Wed Jul 5 12:24:48 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 05 Jul 2006 18:24:48 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <44ABD8E7.3050904@research.panasonic.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> Message-ID: <44ABE7D0.4080304@telecomitalia.it> Greg Daley wrote: >> RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is used to >> discover the STUN server following these procedures...The DNS SRV service >> name is 'stun' (1)...The default port for STUN requests is 3478 (2)...STUN >> makes use of a shared secret between client and server(3)... A: This is >> the "change IP" flag. If true, it requests the server to send the Binding >> Response with a different IP address than the one the Binding Request was >> received on(4) " >> >> ASSUMING no central STUN server but many SNs acting as *volatile* STUN >> servers (VSS), these can be regretful among others: >> >> (1). DNS may be infeasible in serverless world, not to mention SRV. > > Discovery will have to be done another way. > My guess is that we will use the same mechanisms which are > needed for Super Peer (SP) discovery. As long as PUT/GET operations do not require STUN, we can rely on lookup functionalites provided by the overlay. For example, when a device which has a SIP UA and a STUN Server on joins the overlay, it will bind its contact address both to its AOR and to a special URN which identifies the STUN service (e.g. "urn:service:stun"). Enrico From huang-ming.pan at comcast.net Wed Jul 5 12:37:10 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 5 Jul 2006 09:37:10 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> Message-ID: <004d01c6a051$43910350$030aa8c0@comcast.net> > > > > Discovery will have to be done another way. > > My guess is that we will use the same mechanisms which are > > needed for Super Peer (SP) discovery. > > As long as PUT/GET operations do not require STUN, we can rely on lookup > functionalites provided by the overlay. For example, when a device > which has a SIP UA and a STUN Server on joins the overlay, it will bind > its contact address both to its AOR and to a special URN which > identifies the STUN service (e.g. "urn:service:stun"). > Hi, Enrico. Could you further elaborate your oracle, for examples, about whether on earth STUN in whatever form is required, when it is used relative to node joining and AOR binding, and how, should it be required? Thanks a lot! Peter From philip_matthews at magma.ca Wed Jul 5 13:45:32 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 5 Jul 2006 13:45:32 -0400 Subject: [p2p-sip] Where will P2PSIP NAT work be done (was: Fw: STUN (rfc3489)) In-Reply-To: <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> Message-ID: I mostly agree with David on this one. I suspect that much of the work on NAT traversal will happen in other WGs, even if it is done for P2PSIP purposes. For example, I have been spending a fair amount of time recently on ICE (= an MMUSIC protocol for setting up connections between two peers in NAT situations) to make sure it will work well in P2PSIP applications. - Philip On 4-Jul-06, at 09:14 , David A. Bryan wrote: > My personal hope is that we consider NAT traversal as an important and > integral issue, but any actual new work in the area be done in other > working groups. I think we should architect our protocols to work with > NATs, and if needed refer problems (if any) with the current suite of > tools to other WGs (BEHAVE, MMUSIC, or what have you). > > David > > On 7/4/06, Spencer Dawkins wrote: >> Rather than just posting an "I agree with Greg on this one" note, >> I'll ask >> the more charter-related question - is it our intention to let >> other people >> work on NAT traversal while we work on P2P-SIP without much focus >> on NAT >> traversal, and then look at the state of NAT traversal when we've >> done our >> own work? >> >> Thanks, >> >> Spencer >> >> ----- Original Message ----- >> From: "Greg Daley" >> To: "Peter Pan" >> Cc: >> Sent: Monday, July 03, 2006 3:06 PM >> Subject: Re: [p2p-sip] STUN (rfc3489) >> >> >>> Dear Peter. >>> >>> Peter Pan wrote: >>>>> But unless the system knows beforehand, it can't use this >>>>> capability, >>>>> as it cannot be reliably detected. >>>>> >>>>> Working for unknown subsets of NATs isn't a useful requirement >>>>> IMO. >>>>> >>>> >>>> Capability detection of NAT (or more appropriate to say, of >>>> node) seems a >>>> well-known technology for many years. Or, nothing would be worth $ >>>> billions. >>> >>> The issue isn't about new devices. >>> If new devices are deployed, they can be IPv6 capable, or UPNP. >>> >>> It's about writing protocols that work with legacy services which >>> cannot be upgraded. >>> >>> The existing NAT Detection in RFC3489 is deprecated in the draft >>> precisely because the unreliability of the detection decreases >>> its worth. >>> >>> >>>> I don't mind at all any newer definition of the technology, just >>>> as I >>>> cannot >>>> forbid the sky from raining or my mother from remarrying :) >>> >>> I hope that you get your wish in both cases anyway. >>> >>> Greg >>> _______________________________________________ >>> p2p-sip mailing list >>> p2p-sip at cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> >> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From philip_matthews at magma.ca Wed Jul 5 13:50:28 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 5 Jul 2006 13:50:28 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <20060704142829.GA1723@login.ecs.soton.ac.uk> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> Message-ID: <24192490-43C0-4EA7-833D-018D50DD8BA5@magma.ca> On 4-Jul-06, at 10:28 , Tim Chown wrote: > On Tue, Jul 04, 2006 at 09:22:52AM -0500, Spencer Dawkins wrote: >> My hope as well - that's why I'm asking! >> >> Spencer >> >>> My personal hope is that we consider NAT traversal as an >>> important and >>> integral issue, but any actual new work in the area be done in other >>> working groups. I think we should architect our protocols to work >>> with >>> NATs, and if needed refer problems (if any) with the current >>> suite of >>> tools to other WGs (BEHAVE, MMUSIC, or what have you). > > But how much complexity is "architecting our protocols to work with > NATs" > going to add? > The main complexity I see it adding is the need for peers to route requests on behalf of other peers. - Philip From gregd at research.panasonic.com Wed Jul 5 15:59:57 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Wed, 05 Jul 2006 15:59:57 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> Message-ID: <44AC1A3D.2050707@research.panasonic.com> Hi Peter. Peter Pan wrote: > By the way, could you also reveal your *standard* way of distributing > *different* shared-secret between *different peer pairs* for stronly secure > STUN operation to proceed? We're just using the temporary passwords created with shared-secret-request/response from STUN. There's no identity tied to it, except that provided by certs in TLS. The TLS session protects the shared password generation, and every other (non-TLS protected) message is signed using the HMAC-SHA1 over the message using the shared secret. This protects the allocate-request/response and indication packets from modification. There's no encryption though. It's all in the rfc3489bis document (except I think the existing version is described with MD5). From my reading of ML discussion, I think I read about a move to SHA1. > Your kindness can also save us many exchanges of spits on a topic that has > lasted for so long time. I'm sure everyone here will appreciate it very much > if it is indeed all standard and working. ^_^ It's not rocket science. I read the draft, and picked an authentication method. I didn't implement all of them yet. Greg From dwing at cisco.com Wed Jul 5 16:46:21 2006 From: dwing at cisco.com (Dan Wing) Date: Wed, 5 Jul 2006 13:46:21 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <002c01c69f95$0c267bf0$030aa8c0@comcast.net> Message-ID: <00c901c6a074$15c8f5e0$ad60150a@amer.cisco.com> (for background, I am co-author of rfc3489bis-03 and co-chair of BEHAVE.) > Perhaps you would not like to exclude the preludes for P2PSIP > to dance with these WGs. > > RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is > used to discover the STUN server following these procedures...The > DNS SRV service name is 'stun' (1)...The default port for STUN > requests is 3478 (2)...STUN makes use of a shared secret between > client and server(3)... A: This is the "change IP" flag. If true, > it requests the server to send the Binding Response with a different > IP address than the one the Binding Request was received on(4) " > > ASSUMING no central STUN server but many SNs acting as *volatile* STUN > servers (VSS), these can be regretful among others: > > (1). DNS may be infeasible in serverless world, not to mention SRV. Agreed. You will need to define a STUN usage which won't use DNS but would rather use some other mechanism to find a STUN server. > (2). Any well-known port (3478) or ephemeral private port is > unreachable if most VSSs are to be behind NATs. Agreed. Related to (1). > (3). Shared secrets between STUN clients and VSSs may turn to > a chicken or an egg. The authentication of STUN messages protects against certain on-path attacks. Many threat models don't worry about on-path attackers (who can spoof TCP RSTs, among other things). > (4). All goodness of the "change IP" flag vanishes with > normal single-IP VSSs w/o *hard wires* between. You probably noticed the CHANGED-ADDRESS attribute includes the following text at the end of its section: Issue: should this attribute be made specific to Binding Discovery or moved to another document entirely. RESPONSE-ADDRESS, CHANGE-REQUEST, and SOURCE-ADDRESS all have this same issue, and are being considered for removal from rfc3489bis. > (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs. But P2PSIP's chicken-or-egg problem exists no matter if you use STUN to learn your public IP address+port or if you use something else to learn your public IP address+port: once you learn it, you need to register it. If you know where to register your IP address+port, you can also know where a STUN server can be found. > Maybe I've decipered the bis wrong or maybe P2PSIP has > reserved more seats for central servers than for > serverlessness, otherwise wish these odds and > sods weren't considered deployment-specific. -d From gregd at research.panasonic.com Wed Jul 5 18:40:54 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Wed, 05 Jul 2006 18:40:54 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00c901c6a074$15c8f5e0$ad60150a@amer.cisco.com> References: <00c901c6a074$15c8f5e0$ad60150a@amer.cisco.com> Message-ID: <44AC3FF6.9000806@research.panasonic.com> Dan Wing wrote: [cut] >> (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs. > > But P2PSIP's chicken-or-egg problem exists no matter if you > use STUN to learn your public IP address+port or if you use > something else to learn your public IP address+port: once > you learn it, you need to register it. > > If you know where to register your IP address+port, you can > also know where a STUN server can be found. I guess this is the essential point. Another mechanism needs to be available for either or both of these operations. There's some description of how this may be achieved in a couple of documents, but essentially there may be a combination of multicast and unicast techniques (SLP, SLP DS, DNS SRV, well known address?) One technique (DNS) isn't sufficient if we also want disconnected network cases to work correctly. Greg From dwing at cisco.com Wed Jul 5 18:49:56 2006 From: dwing at cisco.com (Dan Wing) Date: Wed, 5 Jul 2006 15:49:56 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <44AC3FF6.9000806@research.panasonic.com> Message-ID: <013801c6a085$59fc7690$ad60150a@amer.cisco.com> > > If you know where to register your IP address+port, you > > can also know where a STUN server can be found. > > I guess this is the essential point. Another mechanism > needs to be available for either or both of these operations. Yep - solve one and you have solved the other. > There's some description of how this may be achieved > in a couple of documents, but essentially there may be > a combination of multicast and unicast techniques > (SLP, SLP DS, DNS SRV, well known address?) > > One technique (DNS) isn't sufficient if we also want > disconnected network cases to work correctly. Agreed. To do that you're looking to some kind of zeroconf techniques. http://en.wikipedia.org/wiki/Zeroconf has a decent list of solutions and techniques in this space. -d From RADHIKA.R.ROY at saic.com Wed Jul 5 22:05:34 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 5 Jul 2006 22:05:34 -0400 Subject: [p2p-sip] Where will P2PSIP NAT work be done (was: Fw: STUN(r fc3489)) Message-ID: <62D92A9A02BCC845B202323D49A48426209D63@0591-ITS-EXMP02.us.saic.com> Philip: I also agree with this. For example, David's paper (DHT Design for Public Commns System) refers to another paper (NUTSS: SIGCOM 2004) that deals with the FW/NAT crossing for p2p system. This paper shows that STUN/TURN/ICE can also be used p2p system with some extensions. Well this may not be enough to confirm the fact we have a solution at hand for FW/NAT crossing by the p2p system, but it shows how the overall approach of FW/NAT crossing for the p2p system may look like. If this is the case, it is quite possible that the FW/NAT crossing works may be done in other WGs even for the p2p system. By the way, the NUTSS p2p FW/NAT crossing paper shows almost clearly what additional aspects for p2p system in addition what is being done in STUN/TURN/ICE. We may learn the p2p FW/NAT crossing requirements from this paper and others as well. Best regards, Radhika BTW: NSIS QOS signaling protocol and IPSec have developed their own FW/NAT crossing standard. _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews Sent: Wed 7/5/2006 1:45 PM To: Spencer Dawkins Cc: P2P-SIP; David A. Bryan Subject: Re: [p2p-sip] Where will P2PSIP NAT work be done (was: Fw: STUN(rfc3489)) I mostly agree with David on this one. I suspect that much of the work on NAT traversal will happen in other WGs, even if it is done for P2PSIP purposes. For example, I have been spending a fair amount of time recently on ICE (= an MMUSIC protocol for setting up connections between two peers in NAT situations) to make sure it will work well in P2PSIP applications. - Philip On 4-Jul-06, at 09:14 , David A. Bryan wrote: > My personal hope is that we consider NAT traversal as an important and > integral issue, but any actual new work in the area be done in other > working groups. I think we should architect our protocols to work with > NATs, and if needed refer problems (if any) with the current suite of > tools to other WGs (BEHAVE, MMUSIC, or what have you). > > David > From huang-ming.pan at comcast.net Thu Jul 6 02:21:30 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 5 Jul 2006 23:21:30 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com><8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com><00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <001601c6a04b$e17dfec0$030aa8c0@comcast.net> <44AC1775.3070409@research.panasonic.com> Message-ID: <00e501c6a0c4$6bdc6d40$030aa8c0@comcast.net> > > > > May I know how you are using RFC 3489bis or which existing RFC(s) you are > > using, without the "change IP" flag, to learn a node behind some *friendly > > types* of NAT can act as a SN? > > We're not doing NAT type detection. > > Nat type detection is deprecated in RFC3489bis. > As explained before, it's unreliable. > > We're implementing ICE, using STUN (bis) and STUN > Relay, base on the current revisions of > > draft-ietf-behave-rfc3489bis > draft-ietf-mmusic-ice > draft-ietf-behave-turn > > This gives us a STUN relay over which to run media, > and SIP messages. > > There's not much more to say. > > Greg Hi Greg, I bow to these standards and drafts. However, they seems lego only; still need glue and correct order to glue them for full interoperability among products using these standards. This is what I meant "chickens and eggs". Also, by saying "the offer/answer exchange itself must be capable of traversing the NAT. Such traversal is facilitated through signaling elements such as SIP servers, and is outside the scope of this specification...", ICE seems a shotgun mainly for media streams, not a rifle for signaling/overlay msgs to penetrate NAT. (Does it assumed that an overlay and/or a dialog has been formed before ICE is utilized??) When a restricted node can learn its mapped address only, it can think itself super, ignorantly or maliciously. When a restricted address is registered and offered to the others as a SN, overlay inaccuracy is incremented. What if you're offered hundreds or thousands of useless restricted addresses before one of a real SN? Miserably deprecated NAT type detection is the rifle. Rifles may miss sometimes, but to bring down a flying bird 1 rifle excels 3+ shotguns. Peter From huang-ming.pan at comcast.net Thu Jul 6 02:49:27 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 5 Jul 2006 23:49:27 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> Message-ID: <010601c6a0c8$53baeb20$030aa8c0@comcast.net> > Peter Pan wrote: > > By the way, could you also reveal your *standard* way of distributing > > *different* shared-secret between *different peer pairs* for stronly secure > > STUN operation to proceed? > > We're just using the temporary passwords created with > shared-secret-request/response from STUN. > > There's no identity tied to it, except that provided by > certs in TLS. > > The TLS session protects the shared password generation, > and every other (non-TLS protected) message is signed using > the HMAC-SHA1 over the message using the shared secret. > > This protects the allocate-request/response and indication > packets from modification. There's no encryption though. Like sheeps dancing with wolves, the temporary (created) shared secret seems no secret without trusted relationship or TLS. By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, which may fail in usual cases. Peter From huang-ming.pan at comcast.net Thu Jul 6 02:56:41 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 5 Jul 2006 23:56:41 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <013801c6a085$59fc7690$ad60150a@amer.cisco.com> Message-ID: <011e01c6a0c9$5622cdf0$030aa8c0@comcast.net> > > There's some description of how this may be achieved > > in a couple of documents, but essentially there may be > > a combination of multicast and unicast techniques > > (SLP, SLP DS, DNS SRV, well known address?) > > > > One technique (DNS) isn't sufficient if we also want > > disconnected network cases to work correctly. > > Agreed. To do that you're looking to some kind of zeroconf > techniques. http://en.wikipedia.org/wiki/Zeroconf has a > decent list of solutions and techniques in this space. > Hi, Dan. Which (serverless & DNSless) technique do you think the best for WAN or for a P2PSIP universe? Thanks for any light. Peter From enrico.marocco at telecomitalia.it Thu Jul 6 05:28:52 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 06 Jul 2006 11:28:52 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <004d01c6a051$43910350$030aa8c0@comcast.net> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> Message-ID: <44ACD7D4.3010306@telecomitalia.it> Peter Pan wrote: > Could you further elaborate your oracle, for examples, about whether on > earth STUN in whatever form is required, when it is used relative to node > joining and AOR binding, and how, should it be required? I think that natted nodes will need STUN for: + participating in the overlay (i.e. STUN should be coupled with the "peer protocol"); + being reachable (i.e. STUN should be used in some mecanisms similar to those defined in the outbound draft); + establishing media connectivity (i.e. ICE). OTOH, I hope that the "client protocol" would not need any NAT traversal mechanisms. Since its operations have the natted node -- the client -- always as the source and never as the destination, I'm quite confident it won't. That's why I think that once a client is able to query the overlay, it doesn't require any other mechanism for discovering STUN servers. Enrico From slavitch at gmail.com Thu Jul 6 09:08:21 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 6 Jul 2006 09:08:21 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <44ACD7D4.3010306@telecomitalia.it> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> Message-ID: <1fc32c8f0607060608y82703c8md464ed188763cb26@mail.gmail.com> That model is not end to end, which limits functionality. Why should there be a distinction? On 7/6/06, Enrico Marocco wrote: > > > OTOH, I hope that the "client protocol" would not need any NAT traversal > mechanisms. Since its operations have the natted node -- the client -- > always as the source and never as the destination, I'm quite confident > it won't. That's why I think that once a client is able to query the > overlay, it doesn't require any other mechanism for discovering STUN > servers. > > Enrico > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/62d48c3b/attachment.html From enrico.marocco at telecomitalia.it Thu Jul 6 09:29:26 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 06 Jul 2006 15:29:26 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <1fc32c8f0607060608y82703c8md464ed188763cb26@mail.gmail.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <1fc32c8f0607060608y82703c8md464ed188763cb26@mail.gmail.com> Message-ID: <44AD1036.1060601@telecomitalia.it> It *is* end to end. On the client side there is a UA which has not joined the overlay yet, while on the server side there is a SN which, since it has already joined, is reachable from anywhere. There is no infrastructure but the overlay. With "client protocol" and "peer protocol" I'm trying to be consistent with concepts draft; I hope I'm not causing confusion. Enrico Michael Slavitch wrote: > That model is not end to end, which limits functionality. Why should > there be a distinction? > > On 7/6/06, *Enrico Marocco* > wrote: > > > OTOH, I hope that the "client protocol" would not need any NAT traversal > mechanisms. Since its operations have the natted node -- the client -- > always as the source and never as the destination, I'm quite confident > it won't. That's why I think that once a client is able to query the > overlay, it doesn't require any other mechanism for discovering STUN > servers. > > Enrico > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From slavitch at gmail.com Thu Jul 6 10:04:06 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 6 Jul 2006 10:04:06 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <44AD1036.1060601@telecomitalia.it> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <1fc32c8f0607060608y82703c8md464ed188763cb26@mail.gmail.com> <44AD1036.1060601@telecomitalia.it> Message-ID: <1fc32c8f0607060704i51878369m188414259815e6c8@mail.gmail.com> It can be a little confusing, yes, so my apologies. As long as any SN can be placed anywhere I can see no problem. If SN's require configuration and have location dependence based on NAT there may be an issue downstream but let's get going. Regards M On 7/6/06, Enrico Marocco wrote: > > It *is* end to end. On the client side there is a UA which has not > joined the overlay yet, while on the server side there is a SN which, > since it has already joined, is reachable from anywhere. There is no > infrastructure but the overlay. > > With "client protocol" and "peer protocol" I'm trying to be consistent > with concepts draft; I hope I'm not causing confusion. > > Enrico > > Michael Slavitch wrote: > > That model is not end to end, which limits functionality. Why should > > there be a distinction? > > > > On 7/6/06, *Enrico Marocco* > > wrote: > > > > > > OTOH, I hope that the "client protocol" would not need any NAT > traversal > > mechanisms. Since its operations have the natted node -- the client > -- > > always as the source and never as the destination, I'm quite > confident > > it won't. That's why I think that once a client is able to query > the > > overlay, it doesn't require any other mechanism for discovering STUN > > servers. > > > > Enrico > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/c7e5de08/attachment-0001.html From lowekamp at cs.wm.edu Thu Jul 6 10:23:11 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Thu, 6 Jul 2006 10:23:11 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00e501c6a0c4$6bdc6d40$030aa8c0@comcast.net> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <001601c6a04b$e17dfec0$030aa8c0@comcast.net> <44AC1775.3070409@research.panasonic.com> <00e501c6a0c4$6bdc6d40$030aa8c0@comcast.net> Message-ID: On 7/6/06, Peter Pan wrote: > specification...", ICE seems a shotgun mainly for media streams, not a rifle > for signaling/overlay msgs to penetrate NAT. (Does it assumed that an > overlay and/or a dialog has been formed before ICE is utilized??) When a Although ICE has certainly been developed for media streams, I think it may still have an important purpose for P2PSIP overlays. Obviously STUN is the backbone, but ICE is very useful for determining what the best way is to communicate between two nodes that share a control connection with a third node (or nodes). This could be a common case either when two P2PSIP Overlay Clients try to connect to each other or during P2PSIP Overlay Peer Insertion. Bruce From dwing at cisco.com Thu Jul 6 10:30:01 2006 From: dwing at cisco.com (Dan Wing) Date: Thu, 6 Jul 2006 07:30:01 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <011e01c6a0c9$5622cdf0$030aa8c0@comcast.net> Message-ID: <028c01c6a108$af503f40$ad60150a@amer.cisco.com> > > > One technique (DNS) isn't sufficient if we also want > > > disconnected network cases to work correctly. > > > > Agreed. To do that you're looking to some kind of zeroconf > > techniques. http://en.wikipedia.org/wiki/Zeroconf has a > > decent list of solutions and techniques in this space. > > Hi, Dan. > > Which (serverless & DNSless) technique do you think the best > for WAN or for a P2PSIP universe? Thanks for any light. If by WAN you mean the Internet, I don't believe any of the zeroconf techniques cited in that wikipedia article provide a DNS-like, serverless rendezvous service for the Internet. -d From gregd at research.panasonic.com Thu Jul 6 11:20:02 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 06 Jul 2006 11:20:02 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <028c01c6a108$af503f40$ad60150a@amer.cisco.com> References: <028c01c6a108$af503f40$ad60150a@amer.cisco.com> Message-ID: <44AD2A22.7020707@research.panasonic.com> Hi Dan, Dan Wing wrote: [cut] > If by WAN you mean the Internet, I don't believe any of the > zeroconf techniques cited in that wikipedia article provide > a DNS-like, serverless rendezvous service for the Internet. > > -d I think that there are examples of local, and beyond the first hop multicast techniques which can help where available. It's pretty clear though that there's no pervasive L3 multicast system which can be used for this purpose. So the mechanisms for bootstrap may require a set of fixed servers, one would hope that dynamic server information could be cached for later use, in order to aid scalability. I'd guess you'd like to be able to use local zeroconf-like techniques if possible, falling back to dynamic servers, and static servers successively. Greg From huang-ming.pan at comcast.net Thu Jul 6 11:24:24 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 08:24:24 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> Message-ID: <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> > > OTOH, I hope that the "client protocol" would not need any NAT traversal > mechanisms. Since its operations have the natted node -- the client -- > always as the source and never as the destination, I'm quite confident > it won't. That's why I think that once a client is able to query the > overlay, it doesn't require any other mechanism for discovering STUN > servers. > The assumption "once a client is able to query the overlay" is an egg. The optimum "it doesn't require any other mechanism for discovering STUN servers" is its chicken. They seems in a fantasyland. Peter From adamfisk at gmail.com Thu Jul 6 11:33:53 2006 From: adamfisk at gmail.com (Adam Fisk) Date: Thu, 6 Jul 2006 11:33:53 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <001601c6a04b$e17dfec0$030aa8c0@comcast.net> <44AC1775.3070409@research.panasonic.com> <00e501c6a0c4$6bdc6d40$030aa8c0@comcast.net> Message-ID: On 7/6/06, Bruce Lowekamp wrote: > On 7/6/06, Peter Pan wrote: > > > specification...", ICE seems a shotgun mainly for media streams, not a rifle > > for signaling/overlay msgs to penetrate NAT. (Does it assumed that an > > overlay and/or a dialog has been formed before ICE is utilized??) When a > > Although ICE has certainly been developed for media streams, I think > it may still have an important purpose for P2PSIP overlays. Obviously > STUN is the backbone, but ICE is very useful for determining what the > best way is to communicate between two nodes that share a control > connection with a third node (or nodes). This could be a common case > either when two P2PSIP Overlay Clients try to connect to each other or > during P2PSIP Overlay Peer Insertion. Agreed. All of these protocols have been deployed primarily for media streams, aka UDP. There's nothing in ICE that restricts it to UDP, however, just as there's nothing in STUN that restricts it to UDP. In our case, we'd likely advertise TCP addresses for simultaneous open across NATs using ICE. It seems this conversation is getting way off track. If we're talking about using these protocols to have NATted nodes participate in DHTs, that's still a long way off and would be a far greater diversion than this group should pursue at this time, in my humble opinion. NATted peers that cannot open ports using UPnP should just be client/leaf nodes and leave it at that. -Adam From huang-ming.pan at comcast.net Thu Jul 6 11:52:07 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 08:52:07 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <001601c6a04b$e17dfec0$030aa8c0@comcast.net> <44AC1775.3070409@research.panasonic.com> <00e501c6a0c4$6bdc6d40$030aa8c0@comcast.net> Message-ID: <00b701c6a114$22fcab80$030aa8c0@comcast.net> > On 7/6/06, Bruce Lowekamp wrote: > > On 7/6/06, Peter Pan wrote: > > > > > specification...", ICE seems a shotgun mainly for media streams, not a rifle > > > for signaling/overlay msgs to penetrate NAT. (Does it assumed that an > > > overlay and/or a dialog has been formed before ICE is utilized??) When a > > > > Although ICE has certainly been developed for media streams, I think > > it may still have an important purpose for P2PSIP overlays. Obviously > > STUN is the backbone, but ICE is very useful for determining what the > > best way is to communicate between two nodes that share a control > > connection with a third node (or nodes). This could be a common case > > either when two P2PSIP Overlay Clients try to connect to each other or > > during P2PSIP Overlay Peer Insertion. > > Agreed. All of these protocols have been deployed primarily for media > streams, aka UDP. There's nothing in ICE that restricts it to UDP, > however, just as there's nothing in STUN that restricts it to UDP. In > our case, we'd likely advertise TCP addresses for simultaneous open > across NATs using ICE. > > It seems this conversation is getting way off track. If we're talking > about using these protocols to have NATted nodes participate in DHTs, > that's still a long way off and would be a far greater diversion than > this group should pursue at this time, in my humble opinion. Yep, we should have others make king beds. We just stack the king beds to build our house. > NATted peers that cannot open ports using UPnP should just be client/leaf > nodes and leave it at that. > > -Adam Do you or anyone know the percentage of residential or even enterprise users who ever use uPnP? I thought uPnP is used only in Microsoft :-) Peter From gregd at research.panasonic.com Thu Jul 6 11:51:00 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 06 Jul 2006 11:51:00 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <010601c6a0c8$53baeb20$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> Message-ID: <44AD3164.1010402@research.panasonic.com> Peter Pan wrote: [cut] > > Like sheeps dancing with wolves, the temporary (created) shared secret seems > no secret without trusted relationship or TLS. Sure, if you take away TLS it's not secure ;) If you take away a man's legs it's hard for him to walk. Really though, the client can be guaranteed the server is the right one, because of the server's verifiable certificate chain. If it makes sense, and the STUN server wishes to know about the client, mutual authentication based on public keys/certificates can be performed. Even without mutual authentication though, the host may choose to trust the STUN Relay effectively, though the converse isn't necessarily true. This is sufficient to prevent eavesdropping or man-in-the-middle on the delivered secret. > By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, > which may fail in usual cases. Why would you ever try to contact a STUN server behind a NAT (at least from the public Internet)? If the STUN server is on the public Internet and an ordinary peer is behind a NAT, TCP will not fail (firewalls on the other hand...). Greg PS. Can you please not abbreviate STUN server as VSS. It doesn't aid clarity. From enrico.marocco at telecomitalia.it Thu Jul 6 12:10:30 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 06 Jul 2006 18:10:30 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> Message-ID: <44AD35F6.5030301@telecomitalia.it> Peter Pan wrote: >> OTOH, I hope that the "client protocol" would not need any NAT traversal >> mechanisms. Since its operations have the natted node -- the client -- >> always as the source and never as the destination, I'm quite confident >> it won't. That's why I think that once a client is able to query the >> overlay, it doesn't require any other mechanism for discovering STUN >> servers. >> > > The assumption "once a client is able to query the overlay" is an egg. > > The optimum "it doesn't require any other mechanism for discovering STUN > servers" is its chicken. > > They seems in a fantasyland. Do they? They would be chicken and egg if they were mutually dependent, but do you really think they are? As long as "client protocol" (draft-willis-p2psip-concepts) queries can be done in an HTTP-like fashion, i.e. TCP or UDP connections initiated by natted clients and addressed to reachable peers, they don't need any NAT traversal support to succeed. Or are you aware of any NAT scenario where you need STUN for effectively using HTTP? Enrico From huang-ming.pan at comcast.net Thu Jul 6 12:15:38 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 09:15:38 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> Message-ID: <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> > > By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, > > which may fail in usual cases. > > Why would you ever try to contact a STUN server behind a NAT (at least > from the public Internet)? > > If the STUN server is on the public Internet and an ordinary peer is > behind a NAT, TCP will not fail (firewalls on the other hand...). Would you sponsor the public STUN servers? :) I thought we're all serious about true serverlessness, at least with the best efforts. > > Greg > PS. Can you please not abbreviate STUN server as VSS. > It doesn't aid clarity. My apology. I thought whoever recognized the term "VSS" might have the common sense of the volatility of STUN servers for P2PSIP. From huang-ming.pan at comcast.net Thu Jul 6 12:27:30 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 09:27:30 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> <44AD35F6.5030301@telecomitalia.it> Message-ID: <00cb01c6a119$143c0550$030aa8c0@comcast.net> Peter ----- Original Message ----- From: "Enrico Marocco" To: "Peter Pan" Cc: "Greg Daley" ; Sent: Thursday, July 06, 2006 9:10 AM Subject: Re: [p2p-sip] Fw: STUN (rfc3489) > Peter Pan wrote: > >> OTOH, I hope that the "client protocol" would not need any NAT traversal > >> mechanisms. Since its operations have the natted node -- the client -- > >> always as the source and never as the destination, I'm quite confident > >> it won't. That's why I think that once a client is able to query the > >> overlay, it doesn't require any other mechanism for discovering STUN > >> servers. > >> > > > > The assumption "once a client is able to query the overlay" is an egg. > > > > The optimum "it doesn't require any other mechanism for discovering STUN > > servers" is its chicken. > > > > They seems in a fantasyland. > > Do they? They would be chicken and egg if they were mutually dependent, > but do you really think they are? > > As long as "client protocol" (draft-willis-p2psip-concepts) queries can > be done in an HTTP-like fashion, i.e. TCP or UDP connections initiated > by natted clients and addressed to reachable peers, they don't need any > NAT traversal support to succeed. Or are you aware of any NAT scenario > where you need STUN for effectively using HTTP? > > Enrico > Yes, I'm just confused, because sometimes you said STUN is required sometimes not. Please shed more light to me about: * how to define the "reachable peers"? (without have them contact any STUN server) * which entity in a P2PSIP network is in charge of defining "reachable peers"? (I know it is you in P2PSIP ML :) Peter From saikat at cs.cornell.edu Thu Jul 6 12:44:13 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Thu, 06 Jul 2006 17:44:13 +0100 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> Message-ID: <1152204253.7931.185.camel@localhost.localdomain> On Thu, 2006-07-06 at 09:15 -0700, Peter Pan wrote: > > > By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, > > > which may fail in usual cases. > > > > Why would you ever try to contact a STUN server behind a NAT (at least > > from the public Internet)? You can run a STUN server behind a NAT with a static mapping, much like you would an HTTP server behind a NAT today. > > If the STUN server is on the public Internet and an ordinary peer is > > behind a NAT, TCP will not fail (firewalls on the other hand...). > > Would you sponsor the public STUN servers? :) I thought we're all serious > about true serverlessness, at least with the best efforts. Consider 'reachability' a resource much like you would bandwidth or processing power. P2P networks need to accommodate peers with heterogeneous resources -- offload expensive computation to desktops rather than cellphones, not require modem users to upload as much as you would a university/internet-2 host etc. In the same vein, I don't see anything inherently non-serverless about public nodes providing STUN service. 2c -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/5b0f536e/attachment.bin From huang-ming.pan at comcast.net Thu Jul 6 13:02:28 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 10:02:28 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <1152204253.7931.185.camel@localhost.localdomain> Message-ID: <00f401c6a11d$f6cdbe00$030aa8c0@comcast.net> Hi, Saikat. You don't need to encapsulate your email to reach me :-) But in no way you can reach me at any (mapped) static address, STUN or HTTP, behind my NAT, which is very friendly-made by Netgear. I never disable anything of it but just pretend as naive and happy as ordinary users. Peter ----- Original Message ----- From: "Saikat Guha" To: "Peter Pan" Cc: "Greg Daley" ; Sent: Thursday, July 06, 2006 9:44 AM Subject: Re: [p2p-sip] Fw: STUN (rfc3489) On Thu, 2006-07-06 at 09:15 -0700, Peter Pan wrote: > > > By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, > > > which may fail in usual cases. > > > > Why would you ever try to contact a STUN server behind a NAT (at least > > from the public Internet)? You can run a STUN server behind a NAT with a static mapping, much like you would an HTTP server behind a NAT today. > > If the STUN server is on the public Internet and an ordinary peer is > > behind a NAT, TCP will not fail (firewalls on the other hand...). > > Would you sponsor the public STUN servers? :) I thought we're all serious > about true serverlessness, at least with the best efforts. Consider 'reachability' a resource much like you would bandwidth or processing power. P2P networks need to accommodate peers with heterogeneous resources -- offload expensive computation to desktops rather than cellphones, not require modem users to upload as much as you would a university/internet-2 host etc. In the same vein, I don't see anything inherently non-serverless about public nodes providing STUN service. 2c -- Saikat From gregd at research.panasonic.com Thu Jul 6 13:11:09 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 06 Jul 2006 13:11:09 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> Message-ID: <44AD442D.8090205@research.panasonic.com> Hi Peter, >> If the STUN server is on the public Internet and an ordinary peer is >> behind a NAT, TCP will not fail (firewalls on the other hand...). > > Would you sponsor the public STUN servers? :) I thought we're all serious > about true serverlessness, at least with the best efforts. I'm not talking about infrastructure, the publically addressed peers are likely to be providing the STUN service: Volatile STUN Servers, in your parlance. Your question was about NAT traversal to stun servers on private nets which doesn't make sense. Greg From huang-ming.pan at comcast.net Thu Jul 6 13:12:50 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 10:12:50 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com><8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com><00b101c69f75$563a5010$0300a8c0@china.huawei.com><20060704142829.GA1723@login.ecs.soton.ac.uk><002c01c69f95$0c267bf0$030aa8c0@comcast.net><44ABD8E7.3050904@research.panasonic.com><44ABE7D0.4080304@telecomitalia.it><004d01c6a051$43910350$030aa8c0@comcast.net><44ACD7D4.3010306@telecomitalia.it><00a301c6a110$43fcfdc0$030aa8c0@comcast.net><44AD35F6.5030301@telecomitalia.it> <00cb01c6a119$143c0550$030aa8c0@comcast.net> Message-ID: <00f701c6a11f$695b3140$030aa8c0@comcast.net> > > Peter Pan wrote: > > >> OTOH, I hope that the "client protocol" would not need any NAT > traversal > > >> mechanisms. Since its operations have the natted node -- the client -- > > >> always as the source and never as the destination, I'm quite confident > > >> it won't. That's why I think that once a client is able to query the > > >> overlay, it doesn't require any other mechanism for discovering STUN > > >> servers. > > >> > > > > > > The assumption "once a client is able to query the overlay" is an egg. > > > > > > The optimum "it doesn't require any other mechanism for discovering STUN > > > servers" is its chicken. > > > > > > They seems in a fantasyland. > > > > Do they? They would be chicken and egg if they were mutually dependent, > > but do you really think they are? > > > > As long as "client protocol" (draft-willis-p2psip-concepts) queries can > > be done in an HTTP-like fashion, i.e. TCP or UDP connections initiated > > by natted clients and addressed to reachable peers, they don't need any > > NAT traversal support to succeed. Or are you aware of any NAT scenario > > where you need STUN for effectively using HTTP? > > > > Enrico > > > Yes, I'm just confused, because sometimes you said STUN is required > sometimes not. > > Please shed more light to me about: > > * how to define the "reachable peers"? (without have them contact any STUN > server) > * which entity in a P2PSIP network is in charge of defining "reachable > peers"? (I know it is you in P2PSIP ML :) > > Peter > My questions can be stupid and confusing. Let's put a scenario in *reversed* order: <= via ICE a NAT-restricted node is offered with public addresses of some "reachable peers" to be as its Relay candicates <= the "reachable peers" learn their mapped addresses by some mechanism or just by STUN (though it is said as not needed sometimes) How can these reachable peers know whether they are *really reachable* from nodes other than the one(s) they've queried for mapped address? Who confirms these reachable peers of their reachability from the other nodes? Thanks for the patience of you and all. Peter From enrico.marocco at telecomitalia.it Thu Jul 6 13:14:42 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 06 Jul 2006 19:14:42 +0200 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00cb01c6a119$143c0550$030aa8c0@comcast.net> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> <44AD35F6.5030301@telecomitalia.it> <00cb01c6a119$143c0550$030aa8c0@comcast.net> Message-ID: <44AD4502.8000209@telecomitalia.it> Peter Pan wrote: >> As long as "client protocol" (draft-willis-p2psip-concepts) queries can >> be done in an HTTP-like fashion, i.e. TCP or UDP connections initiated >> by natted clients and addressed to reachable peers, they don't need any >> NAT traversal support to succeed. Or are you aware of any NAT scenario >> where you need STUN for effectively using HTTP? >> >> Enrico >> > Yes, I'm just confused, because sometimes you said STUN is required > sometimes not. It is not so complicated. Natted nodes require STUN for everything but locating (through DNS, zeroconf, well-known nodes...) and quering (through HTTP-like transactions) peers. And since nodes can perform queries, they can also obtain addresses of STUN servers. Enrico From gregd at research.panasonic.com Thu Jul 6 13:13:28 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 06 Jul 2006 13:13:28 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <1152204253.7931.185.camel@localhost.localdomain> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <1152204253.7931.185.camel@localhost.localdomain> Message-ID: <44AD44B8.5060207@research.panasonic.com> Hi Saikat, Saikat Guha wrote: > On Thu, 2006-07-06 at 09:15 -0700, Peter Pan wrote: >>>> By TLS connection to VSS behind NAT, you mean NAT penetration with TCP, >>>> which may fail in usual cases. >>> Why would you ever try to contact a STUN server behind a NAT (at least >>> from the public Internet)? > > You can run a STUN server behind a NAT with a static mapping, much like > you would an HTTP server behind a NAT today. Sure you can, but what is the purpose? >>> If the STUN server is on the public Internet and an ordinary peer is >>> behind a NAT, TCP will not fail (firewalls on the other hand...). >> Would you sponsor the public STUN servers? :) I thought we're all serious >> about true serverlessness, at least with the best efforts. > > Consider 'reachability' a resource much like you would bandwidth or > processing power. > > P2P networks need to accommodate peers with heterogeneous resources -- > offload expensive computation to desktops rather than cellphones, not > require modem users to upload as much as you would a > university/internet-2 host etc. In the same vein, I don't see anything > inherently non-serverless about public nodes providing STUN service. Agreed. Peers may provide limited service in support of others, so long as they don't experience hardship. Greg From huang-ming.pan at comcast.net Thu Jul 6 13:26:31 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 10:26:31 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> Message-ID: <00fd01c6a121$52dbff60$030aa8c0@comcast.net> > >> If the STUN server is on the public Internet and an ordinary peer is > >> behind a NAT, TCP will not fail (firewalls on the other hand...). > > > > Would you sponsor the public STUN servers? :) I thought we're all serious > > about true serverlessness, at least with the best efforts. > > I'm not talking about infrastructure, the publically addressed peers > are likely to be providing the STUN service: Volatile STUN Servers, > in your parlance. > > Your question was about NAT traversal to stun servers on private nets > which doesn't make sense. > > Greg > > Hi, Greg. When a node behind NAT can become your SN, and possibly also become your voicemail storage server or even class 5 switch, why does the tinier effort make no sense to equip the SN with STUN server capability? I don't think all the IPs in my Skype cache are of public-addressed hosts. Of course, it is proprietary of original sin. Peter From huang-ming.pan at comcast.net Thu Jul 6 13:32:12 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 6 Jul 2006 10:32:12 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> <20060704142829.GA1723@login.ecs.soton.ac.uk> <002c01c69f95$0c267bf0$030aa8c0@comcast.net> <44ABD8E7.3050904@research.panasonic.com> <44ABE7D0.4080304@telecomitalia.it> <004d01c6a051$43910350$030aa8c0@comcast.net> <44ACD7D4.3010306@telecomitalia.it> <00a301c6a110$43fcfdc0$030aa8c0@comcast.net> <44AD35F6.5030301@telecomitalia.it> <00cb01c6a119$143c0550$030aa8c0@comcast.net> <44AD4502.8000209@telecomitalia.it> Message-ID: <011401c6a122$1db94940$030aa8c0@comcast.net> > >> > > Yes, I'm just confused, because sometimes you said STUN is required > > sometimes not. > > It is not so complicated. Natted nodes require STUN for everything but > locating (through DNS, zeroconf, well-known nodes...) and quering > (through HTTP-like transactions) peers. And since nodes can perform > queries, they can also obtain addresses of STUN servers. > > Enrico Hi, Enrico. Where nodes can query still seems oracle to me. But forget about it. I'm kinda stupid and stubborn. Peter From gregd at research.panasonic.com Thu Jul 6 15:38:48 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Thu, 06 Jul 2006 15:38:48 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00fd01c6a121$52dbff60$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> Message-ID: <44AD66C8.3080707@research.panasonic.com> > Hi, Greg. > > When a node behind NAT can become your SN, and possibly also become your > voicemail storage server or even class 5 switch, why does the tinier effort > make no sense to equip the SN with STUN server capability? None of those sound like a good idea to me. > I don't think all the IPs in my Skype cache are of public-addressed hosts. > Of course, it is proprietary of original sin. The allusion surpasses me, but yes, they are all publically addressed. Greg From huang-ming.pan at comcast.net Fri Jul 7 12:18:40 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 7 Jul 2006 09:18:40 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com> Message-ID: <000b01c6a1e1$02934fc0$030aa8c0@comcast.net> > > When a node behind NAT can become your SN, and possibly also become your > > voicemail storage server or even class 5 switch, why does the tinier effort > > make no sense to equip the SN with STUN server capability? > > None of those sound like a good idea to me. Thanks. Your trash is my treasure :) > > > I don't think all the IPs in my Skype cache are of public-addressed hosts. > > Of course, it is proprietary of original sin. > > The allusion surpasses me, > but yes, they are all publically addressed. > What I observed seems no. Except those with port 33033, most of them are NAT-mapped addresses of SNs. Niklas Zennstrom said that Skype has <10 servers worldwide (likely for aaa). Peter From saikat at cs.cornell.edu Fri Jul 7 12:40:39 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Fri, 07 Jul 2006 17:40:39 +0100 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <44AD66C8.3080707@research.panasonic.com> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com> Message-ID: <1152290439.7931.341.camel@localhost.localdomain> On Thu, 2006-07-06 at 15:38 -0400, Greg Daley wrote: > > When a node behind NAT can become your SN, and possibly also become your > > voicemail storage server or even class 5 switch, why does the tinier effort > > make no sense to equip the SN with STUN server capability? > > None of those sound like a good idea to me. Actually, when it comes to Skype, all Skype SN's serve as STUN servers. In fact, all Skype nodes with a public addresses (SN or not) serve as STUN servers. See [1]. Skype nodes uses their local address as part of the key for encrypting signaling traffic. Any public node (SN or otherwise) receiving such an encrypted packet from a NAT'ed Skype node sees gibberish (since the apparent source IP/Port isn't the same as the source's local IP/port). Upon receiving such gibberish, it responds with the source's apparent IP/port == STUN address. The source thus learns it's external address (from any public peer it contacts), and re-sends the packet encrypted with its external address. [2] [1] S. Guha, N. Daswani and R. Jain. "An Experimental Study of the Skype Peer-to-Peer VoIP System," In Proceedings of The 5th International Workshop on Peer-to-Peer Systems (IPTPS '06), Santa Barbara, CA, February 2006. [2] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060707/d912b55f/attachment.bin From gregd at research.panasonic.com Fri Jul 7 18:45:09 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 07 Jul 2006 18:45:09 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <1152290439.7931.341.camel@localhost.localdomain> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com> <1152290439.7931.341.camel@localhost.localdomain> Message-ID: <44AEE3F5.5000504@research.panasonic.com> Hi Saikat, Saikat Guha wrote: > On Thu, 2006-07-06 at 15:38 -0400, Greg Daley wrote: >>> When a node behind NAT can become your SN, and possibly also become your >>> voicemail storage server or even class 5 switch, why does the tinier effort >>> make no sense to equip the SN with STUN server capability? >> None of those sound like a good idea to me. > > Actually, when it comes to Skype, all Skype SN's serve as STUN servers. > > In fact, all Skype nodes with a public addresses (SN or not) serve as > STUN servers. See [1]. > > Skype nodes uses their local address as part of the key for encrypting > signaling traffic. Any public node (SN or otherwise) receiving such an > encrypted packet from a NAT'ed Skype node sees gibberish (since the > apparent source IP/Port isn't the same as the source's local IP/port). > Upon receiving such gibberish, it responds with the source's apparent > IP/port == STUN address. The source thus learns it's external address > (from any public peer it contacts), and re-sends the packet encrypted > with its external address. [2] Peter's original assertion was that the SP (SN) or STUN server is behind a NAT. I was responding to that idea particularly. The essential point with the technology in STUN (+ STUN Relay) and in Skype is that a publicly addressed node acts as a helper. Greg From huang-ming.pan at comcast.net Fri Jul 7 20:01:24 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 7 Jul 2006 17:01:24 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com><1152290439.7931.341.camel@localhost.localdomain> <44AEE3F5.5000504@research.panasonic.com> Message-ID: <009101c6a221$a797c600$030aa8c0@comcast.net> > > On Thu, 2006-07-06 at 15:38 -0400, Greg Daley wrote: > >>> When a node behind NAT can become your SN, and possibly also become your > >>> voicemail storage server or even class 5 switch, why does the tinier effort > >>> make no sense to equip the SN with STUN server capability? > >> None of those sound like a good idea to me. > > > > Actually, when it comes to Skype, all Skype SN's serve as STUN servers. > > > > In fact, all Skype nodes with a public addresses (SN or not) serve as > > STUN servers. See [1]. > > > > Skype nodes uses their local address as part of the key for encrypting > > signaling traffic. Any public node (SN or otherwise) receiving such an > > encrypted packet from a NAT'ed Skype node sees gibberish (since the > > apparent source IP/Port isn't the same as the source's local IP/port). > > Upon receiving such gibberish, it responds with the source's apparent > > IP/port == STUN address. The source thus learns it's external address > > (from any public peer it contacts), and re-sends the packet encrypted > > with its external address. [2] > > Peter's original assertion was that the SP (SN) or STUN server > is behind a NAT. I was responding to that idea particularly. > The essential point with the technology in STUN (+ STUN Relay) > and in Skype is that a publicly addressed node acts as a helper. > Hi Greg, My assertion, if any, is that a SN/STUN server *CAN BE* behind a NAT. It might sound a mission impossible to you. Never mind. Alongside iron steel sometimes feels Orz :D I wish you abundance of publicly addressed helpers for your billion-users network as well as a wonderful weekend. Peter From gregd at research.panasonic.com Fri Jul 7 23:59:21 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 07 Jul 2006 23:59:21 -0400 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <009101c6a221$a797c600$030aa8c0@comcast.net> References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com><1152290439.7931.341.camel@localhost.localdomain> <44AEE3F5.5000504@research.panasonic.com> <009101c6a221$a797c600$030aa8c0@comcast.net> Message-ID: <44AF2D99.5080603@research.panasonic.com> > My assertion, if any, is that a SN/STUN server *CAN BE* behind a NAT. It > might sound a mission impossible to you. Never mind. Alongside iron steel > sometimes feels Orz :D I'm not saying that it can't be. I'm saying that it's not a resonable goal, with the protocols available to us today. We don't have enough time or resources to fix both the NAT traversal issue with non-publically addressed servers, and create a peer-to-peer SIP system. Let's focus on what's achievable with the resources available in a reasonable amount of time. If someone wants to do research on that, I'd be happy to see it. Let's not go off in P2PSIP now, and contemplate all these peripheral issues in depth. It's not going to help achieve a workable protocol. Greg From huang-ming.pan at comcast.net Sat Jul 8 02:46:44 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 7 Jul 2006 23:46:44 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) References: <003301c6a04d$4c70baa0$030aa8c0@comcast.net> <44AC1A3D.2050707@research.panasonic.com> <010601c6a0c8$53baeb20$030aa8c0@comcast.net> <44AD3164.1010402@research.panasonic.com> <00bd01c6a117$6bc80c30$030aa8c0@comcast.net> <44AD442D.8090205@research.panasonic.com> <00fd01c6a121$52dbff60$030aa8c0@comcast.net> <44AD66C8.3080707@research.panasonic.com><1152290439.7931.341.camel@localhost.localdomain> <44AEE3F5.5000504@research.panasonic.com> <009101c6a221$a797c600$030aa8c0@comcast.net> <44AF2D99.5080603@research.panasonic.com> Message-ID: <017501c6a25a$47268160$030aa8c0@comcast.net> > > > My assertion, if any, is that a SN/STUN server *CAN BE* behind a NAT. It > > might sound a mission impossible to you. Never mind... > > I'm not saying that it can't be. > > I'm saying that it's not a resonable goal, with the protocols > available to us today. > > We don't have enough time or resources to fix both the NAT > traversal issue with non-publically addressed servers, and > create a peer-to-peer SIP system. > > Let's focus on what's achievable with the resources available > in a reasonable amount of time. > > If someone wants to do research on that, I'd be happy to see > it. > > Let's not go off in P2PSIP now, and contemplate all these > peripheral issues in depth. > > It's not going to help achieve a workable protocol. > > Greg Overtrumped by the constraints, I cannot but agree with your reasonable compromise. Not knowing the constraints until now, I've been expecting that any "workable" P2PSIP protocol should go as far as imagination could reach. Though I cannot figure out the reasons of your squeeze and hurry, I apology for delay and interference from my naive expectation. Peter P.S. In the future when time or resource is no more a constraint, will P2PSIP approach true serverlessness with better efforts ? I can wait la :-) From karstbj at yahoo.com Sun Jul 9 01:24:40 2006 From: karstbj at yahoo.com (Karst Bjorgson) Date: Sat, 8 Jul 2006 22:24:40 -0700 (PDT) Subject: [p2p-sip] Layered traversal (was: STUN (rfc3489)) In-Reply-To: <017501c6a25a$47268160$030aa8c0@comcast.net> Message-ID: <20060709052440.25165.qmail@web53009.mail.yahoo.com> As much as I like STUN and ICE, I don't look with pleasure at the idea of building NAT traversal inside a DHT, and inside session signalling, and inside every media stream... I believe we will be much better off with a layered solution: +---------------+ | Media stream | +---------------+ | SIP | +---------------+ | DHT | +---------------+ | NAT traversal | +---------------+ At the bottom layer, something like Teredo could deal with NAT traversal, making the whole architecture much simpler. -- Karst __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From RADHIKA.R.ROY at saic.com Sun Jul 9 17:47:05 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Sun, 9 Jul 2006 17:47:05 -0400 Subject: [p2p-sip] Layered traversal (was: STUN (rfc3489)) Message-ID: <62D92A9A02BCC845B202323D49A48426209D86@0591-ITS-EXMP02.us.saic.com> Karst: In VoIP, Media is followed after signaling is completed. The signaling may consist of SIP/SDP, DHT, and NAT/FW Crossing. Once signaling allows to get the appropriate addresses for media transfer, SDP uses those addresses for sending the media. The point is that media layer will go at the bottom. Now the question comes whether we should do a trade-off analysis: NAT/FW transversal embedded in DHT vs. DHT and NAT/FW traversal as two independent layers. There is one similarity for both DHT and NAT/FW traversal: Discovery/Resolving of addresses. However, the punching of holes in FW/NATs knowing the different NAT/FW types where hosts are located are definitely a painful job. However, the first thing that we should know before the trade-off analysis is this: What it take to cross the NAT/FWs in P2P-SIP. With some extensions/modifications in STUN/TURN/ICE, is it enough in P2P-SIP? If so, what should we do in in STUN/TURN/ICE including security? Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Karst Bjorgson Sent: Sun 7/9/2006 1:24 AM To: P2P-SIP Subject: [p2p-sip] Layered traversal (was: STUN (rfc3489)) As much as I like STUN and ICE, I don't look with pleasure at the idea of building NAT traversal inside a DHT, and inside session signalling, and inside every media stream... I believe we will be much better off with a layered solution: +---------------+ | Media stream | +---------------+ | SIP | +---------------+ | DHT | +---------------+ | NAT traversal | +---------------+ At the bottom layer, something like Teredo could deal with NAT traversal, making the whole architecture much simpler. -- Karst From Gonzalo.Camarillo at ericsson.com Mon Jul 10 17:51:59 2006 From: Gonzalo.Camarillo at ericsson.com (Gonzalo Camarillo) Date: Tue, 11 Jul 2006 00:51:59 +0300 Subject: [p2p-sip] [Fwd: P2P SIP Ad-hoc on Friday at 12:30 at Room 519A] Message-ID: <44B2CBFF.5070104@ericsson.com> FYI. -------- Original Message -------- Subject: P2P SIP Ad-hoc on Friday at 12:30 at Room 519A Date: Tue, 11 Jul 2006 00:50:37 +0300 From: Gonzalo Camarillo To: sipping CC: Mary Barnes Folks, the ad-hoc meeting on SIP peer-to-peer will take place on Friday, at 12:30, at Room 519A. The room is reserved until 15:00. Cheers, Gonzalo From eunsoo at research.panasonic.com Mon Jul 10 17:54:48 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 10 Jul 2006 17:54:48 -0400 Subject: [p2p-sip] [Fwd: [Sipping] P2P SIP Ad-hoc on Friday at 12:30 at Room 519A] Message-ID: <44B2CCA8.2080805@research.panasonic.com> fyi. -------------- next part -------------- An embedded message was scrubbed... From: Gonzalo Camarillo Subject: [Sipping] P2P SIP Ad-hoc on Friday at 12:30 at Room 519A Date: Tue, 11 Jul 2006 00:50:37 +0300 Size: 3764 Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060710/6f3c61e8/30atRoom519A-0001.mht From tutschku at informatik.uni-wuerzburg.de Tue Jul 11 04:37:07 2006 From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku) Date: Tue, 11 Jul 2006 10:37:07 +0200 Subject: [p2p-sip] First CfP: MobileP2P'07 Message-ID: <007801c6a4c5$31d17140$93b86d86@Musa> (Please apologize for multiple copies) --------------------------------------------------------------------- First Call-for-Paper 4th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'07) http://www-info3.informatik.uni-wuerzburg.de/mp2p2007 White Plains, NY, USA, March 26/30, 2007 In conjunction with the 4th IEEE International Conference on Pervasive Computing and Communications (PerCom?07) http://www.percom.org/ ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile users, extend the arena of P2P computing to encompass mobile devices and wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, resource constraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P computing. Based on the success of its three predecessors, MP2P?07 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile P2P computing. It will address the challenges, technologies, and architectures leading to real-world solutions that provide users with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P?07 is the development of protocols, systems and architectures of mobile P2P architectures and the evaluation of their performance. Topics of particular interest include, but are not limited to: - Architecture and platforms for mobile P2P computing - Measurement studies on mobile P2P systems - Performance of mobile P2P services - Resource and service discovery in mobile P2P computing - Resource exchange mechanisms in mobile P2P application - Multicast Protocols in mobile networks - Energy saving P2P protocols for mobile devices - Mobile P2P in wirelesss sensor networks - Security in mobile P2P networks - Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) / 802.11 (WLAN) - Mobile P2P & operator/provider requirements - Reliability and carrier-gradeness of mobile P2P services - Mobile P2P SIP - Mobile P2P & fixed P2P system interworking - Issues of combining P2P services with mobility (mobile IP / MANET) - Peer access and control in mobile environment - Location dependent mobile P2P services - Data exchange and rendering techniques for mobile devices - Secure communication protocols for mobile P2P computing - Mobile P2P messaging systems - Peer-to-peer broadband wireless communications - Applications of mobile P2P - Nature-inspired algorithms for mobile P2P computing - Theoretical issues on mobile information diffusion - Mobile P2P video games - Stimulating cooperation in mobile computing Paper Submission: ----------------- Papers must be written in English and should not exceed 5 pages in IEEE proceedings style. All submissions must describe original research, not published nor currently under review for another conference or journal. Authors MUST submit their papers through the PERDAS web site (http://www.percom.org/perdas) in three steps: * Creation of a personal account on PERDAS (if the author does not already have one) * Registration of the paper (requiring a short abstract of up to 150 words) * Upload of the paper. Only in pdf format Submission implies the willingness of at least one of the authors to register and present the paper. There is only one registration for the whole PerCom "convention", all workshops included. The only exception from the full-registration rule is: an author can register for her/his paper with a student registration if i) (s)he is a student AND ii) on of her/his co-authors has a full registration with PerCom. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must be presented at the workshop and will appear in a combined PerCom 2007 workshop proceedings published by IEEE Computer Society Press. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Important Dates: ---------------- Papers due: 5pm EST, September 29, 2006 Notification of acceptance November 25, 2006 Camera-ready papers due to IEEE December 22, 2006 Organizing Committee, Program Co-chairs: ---------------------------------------- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany. Acting Chair of Self-Organization and Distributed Systems, TU Chemnitz, Germany. John Buford, Panasonic Princeton Laboratory, USA. Li Li, Communications Research Center Canada, Canada. Steering Board: --------------- - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University. - Cecilia Mascolo, Department of Computer Science, University College London. - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill. Publicity Chair: ---------------- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany Acting Chair of Self-Organization and Distributed Systems, TU Chemnitz, Germany. --- Dr. Kurt Tutschku, Assistant Professor University of Wuerzburg Department of Distributed Systems Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641 FAX: +49-931-8886632 mailto:tutschku at informatik.uni-wuerzburg.de or mailto:kurttutschku at hotmail.com http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku TU Chemnitz Acting Chair of Self-Organization and Distributed Systems Faculty of Computer Science Strasse der Nationen 62 09107 Chemnitz Germany Tel.: +49-371-531-35514 FAX: +49-371-531-25539 mailto:tutschku at informatik.tu-chemnitz.de From srisuresh at yahoo.com Wed Jul 12 09:53:01 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Wed, 12 Jul 2006 06:53:01 -0700 (PDT) Subject: [p2p-sip] Request for comments on draft-srisuresh-behave-p2p-state-03.txt Message-ID: <20060712135301.36712.qmail@web33311.mail.mud.yahoo.com> Folks, The authors of draft-srisuresh-behave-p2p-state-03.txt wish to submit the draft as independent submission to the RFC editor and request its publication as an informational RFC. Please review and let us know your comments by no later than 07/26/06. I.e., within 2 weeks from now. Thanks. The draft is available in the archives as follows. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-03.txt regards, suresh From philip_matthews at magma.ca Wed Jul 12 11:20:35 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 12 Jul 2006 11:20:35 -0400 Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060712135301.36712.qmail@web33311.mail.mud.yahoo.com> References: <20060712135301.36712.qmail@web33311.mail.mud.yahoo.com> Message-ID: Is this a request for people on the BEHAVE and P2P-SIP mailing lists to review the draft and send you comments? - Philip On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > Folks, > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > submit the draft > as independent submission to the RFC editor and request its > publication as an > informational RFC. Please review and let us know your comments by > no later than > 07/26/06. I.e., within 2 weeks from now. Thanks. > > The draft is available in the archives as follows. > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > state-03.txt > > regards, > suresh > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave at list.sipfoundry.org > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh at yahoo.com Wed Jul 12 12:34:41 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Wed, 12 Jul 2006 09:34:41 -0700 (PDT) Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: Message-ID: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> Right. Thanks. regards, suresh --- Philip Matthews wrote: > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > to review the draft and send you comments? > > - Philip > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > Folks, > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > submit the draft > > as independent submission to the RFC editor and request its > > publication as an > > informational RFC. Please review and let us know your comments by > > no later than > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > The draft is available in the archives as follows. > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > state-03.txt > > > > regards, > > suresh > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave at list.sipfoundry.org > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dwing at cisco.com Wed Jul 12 14:17:42 2006 From: dwing at cisco.com (Dan Wing) Date: Wed, 12 Jul 2006 14:17:42 -0400 Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> Message-ID: <017601c6a5df$7abb8ec0$2872150a@amer.cisco.com> During the PROTO (*) writeup, we decided that review of this document by BEHAVE and P2P-SIP would be useful, as both groups have subject matter experts in the area covered by this draft. The abstract of draft-srisuresh-behave-p2p-state-03.txt is: This memo documents the various methods known to be in use by the peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt -d > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > Sent: Wednesday, July 12, 2006 12:35 PM > To: Philip Matthews > Cc: ietf-behave at list.sipfoundry.org; p2p-sip at cs.columbia.edu; > dwing at cisco.com; Dan Kegel > Subject: Re: [Ietf-behave] Request for comments on > draft-srisuresh-behave-p2p-state-03.txt > > Right. Thanks. > > regards, > suresh > > --- Philip Matthews wrote: > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > to review the draft and send you comments? > > > > - Philip > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > Folks, > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > submit the draft > > > as independent submission to the RFC editor and request its > > > publication as an > > > informational RFC. Please review and let us know your > comments by > > > no later than > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > The draft is available in the archives as follows. > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > state-03.txt > > > > > > regards, > > > suresh > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave at list.sipfoundry.org > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From enrico.marocco at telecomitalia.it Thu Jul 13 16:07:24 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 13 Jul 2006 22:07:24 +0200 Subject: [p2p-sip] SIP security for P2PSIP Message-ID: <44B6A7FC.8000903@telecomitalia.it> Folks, the SIP WG has recently been focusing on security issues which are particularily critical in P2PSIP environments. Opposite to SIPS, which provides hop-by-hop security and is hardly applicable in P2P networks where any peer could be malicious, a new model (SIPSEC) has been discussed for providing end-to-end security. I'd suggest that people interested in P2PSIP also give a look at the initial SIPSEC draft (draft-gurbani-sip-sipsec-00) as well as draft-audet-sip-sips-guidelines-02 and draft-srivastava-sip-e2e-ciphersuites-00. Links: http://ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt http://ietf.org/internet-drafts/draft-audet-sip-sips-guidelines-02.txt http://ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuites-00.txt Enrico From samirsr at nortel.com Fri Jul 14 02:09:43 2006 From: samirsr at nortel.com (Samir Srivastava) Date: Fri, 14 Jul 2006 01:09:43 -0500 Subject: [p2p-sip] SIP security for P2PSIP In-Reply-To: <44B6A7FC.8000903@telecomitalia.it> Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60D3BC2BF@zrc2hxm2.corp.nortel.com> Hi, 1) For the cipher-suites draft, there are slides also available http://www3.ietf.org/proceedings/06jul/slides/sip-17.pdf Which captures email discussions done after the draft submission. 2) For SIPS/SIP guidelines, slides are at http://www3.ietf.org/proceedings/06jul/slides/sip-14.pdf Thx Samir > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Enrico Marocco > Sent: Thursday, July 13, 2006 4:07 PM > To: P2P-SIP > Subject: [p2p-sip] SIP security for P2PSIP > > Folks, > > the SIP WG has recently been focusing on security issues > which are particularily critical in P2PSIP environments. > Opposite to SIPS, which provides hop-by-hop security and is > hardly applicable in P2P networks where any peer could be > malicious, a new model (SIPSEC) has been discussed for > providing end-to-end security. > > I'd suggest that people interested in P2PSIP also give a look > at the initial SIPSEC draft (draft-gurbani-sip-sipsec-00) as well as > draft-audet-sip-sips-guidelines-02 and > draft-srivastava-sip-e2e-ciphersuites-00. > > Links: > > http://ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt > http://ietf.org/internet-drafts/draft-audet-sip-sips-guidelines-02.txt > http://ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphe > rsuites-00.txt > > Enrico > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From fluffy at cisco.com Fri Jul 14 10:26:57 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Fri, 14 Jul 2006 10:26:57 -0400 Subject: [p2p-sip] Comment on willis-p2psip-concepts Message-ID: <1D655127-DB9F-49B8-944A-ADCA55ED3725@cisco.com> One little note... When doing enrollment I think you need to get a few more things... Any parameters that are required to participate in this particular instance of the overlay network. Information to help locate bootstrap nodes. From slavitch at gmail.com Fri Jul 14 13:33:47 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 14 Jul 2006 13:33:47 -0400 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... Message-ID: <1fc32c8f0607141033s638d2ec1naea5a4b285951ac6@mail.gmail.com> Folks; Given that the IETF meeting is officially over this may be the one time where an attachment sent to the list is a good idea. Regards Michael From mary.barnes at nortel.com Fri Jul 14 14:32:19 2006 From: mary.barnes at nortel.com (Mary Barnes) Date: Fri, 14 Jul 2006 13:32:19 -0500 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... In-Reply-To: <1fc32c8f0607141033s638d2ec1naea5a4b285951ac6@mail.gmail.com> Message-ID: Yes, we should have had the charts available sooner. For reference they are cached on the SIPPING WG supplementary page: http://www.softarmor.com/sipping/meets/ietf66/slides/index.html Mary -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch Sent: Friday, July 14, 2006 12:34 PM To: P2P-SIP Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... Folks; Given that the IETF meeting is officially over this may be the one time where an attachment sent to the list is a good idea. Regards Michael _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From RADHIKA.R.ROY at saic.com Fri Jul 14 14:45:52 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Fri, 14 Jul 2006 14:45:52 -0400 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hocslid es... Message-ID: <62D92A9A02BCC845B202323D49A48426209DA4@0591-ITS-EXMP02.us.saic.com> Hi, all: Mary did a super-excellent job sending this URL so promptly especially for those who did not attend the IETF meeting. Best regards to Mary and all. Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Mary Barnes Sent: Fri 7/14/2006 2:32 PM To: Michael Slavitch; P2P-SIP Subject: Re: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hocslides... Yes, we should have had the charts available sooner. For reference they are cached on the SIPPING WG supplementary page: http://www.softarmor.com/sipping/meets/ietf66/slides/index.html Mary -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu ] On Behalf Of Michael Slavitch Sent: Friday, July 14, 2006 12:34 PM To: P2P-SIP Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... Folks; Given that the IETF meeting is officially over this may be the one time where an attachment sent to the list is a good idea. Regards Michael From jani.hautakorpi at ericsson.com Mon Jul 17 07:46:09 2006 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Mon, 17 Jul 2006 14:46:09 +0300 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft Message-ID: <44BB7881.4010205@ericsson.com> Hi all, I read the Concepts and Terminology for P2PSIP draft, and I though that the draft was quite good. However, I believe that the draft could be somewhat polished. You can find my comments/findings from the following diff-file: http://users.piuha.net/jantzgu/temp/p2psip-concepts-00--diff.html Same comments are also listed here (sorted by sections): First page: - s/Byran/Bryan/ 2. Definitions: - Definition of "Overlay Network" and "P2P Network" are taken directly from wikipedia. Maybe a bit better definitions would be in order. - There's no definition for "P2PSIP" itself, and I think it would be good to include it. - How does a "P2PSIP Overlay User Agent differ from a traditional SIP UA? Is there a need to make a distinction between the two? - The "P2P Overlay Network" is a bit ambiguous, because it is not defined in this draft - s/via ,/via,/ - Is there a need to make a distinction between the "User Record" and "User Routing Record"? - It is not very clear what kind of an address this User Routing Record contains. Does it contain an IP address, SIP URI, or some other address? - The draft at its current stage talks about "Resources" and about "Users". I believe that it would be good to talk mainly about "Resources" and only mention that "User" is one form of a "Resource". What do you think? 3.2. Reference Model: - I felt that the figure didn't really represent the text in the draft too well. I tried to draw a figure which would match the text (in my opinion), see the figure in the diff-file. 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent: - s/client/client or a peer/ 3.3.5. Bootstrapping: - The existence of Clients create a requirement for bootstrapping procedure. That is, it would be good if bootstrapping procedure would be able to return a Peer from a relatively large pool of online Peers. 4.10. Peer-Adjacency Through NATs: - This could be section 4.8, because this is probably related to the section 4.7. 4.11. Peer and Client Enrollment Protocols: - There is one related question: "How to do admission control in practice?" It would be nice if my comments/findings would initiate some counter-comments/discussion in this mailing list. -- Regards, Jani Hautakorpi Ericsson Research From dean.willis at softarmor.com Tue Jul 18 20:08:04 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 18 Jul 2006 19:08:04 -0500 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <44BB7881.4010205@ericsson.com> References: <44BB7881.4010205@ericsson.com> Message-ID: <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> On Jul 17, 2006, at 6:46 AM, Jani Hautakorpi (JO/LMF) wrote: > Hi all, > > I read the Concepts and Terminology for P2PSIP draft, and I though > that > the draft was quite good. However, I believe that the draft could be > somewhat polished. > Thanks.,I agree. > You can find my comments/findings from the following diff-file: > http://users.piuha.net/jantzgu/temp/p2psip-concepts-00--diff.html > > Same comments are also listed here (sorted by sections): > First page: > - s/Byran/Bryan/ oops. > 2. Definitions: > - Definition of "Overlay Network" and "P2P Network" are taken directly > from wikipedia. Maybe a bit better definitions would be in order. > I'm game. Send text? > - There's no definition for "P2PSIP" itself, and I think it would be > good to include it. ok. > - How does a "P2PSIP Overlay User Agent differ from a traditional SIP > UA? Is there a need to make a distinction between the two? > A P2PSIP Overlay User Agent also includes a P2PSIP Overlay Peer or P2PSIP Overlay Client that might (assuming the client protocol is not plain SIP) be present in a regular SIP UA. > - The "P2P Overlay Network" is a bit ambiguous, because it is not > defined in this draft Hmm. Need to delete the word "Network" in the above. > - s/via ,/via,/ ok > - Is there a need to make a distinction between the "User Record" and > "User Routing Record"? Well, it seemed reasonable at the time. There might be USer Records that are not routing records. The text says: P2PSIP Overlay User Record: A block of data, stored in the data mechanism of the P2PSIP Overlay, that includes information relevant to a specific user. We presume that there may be multiple types of user records. Some may describe routes to a client at which the user is presumed reachable (a "user routing record", like a SIP "Contact:"). Others might store presence information. The types, usages, and formats of user records are a question for future study. So, one might envision something like a P2PSIP Overlay User Presence Record that contains presence, not routing information. > - It is not very clear what kind of an address this User Routing > Record > contains. Does it contain an IP address, SIP URI, or some other > address? We don't know yet. My presumption is that it contains a SIP route vector. I might be wrong. > - The draft at its current stage talks about "Resources" and about > "Users". I believe that it would be good to talk mainly about > "Resources" and only mention that "User" is one form of a > "Resource". > What do you think? I stared with that approach and got overruled b Eunsoo and others so I'll let them defend the choice. The "P2PSIP Overlay Resource Enrollment" defnition is probably an artifact and might could just be removed if we stay with the "all resources are users" model. > 3.2. Reference Model: > - I felt that the figure didn't really represent the text in the draft > too well. I tried to draw a figure which would match the text (in my > opinion), see the figure in the diff-file. You're probably right but my brain doesn't parse your figure. Curved- lines in ASCII art all look like naked butterfly pictures or something to me, but they don't look like lines. > 3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent: > - s/client/client or a peer/ ok > 3.3.5. Bootstrapping: > - The existence of Clients create a requirement for bootstrapping > procedure. That is, it would be good if bootstrapping procedure > would > be able to return a Peer from a relatively large pool of online > Peers. > That's a valid approach, but may not be the only possible one. > 4.10. Peer-Adjacency Through NATs: > - This could be section 4.8, because this is probably related to the > section 4.7. You mean just re-order the sections? > 4.11. Peer and Client Enrollment Protocols: > - There is one related question: "How to do admission control in > practice?" > Use RSVP? > It would be nice if my comments/findings would initiate some > counter-comments/discussion in this mailing list. Yes, it would. -- Dean From enrico.marocco at telecomitalia.it Wed Jul 19 05:26:11 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 19 Jul 2006 11:26:11 +0200 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> Message-ID: <44BDFAB3.2060906@telecomitalia.it> Dean Willis wrote: >> - The draft at its current stage talks about "Resources" and about >> "Users". I believe that it would be good to talk mainly about >> "Resources" and only mention that "User" is one form of a >> "Resource". >> What do you think? > > I stared with that approach and got overruled b Eunsoo and others so > I'll let them defend the choice. The main difference between users and resources is that the formers have unique identifiers (e.g. sip:alice at example.com), while the latters share sort of "category identifiers" (e.g. urn:service:data-relay.turn). I think that, at least at the moment, we should keep them distinct. > The "P2PSIP Overlay Resource Enrollment" defnition is probably an > artifact and might could just be removed if we stay with the "all > resources are users" model. Actually the draft defines enrollment distinct for peers and resources, not for resources and users. Perhaps such an artifact could be introduced, until we better understand the relationship between users and resources. Enrico From dean.willis at softarmor.com Wed Jul 19 14:15:20 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 19 Jul 2006 13:15:20 -0500 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <44BDFAB3.2060906@telecomitalia.it> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BDFAB3.2060906@telecomitalia.it> Message-ID: On Jul 19, 2006, at 4:26 AM, Enrico Marocco wrote: > Dean Willis wrote: >>> - The draft at its current stage talks about "Resources" and about >>> "Users". I believe that it would be good to talk mainly about >>> "Resources" and only mention that "User" is one form of a >>> "Resource". >>> What do you think? >> >> I stared with that approach and got overruled b Eunsoo and others so >> I'll let them defend the choice. > > The main difference between users and resources is that the formers > have > unique identifiers (e.g. sip:alice at example.com), while the latters > share > sort of "category identifiers" (e.g. urn:service:data-relay.turn). I > think that, at least at the moment, we should keep them distinct. > >> The "P2PSIP Overlay Resource Enrollment" defnition is probably an >> artifact and might could just be removed if we stay with the "all >> resources are users" model. > > Actually the draft defines enrollment distinct for peers and > resources, > not for resources and users. Perhaps such an artifact could be > introduced, until we better understand the relationship between users > and resources. The intent of the current draft is that resources == users. i.e. they are synonymous terms, and all have unique identifiers within the overlay. There may be a separate requirement for "classes" of resources, like "resources that are media relays" or "resources that are in Dallas". Of course, this intent is subject to debate -- it should probably become an "open issue" in the document, unless we get a stronger consensus Real Soon Now. -- Dean From eunsoo at research.panasonic.com Wed Jul 19 16:55:07 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 19 Jul 2006 16:55:07 -0400 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BDFAB3.2060906@telecomitalia.it> Message-ID: <44BE9C2B.7000102@research.panasonic.com> Dean Willis wrote: > On Jul 19, 2006, at 4:26 AM, Enrico Marocco wrote: > >> Dean Willis wrote: >>>> - The draft at its current stage talks about "Resources" and about >>>> "Users". I believe that it would be good to talk mainly about >>>> "Resources" and only mention that "User" is one form of a >>>> "Resource". >>>> What do you think? >>> I stared with that approach and got overruled b Eunsoo and others so >>> I'll let them defend the choice. >> The main difference between users and resources is that the formers >> have >> unique identifiers (e.g. sip:alice at example.com), while the latters >> share >> sort of "category identifiers" (e.g. urn:service:data-relay.turn). I >> think that, at least at the moment, we should keep them distinct. >> >>> The "P2PSIP Overlay Resource Enrollment" defnition is probably an >>> artifact and might could just be removed if we stay with the "all >>> resources are users" model. >> Actually the draft defines enrollment distinct for peers and >> resources, >> not for resources and users. Perhaps such an artifact could be >> introduced, until we better understand the relationship between users >> and resources. > > The intent of the current draft is that resources == users. i.e. they > are synonymous terms, and all have unique identifiers within the > overlay. > > There may be a separate requirement for "classes" of resources, like > "resources that are media relays" or "resources that are in Dallas". > > Of course, this intent is subject to debate -- it should probably > become an "open issue" in the document, unless we get a stronger > consensus Real Soon Now. > Below is my understanding about the terms 'resource', 'user', and 'enrollment'. 'resource' is a term used with many different meanings. Probably it has been used different in the SIP context and P2P contexnt. SIP UAs and media relays are resources in SIP context. CPU time or disk storage can be a resource in P2P context. We say a P2P network or a DHT provides resource lookup. Let say Alice looks up Bob (actually bob at example.com)'s location. The lookup request returns a record that contains Bob's location, i.e., IP address and port number. Is the location record a resource as well or just a pointer to a resource? Yes for both, I think. Or is a pointer to a resource another type of resource itself? I think it is. If Bob looks for a message from Alice that is stored in the P2P network, is the message a resource? I think it is. We can see there can be many types of resources. But some need to have SIP URIs (or AORs) but others not. For example, a location record does not have to have a SIP URI. It is useful to distinguish these two categories: those identified by SIP URIs and those not. It is useful especially when SIP URIs should be claimed only with permission (or a right to a name) from a possibly central authority. The process to get a right to a name is 'enrollment'. The draft calls those with SIP URIs 'users'. In this sense, 'resource enrollment' is too broad, I think, We should use just 'user enrollment' rather than 'resource enrollment'. For some resources like a stored message for Bob or Bob's location record do not require enrollment. Just signature by who generated the message or record should be enough. Thanks. Eunsoo From eunsoo at research.panasonic.com Wed Jul 19 17:03:27 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 19 Jul 2006 17:03:27 -0400 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... In-Reply-To: References: Message-ID: <44BE9E1F.6050802@research.panasonic.com> For those who could not attend the ad-hoc meeting, I'd like to ask for reviewing the presentation slides and in particular thinking about the questions and proposed answers in David's slides. The slides contain a proposal for key work items (the essence of the charter). The meeting minutes will be published sooner or later but to be very short, an absolute majority of the ad-hoc meeting attendees agreed to the proposed answers in all the questions. Only the question about anonymous communication did not have a proposed answer and the most of the attendees did not prefer putting it as a requirement of the first version of the protocols Thanks. Eunsoo Mary Barnes wrote: > Yes, we should have had the charts available sooner. For reference they > are cached on the SIPPING WG supplementary page: > http://www.softarmor.com/sipping/meets/ietf66/slides/index.html > > Mary > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch > Sent: Friday, July 14, 2006 12:34 PM > To: P2P-SIP > Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc > slides... > > > Folks; > > Given that the IETF meeting is officially over this may be the one > time where an attachment sent to the list is a good idea. > > Regards > > Michael > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From spencer at mcsr-labs.org Wed Jul 19 17:22:48 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 19 Jul 2006 16:22:48 -0500 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIPad-hoc slides... References: <44BE9E1F.6050802@research.panasonic.com> Message-ID: <076b01c6ab79$7c4b25d0$4f087c0a@china.huawei.com> I was scribing for this session, and agree with Eunsoo's summary, with two additions: - there was a LOT of discussion on most of the points - but then the room agreed with David's suggested resolutions in most cases. - the exception was on anonymous communication, where people seemed to be nodding in response to Dean's "should not PRECLUDE anonymous communication" suggestion - so the room seemed to be agreeing there, too. We pay the working group chairs big bucks to figure out what the working group thinks (as opposed to the meeting room), so I'll leave further discussion along this line to Mary and Gonzalo. Thanks! Spencer p.s. Mary, Dean is putting SIP raw notes on the softarmor site - if you'd like a nicer version of my raw notes for SIPPING (which include P2PSIP notes), please let me know. > For those who could not attend the ad-hoc meeting, I'd like to ask for > reviewing the presentation slides and in particular thinking about the > questions and proposed answers in David's slides. > > The slides contain a proposal for key work items (the essence of the > charter). The meeting minutes will be published sooner or later but to > be very short, an absolute majority of the ad-hoc meeting attendees > agreed to the proposed answers in all the questions. Only the question > about anonymous communication did not have a proposed answer and the > most of the attendees did not prefer putting it as a requirement of the > first version of the protocols > > Thanks. > > Eunsoo From slavitch at gmail.com Wed Jul 19 17:39:52 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 19 Jul 2006 17:39:52 -0400 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIPad-hoc slides... In-Reply-To: <076b01c6ab79$7c4b25d0$4f087c0a@china.huawei.com> References: <44BE9E1F.6050802@research.panasonic.com> <076b01c6ab79$7c4b25d0$4f087c0a@china.huawei.com> Message-ID: <1fc32c8f0607191439v29a20077v18db5646555fb793@mail.gmail.com> Thank you all for posting the slides, and I am looking forward to the follow-on discussion. From jani.hautakorpi at ericsson.com Thu Jul 20 03:57:39 2006 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Thu, 20 Jul 2006 10:57:39 +0300 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> Message-ID: <44BF3773.3040708@ericsson.com> Hi Dean, Dean Willis wrote: >> - How does a "P2PSIP Overlay User Agent differ from a traditional SIP >> UA? Is there a need to make a distinction between the two? > > A P2PSIP Overlay User Agent also includes a P2PSIP Overlay Peer or > P2PSIP Overlay Client that might (assuming the client protocol is not > plain SIP) be present in a regular SIP UA. Maybe I got this wrong, but I understood that an Overlay UA doesn't *include* an Overlay Peer. I understood it in a way that Overlay UA can be co-located in a same node with an Overlay Peer, and that Overlay UA can *use* Overlay Peer. I'm still not convinced that we need to make a distinction between an Overlay UA and a regular SIP UA. I see this in a way that the Client and Peer protocols can be non-SIP/extended-SIP/whatever protocols, but the protocol between the (Overlay) UA and Client/Peer could be plain SIP. At least at the moment I would see this approach as an easy way to connect regular UAs to P2PSIP network. What do you think? >> - Is there a need to make a distinction between the "User Record" and >> "User Routing Record"? > > Well, it seemed reasonable at the time. There might be USer Records that > are not routing records. The text says: > > ... > > So, one might envision something like a P2PSIP Overlay User Presence > Record that contains presence, not routing information. Yes, there can be different User Records, but I'm not sure whether this draft should try to define them all, or should this draft define only "P2PSIP User Record" and let some other draft enumerate all the different User Record types and their structures. Any opinions? >> 3.2. Reference Model: >> - I felt that the figure didn't really represent the text in the draft >> too well. I tried to draw a figure which would match the text (in my >> opinion), see the figure in the diff-file. > > You're probably right but my brain doesn't parse your figure. > Curved-lines in ASCII art all look like naked butterfly pictures or > something to me, but they don't look like lines. The curved-lines aren't naked butterflies, they represent an edge of a cloud instead. But if you like the figure otherwise, I can replace ~s with the character of your choice. :-) >> 3.3.5. Bootstrapping: >> - The existence of Clients create a requirement for bootstrapping >> procedure. That is, it would be good if bootstrapping procedure would >> be able to return a Peer from a relatively large pool of online Peers. > > That's a valid approach, but may not be the only possible one. Maybe, but what I meant was that maybe something like the following could be appended to section 3.3.5? Bootstrap servers should be able to return an address of a Peer to a Client from a relatively large pool of Peer addresses. This is because otherwise load distribution would be insufficient, and some Peers might get overloaded. >> 4.10. Peer-Adjacency Through NATs: >> - This could be section 4.8, because this is probably related to the >> section 4.7. > > You mean just re-order the sections? Yes (it doesn't really matter, this was just an observation). >> 4.11. Peer and Client Enrollment Protocols: >> - There is one related question: "How to do admission control in >> practice?" > > Use RSVP? :-) What I had in mind was that maybe something like "Do we need a mechanism for preventing unauthorized nodes from accessing a P2PSIP Overlay?" could be appended to section 4.11? -- Jani From enrico.marocco at telecomitalia.it Thu Jul 20 12:01:20 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 20 Jul 2006 18:01:20 +0200 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BDFAB3.2060906@telecomitalia.it> Message-ID: <44BFA8D0.4020308@telecomitalia.it> Dean Willis wrote: > The intent of the current draft is that resources == users. i.e. they > are synonymous terms, and all have unique identifiers within the overlay. > > There may be a separate requirement for "classes" of resources, like > "resources that are media relays" or "resources that are in Dallas". I don't have clear ideas about this. We could define "classes" _of_ resources, in which case we then need to have distinct policies for each class. For example, the "list" operation should be allowed for the "media relays" class, but not for the "users" one. On the other hand, we could have "classes" _as_ resources. In this case it would be important that, for example, only Alice was able to register her UAs' contacts for the resource "sip:alice at example.com" (that she had enrolled before), while anyone was able to register contacts for the resource "media relay class". Anyway, "being in Dallas" seems more an attribute than a class (even if it is always possible to define such a class); just to be clear, attribute-based search is out of scope, right? > Of course, this intent is subject to debate -- it should probably become > an "open issue" in the document, unless we get a stronger consensus Real > Soon Now. My "hum" is for "open issues" :-) Enrico From eunsoo at research.panasonic.com Thu Jul 20 14:28:17 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 20 Jul 2006 14:28:17 -0400 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <44BF3773.3040708@ericsson.com> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BF3773.3040708@ericsson.com> Message-ID: <44BFCB41.9070504@research.panasonic.com> Jani Hautakorpi (JO/LMF) wrote: > Hi Dean, > > Dean Willis wrote: >>> - How does a "P2PSIP Overlay User Agent differ from a traditional SIP >>> UA? Is there a need to make a distinction between the two? >> >> A P2PSIP Overlay User Agent also includes a P2PSIP Overlay Peer or >> P2PSIP Overlay Client that might (assuming the client protocol is not >> plain SIP) be present in a regular SIP UA. > > Maybe I got this wrong, but I understood that an Overlay UA doesn't > *include* an Overlay Peer. I understood it in a way that Overlay UA can > be co-located in a same node with an Overlay Peer, and that Overlay UA > can *use* Overlay Peer. > Below is what I understand and suggest. There is no such thing like an Overlay UA that is not co-located with a Client or a Peer. If a UA exists without being coupled (i.e. not co-located) with a Client or a Peer, it is just a plain SIP UA. If a UA is coupled (co-located) with a Client or a Peer, it is a P2PSIP Overlay UA. > I'm still not convinced that we need to make a distinction between an > Overlay UA and a regular SIP UA. I see this in a way that the Client and > Peer protocols can be non-SIP/extended-SIP/whatever protocols, but the > protocol between the (Overlay) UA and Client/Peer could be plain SIP. There is no protocol between an Overlay UA and a Client/Peer. There is no need. For an Overlay UA can/will just invoke the function calls of the API provided by the Client/Peer. It does not make a sense to define a protocol between a plain (C/S) SIP UA and a Client/Peer either. In a sense, they are in different sublayers. If we want to let a C/S UA use the service of the overlay network, the C/S UA should talk to a SIP Proxy node that is a Client or a Peer. Apparently the protocol between the C/S SIP UA and the (P2P)SIP Proxy is just SIP. At > least at the moment I would see this approach as an easy way to connect > regular UAs to P2PSIP network. What do you think? > > >>> - Is there a need to make a distinction between the "User Record" and >>> "User Routing Record"? >> >> Well, it seemed reasonable at the time. There might be USer Records >> that are not routing records. The text says: >> >> ... >> >> So, one might envision something like a P2PSIP Overlay User Presence >> Record that contains presence, not routing information. > > Yes, there can be different User Records, but I'm not sure whether this > draft should try to define them all, or should this draft define only > "P2PSIP User Record" and let some other draft enumerate all the > different User Record types and their structures. Any opinions? > I agree that this draft needs to show the concept but not list all the record types. Even in the case, isn't it OK to mention a couple of or a few record types? > >>> 3.2. Reference Model: >>> - I felt that the figure didn't really represent the text in the draft >>> too well. I tried to draw a figure which would match the text (in my >>> opinion), see the figure in the diff-file. >> >> You're probably right but my brain doesn't parse your figure. >> Curved-lines in ASCII art all look like naked butterfly pictures or >> something to me, but they don't look like lines. > > The curved-lines aren't naked butterflies, they represent an edge of a > cloud instead. But if you like the figure otherwise, I can replace ~s > with the character of your choice. :-) > Somehow I don't see ~s. Where do you see them? > >>> 3.3.5. Bootstrapping: >>> - The existence of Clients create a requirement for bootstrapping >>> procedure. That is, it would be good if bootstrapping procedure would >>> be able to return a Peer from a relatively large pool of online Peers. >> >> That's a valid approach, but may not be the only possible one. > > Maybe, but what I meant was that maybe something like the following > could be appended to section 3.3.5? > > Bootstrap servers should be able to return an address of a Peer to a > Client from a relatively large pool of Peer addresses. This is because > otherwise load distribution would be insufficient, and some Peers > might get overloaded. > It is a desirable characteristic for a bootstrap server. Do we have to talk in that level in this draft? > >>> 4.10. Peer-Adjacency Through NATs: >>> - This could be section 4.8, because this is probably related to the >>> section 4.7. >> >> You mean just re-order the sections? > > Yes (it doesn't really matter, this was just an observation). > > >>> 4.11. Peer and Client Enrollment Protocols: >>> - There is one related question: "How to do admission control in >>> practice?" >> >> Use RSVP? > > :-) What I had in mind was that maybe something like "Do we need a > mechanism for preventing unauthorized nodes from accessing a P2PSIP > Overlay?" could be appended to section 4.11? > > A good point. Thanks. Eunsoo From jani.hautakorpi at ericsson.com Fri Jul 21 07:04:57 2006 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Fri, 21 Jul 2006 14:04:57 +0300 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <44BFCB41.9070504@research.panasonic.com> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BF3773.3040708@ericsson.com> <44BFCB41.9070504@research.panasonic.com> Message-ID: <44C0B4D9.7020808@ericsson.com> Hi Eunsoo, Eunsoo Shim wrote: > Below is what I understand and suggest. > There is no such thing like an Overlay UA that is not co-located with a > Client or a Peer. Ok, I re-read the definition of an Overlay UA, and it clearly says what you just said. Maybe it's a good idea after all to define the Overlay UA. >>>> - Is there a need to make a distinction between the "User Record" and >>>> "User Routing Record"? >>> >>> ... >>> >>> So, one might envision something like a P2PSIP Overlay User Presence >>> Record that contains presence, not routing information. >> Yes, there can be different User Records, but I'm not sure whether this >> draft should try to define them all, or should this draft define only >> "P2PSIP User Record" and let some other draft enumerate all the >> different User Record types and their structures. Any opinions? >> > I agree that this draft needs to show the concept but not list all the > record types. > Even in the case, isn't it OK to mention a couple of or a few record types? Personally I think it's a bit confusing, but I don't have any strong opinions about this. >> The curved-lines aren't naked butterflies, they represent an edge of a >> cloud instead. But if you like the figure otherwise, I can replace ~s >> with the character of your choice. :-) >> > Somehow I don't see ~s. Where do you see them? They are in the 'alternative' figure in (actually, now I can see the butterfly too): http://users.piuha.net/jantzgu/temp/p2psip-concepts-00--diff.html >> Maybe, but what I meant was that maybe something like the following >> could be appended to section 3.3.5? >> >> Bootstrap servers should be able to return an address of a Peer to a >> Client from a relatively large pool of Peer addresses. This is because >> otherwise load distribution would be insufficient, and some Peers >> might get overloaded. >> > It is a desirable characteristic for a bootstrap server. > Do we have to talk in that level in this draft? I might be a good idea to mention it, because the fact the there are Peers *and* Clients create this 'requirement'. -- Jani PS: I'll be on vacation for weeks 30-33. From dean.willis at softarmor.com Fri Jul 21 14:27:03 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Fri, 21 Jul 2006 13:27:03 -0500 Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft In-Reply-To: <44BF3773.3040708@ericsson.com> References: <44BB7881.4010205@ericsson.com> <4046FFFB-11DA-488C-8DAA-6ED8B6BE6C5E@softarmor.com> <44BF3773.3040708@ericsson.com> Message-ID: <0F12CA9B-21C1-49F7-AC9F-4570F80052C3@softarmor.com> On Jul 20, 2006, at 2:57 AM, Jani Hautakorpi (JO/LMF) wrote: > Hi Dean, > > Dean Willis wrote: >>> - How does a "P2PSIP Overlay User Agent differ from a traditional >>> SIP >>> UA? Is there a need to make a distinction between the two? >> A P2PSIP Overlay User Agent also includes a P2PSIP Overlay Peer or >> P2PSIP Overlay Client that might (assuming the client protocol is >> not plain SIP) be present in a regular SIP UA. > > Maybe I got this wrong, but I understood that an Overlay UA doesn't > *include* an Overlay Peer. I understood it in a way that Overlay UA > can be co-located in a same node with an Overlay Peer, and that > Overlay UA can *use* Overlay Peer. > > I'm still not convinced that we need to make a distinction between > an Overlay UA and a regular SIP UA. I see this in a way that the > Client and Peer protocols can be non-SIP/extended-SIP/whatever > protocols, but the protocol between the (Overlay) UA and Client/ > Peer could be plain SIP. At least at the moment I would see this > approach as an easy way to connect regular UAs to P2PSIP network. > What do you think? > I think I'll go with Eunsoo's answer earlier in this thread. > >>> - Is there a need to make a distinction between the "User Record" >>> and >>> "User Routing Record"? >> Well, it seemed reasonable at the time. There might be USer >> Records that are not routing records. The text says: >> ... >> So, one might envision something like a P2PSIP Overlay User >> Presence Record that contains presence, not routing information. > > Yes, there can be different User Records, but I'm not sure whether > this draft should try to define them all, or should this draft > define only "P2PSIP User Record" and let some other draft enumerate > all the different User Record types and their structures. Any > opinions? We may well have definitions for things that are not specified in detail by the group -- that is, we can have definitions that are used to describe things that are "out of scope". > > >>> 3.2. Reference Model: >>> - I felt that the figure didn't really represent the text in the >>> draft >>> too well. I tried to draw a figure which would match the text >>> (in my >>> opinion), see the figure in the diff-file. >> You're probably right but my brain doesn't parse your figure. >> Curved-lines in ASCII art all look like naked butterfly pictures >> or something to me, but they don't look like lines. > > The curved-lines aren't naked butterflies, they represent an edge > of a cloud instead. But if you like the figure otherwise, I can > replace ~s with the character of your choice. :-) > It MIGHT be ok, but I'm really having a hard time grokking the presentation. Maybe a real vector-format version of the drawing would make more sense to me. As it is, I'm not sure you've really captured the NAT-traversal aspects that Philip worked into the existing drawing at some effort. > >>> 3.3.5. Bootstrapping: >>> - The existence of Clients create a requirement for bootstrapping >>> procedure. That is, it would be good if bootstrapping procedure >>> would >>> be able to return a Peer from a relatively large pool of online >>> Peers. >> That's a valid approach, but may not be the only possible one. > > Maybe, but what I meant was that maybe something like the following > could be appended to section 3.3.5? > > Bootstrap servers should be able to return an address of a Peer to a > Client from a relatively large pool of Peer addresses. This is > because > otherwise load distribution would be insufficient, and some Peers > might get overloaded. That's one design alternative, and it has merit, but it might be premature to specify that sort of requirement at this stage. > > >>> 4.10. Peer-Adjacency Through NATs: >>> - This could be section 4.8, because this is probably related to the >>> section 4.7. >> You mean just re-order the sections? > > Yes (it doesn't really matter, this was just an observation). > Ok, I think we could do that. > >>> 4.11. Peer and Client Enrollment Protocols: >>> - There is one related question: "How to do admission control in >>> practice?" >> Use RSVP? > > :-) What I had in mind was that maybe something like "Do we need a > mechanism for preventing unauthorized nodes from accessing a P2PSIP > Overlay?" could be appended to section 4.11? > Ah! Very different from what I think when I hear "admission control", which is in my rather twisted world-view a QoS related question. It seems like a reasonable question (and the answer is probably "Duh! YES"). Send text, and I'll paste it into the working rev of the draft. -- Dean From mary.barnes at nortel.com Mon Jul 24 16:04:41 2006 From: mary.barnes at nortel.com (Mary Barnes) Date: Mon, 24 Jul 2006 15:04:41 -0500 Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... In-Reply-To: <44BE9E1F.6050802@research.panasonic.com> Message-ID: The minutes for this adhoc are available in the IETF-66 Proceedings under the SIPPING WG: http://www3.ietf.org/proceedings/06jul/minutes/sipping.txt The raw notes are available on the SIPPING WG supplementary webpage: http://www.softarmor.com/sipping/meets/ietf66/notes/index.html Mary -----Original Message----- From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] Sent: Wednesday, July 19, 2006 4:03 PM To: Barnes, Mary (RICH2:B601) Cc: Michael Slavitch; P2P-SIP Subject: Re: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc slides... For those who could not attend the ad-hoc meeting, I'd like to ask for reviewing the presentation slides and in particular thinking about the questions and proposed answers in David's slides. The slides contain a proposal for key work items (the essence of the charter). The meeting minutes will be published sooner or later but to be very short, an absolute majority of the ad-hoc meeting attendees agreed to the proposed answers in all the questions. Only the question about anonymous communication did not have a proposed answer and the most of the attendees did not prefer putting it as a requirement of the first version of the protocols Thanks. Eunsoo Mary Barnes wrote: > Yes, we should have had the charts available sooner. For reference they > are cached on the SIPPING WG supplementary page: > http://www.softarmor.com/sipping/meets/ietf66/slides/index.html > > Mary > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch > Sent: Friday, July 14, 2006 12:34 PM > To: P2P-SIP > Subject: [p2p-sip] Patiently waiting for the IETF 66 P2PSIP ad-hoc > slides... > > > Folks; > > Given that the IETF meeting is officially over this may be the one > time where an attachment sent to the list is a good idea. > > Regards > > Michael > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fluffy at cisco.com Sun Jul 23 11:58:51 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 23 Jul 2006 08:58:51 -0700 Subject: [p2p-sip] Fw: STUN (rfc3489) In-Reply-To: <00b101c69f75$563a5010$0300a8c0@china.huawei.com> References: <007201c69f6a$d6761350$0300a8c0@china.huawei.com> <8b2769930607040614o736b235bpe3a053f1def03153@mail.gmail.com> <00b101c69f75$563a5010$0300a8c0@china.huawei.com> Message-ID: Sounds reasonable to me - I was fairly convinced by the arguments that trying to add NAT support later would be very hard. On Jul 4, 2006, at 7:22 AM, Spencer Dawkins wrote: > My hope as well - that's why I'm asking! > > Spencer > > >> My personal hope is that we consider NAT traversal as an important >> and >> integral issue, but any actual new work in the area be done in other >> working groups. I think we should architect our protocols to work >> with >> NATs, and if needed refer problems (if any) with the current suite of >> tools to other WGs (BEHAVE, MMUSIC, or what have you). >> >> David > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From lowekamp at cs.wm.edu Wed Jul 26 22:08:42 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Wed, 26 Jul 2006 22:08:42 -0400 Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <017601c6a5df$7abb8ec0$2872150a@amer.cisco.com> References: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> <017601c6a5df$7abb8ec0$2872150a@amer.cisco.com> Message-ID: A few comments that came to mind while doing a quick read-through of this document: - I would really rather see the more current BEHAVE terminology used in this draft. Even though it's not yet official in an RFC, I think it will confuse people to see the older terminology used. - It would be nice to see a discussion of what standards are being developed to try to implement these techniques (e.g. which are supported by Teredo and ICE). I think the more recent ICE draft is written to imply a bit broader applicability than the previous one was. - I was surprised to notice that the authors did not cite their own very good USENIX05 paper as an informative reference. Bruce On 7/12/06, Dan Wing wrote: > During the PROTO (*) writeup, we decided that review of this document by > BEHAVE and P2P-SIP would be useful, as both groups have subject matter > experts in the area covered by this draft. The abstract of > draft-srisuresh-behave-p2p-state-03.txt is: > > This memo documents the various methods known to be in use by the > peer-to-peer (P2P) applications for communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods > described, but merely an attempt to capture them in a document. > > (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt > > -d > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > Sent: Wednesday, July 12, 2006 12:35 PM > > To: Philip Matthews > > Cc: ietf-behave at list.sipfoundry.org; p2p-sip at cs.columbia.edu; > > dwing at cisco.com; Dan Kegel > > Subject: Re: [Ietf-behave] Request for comments on > > draft-srisuresh-behave-p2p-state-03.txt > > > > Right. Thanks. > > > > regards, > > suresh > > > > --- Philip Matthews wrote: > > > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > > to review the draft and send you comments? > > > > > > - Philip > > > > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > > > Folks, > > > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > > submit the draft > > > > as independent submission to the RFC editor and request its > > > > publication as an > > > > informational RFC. Please review and let us know your > > comments by > > > > no later than > > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > > > The draft is available in the archives as follows. > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > > state-03.txt > > > > > > > > regards, > > > > suresh > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave at list.sipfoundry.org > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From srisuresh at yahoo.com Thu Jul 27 11:36:12 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Thu, 27 Jul 2006 08:36:12 -0700 (PDT) Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: Message-ID: <20060727153612.97735.qmail@web33307.mail.mud.yahoo.com> Thanks, Bruce, for your comments. Please see my responses inline. regards, suresh --- Bruce Lowekamp wrote: > A few comments that came to mind while doing a quick read-through of > this document: > > - I would really rather see the more current BEHAVE terminology used > in this draft. Even though it's not yet official in an RFC, I think > it will confuse people to see the older terminology used. > [suresh] We used the RFC 3489 terminology (Symmetric NATs, Cone NATs) because the draft is a capture of existing techniques. We felt, it made sense to use terminology from existing RFCs to describe the current state rather than use newer terms in Behave. I will take your advice and review the draft to see if this can be revised to use the BEHAVE terminology. Thanks. > - It would be nice to see a discussion of what standards are being > developed to try to implement these techniques (e.g. which are > supported by Teredo and ICE). I think the more recent ICE draft is > written to imply a bit broader applicability than the previous one > was. > [suresh] Right, your point is well taken. Even though, the draft does refer both ICE and TEREDO, the coverage can be better. I will add more text discussing the newer standards. The draft doesnt capture the newer ICE well. ICE draft is rapidly changing from UDP only to UDP + TCP and potentially more changes in newer revs. Oh, well.. > - I was surprised to notice that the authors did not cite their own > very good USENIX05 paper as an informative reference. [suresh] Sure, we will do that. Thank you for your comments. regards, suresh > > Bruce > > > On 7/12/06, Dan Wing wrote: > > During the PROTO (*) writeup, we decided that review of this document by > > BEHAVE and P2P-SIP would be useful, as both groups have subject matter > > experts in the area covered by this draft. The abstract of > > draft-srisuresh-behave-p2p-state-03.txt is: > > > > This memo documents the various methods known to be in use by the > > peer-to-peer (P2P) applications for communication in the presence > > of Network Address Translators (NATs) at the current time. This > > memo covers NAT traversal approaches used by both TCP and UDP > > based applications. This memo is not an endorsement of the methods > > described, but merely an attempt to capture them in a document. > > > > (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt > > > > -d > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > > Sent: Wednesday, July 12, 2006 12:35 PM > > > To: Philip Matthews > > > Cc: ietf-behave at list.sipfoundry.org; p2p-sip at cs.columbia.edu; > > > dwing at cisco.com; Dan Kegel > > > Subject: Re: [Ietf-behave] Request for comments on > > > draft-srisuresh-behave-p2p-state-03.txt > > > > > > Right. Thanks. > > > > > > regards, > > > suresh > > > > > > --- Philip Matthews wrote: > > > > > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > > > to review the draft and send you comments? > > > > > > > > - Philip > > > > > > > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > > > > > Folks, > > > > > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > > > submit the draft > > > > > as independent submission to the RFC editor and request its > > > > > publication as an > > > > > informational RFC. Please review and let us know your > > > comments by > > > > > no later than > > > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > > > > > The draft is available in the archives as follows. > > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > > > state-03.txt > > > > > > > > > > regards, > > > > > suresh > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ietf-behave mailing list > > > > > Ietf-behave at list.sipfoundry.org > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > From dwing at cisco.com Thu Jul 27 15:18:12 2006 From: dwing at cisco.com (Dan Wing) Date: Thu, 27 Jul 2006 12:18:12 -0700 Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060727153612.97735.qmail@web33307.mail.mud.yahoo.com> Message-ID: <04b801c6b1b1$6ac12b50$c2f0200a@amer.cisco.com> > > A few comments that came to mind while doing a quick read-through of > > this document: > > > > - I would really rather see the more current BEHAVE terminology used > > in this draft. Even though it's not yet official in an RFC, I think > > it will confuse people to see the older terminology used. > > [suresh] We used the RFC 3489 terminology (Symmetric NATs, > Cone NATs) because the draft is a capture of existing techniques. > We felt, it made sense to use terminology from existing RFCs to > describe the current state rather than use newer terms in Behave. I > will take your advice and review the draft to see if this can be > revised to use the BEHAVE terminology. Thanks. But draft-srisuresh-behave-p2p-state-03.txt's terminology doesn't match RFC3489's definitions. For example, taking just 'port restricted cone', there is a difference: RFC3489: # Port Restricted Cone: A port restricted cone NAT is like a # restricted cone NAT, but the restriction includes port numbers. # Specifically, an external host can send a packet, with source IP # address X and source port P, to the internal host only if the # internal host had previously sent a packet to IP address X and # port P. draft-srisuresh-behave-p2p-state-03.txt: # Port-Restricted Cone NAT # Subsequent to establishing Port Binding at the start of an # outgoing TCP/UDP session, Port-Restricted Cone NAT will # accept incoming traffic to the corresponding public port from # only those external endpoints to which the internal host has # previously sent one or more outgoing packets. I.e., only # those incoming packets that belong to the sessions initiated # by the private host are permitted on the inbound. "only those external endpoints" means IP address, but I expect your intent was to capture both the external endpoint (IP address) and external port. A lot of pain resulted in the consensus text in RFC3489; if you want to use those old terms, I would strongly encourage adopting the definitions from RFC3489 using exactly the same text as in RFC3489 itself. Similarly, if you want to adopt the new terms, it would be best to copy the text verbatim. -d From srisuresh at yahoo.com Thu Jul 27 17:07:34 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Thu, 27 Jul 2006 14:07:34 -0700 (PDT) Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <04b801c6b1b1$6ac12b50$c2f0200a@amer.cisco.com> Message-ID: <20060727210734.53208.qmail@web33310.mail.mud.yahoo.com> --- Dan Wing wrote: > > > A few comments that came to mind while doing a quick read-through of > > > this document: > > > > > > - I would really rather see the more current BEHAVE terminology used > > > in this draft. Even though it's not yet official in an RFC, I think > > > it will confuse people to see the older terminology used. > > > > [suresh] We used the RFC 3489 terminology (Symmetric NATs, > > Cone NATs) because the draft is a capture of existing techniques. > > We felt, it made sense to use terminology from existing RFCs to > > describe the current state rather than use newer terms in Behave. I > > will take your advice and review the draft to see if this can be > > revised to use the BEHAVE terminology. Thanks. > > But draft-srisuresh-behave-p2p-state-03.txt's terminology doesn't > match RFC3489's definitions. For example, taking just 'port restricted > cone', there is a difference: > > RFC3489: > > # Port Restricted Cone: A port restricted cone NAT is like a > # restricted cone NAT, but the restriction includes port numbers. > # Specifically, an external host can send a packet, with source IP > # address X and source port P, to the internal host only if the > # internal host had previously sent a packet to IP address X and > # port P. > > draft-srisuresh-behave-p2p-state-03.txt: > > # Port-Restricted Cone NAT > # Subsequent to establishing Port Binding at the start of an > # outgoing TCP/UDP session, Port-Restricted Cone NAT will > # accept incoming traffic to the corresponding public port from > # only those external endpoints to which the internal host has > # previously sent one or more outgoing packets. I.e., only > # those incoming packets that belong to the sessions initiated > # by the private host are permitted on the inbound. > > "only those external endpoints" means IP address, but I expect your > intent was to capture both the external endpoint (IP address) and > external port. [suresh] Dan - Early on, in the terminology section, the endpoint is referred as the tuple of (IP adress, Port). This is how the endpoint is referred throughout the documnt, including the figures (all 9 of them). The notation used in the figures to represent the endpoint is :. Endpoint is not referred as just an IP address, anywhere in the document. However, I could make endpoint semantics more explicit be definig this as a term. The same endpoint semantics are used even when defining "Address-Restricted Cone NAT" and "Full Cone NAT". Address-Restricted Cone NAT Subsequent to establishing Port Binding at the start of an outgoing UDP session, Address-Restricted Cone NAT will accept incoming UDP traffic to the corresponding public port from only those external endpoints whose IP address match the address of a node to which the internal host has previously sent one or more outgoing packets. Full Cone NAT Subsequent to establishing Port Binding at the start of an outgoing UDP session, a full cone NAT will accept incoming UDP traffic to the corresponding public port from ANY external endpoint on the public network. Full cone NAT is also sometimes referred as "Promiscuous NAT". > > A lot of pain resulted in the consensus text in RFC3489; if you > want to use those old terms, I would strongly encourage adopting > the definitions from RFC3489 using exactly the same text as in > RFC3489 itself. [suresh] There is ambiguity in RFC 3489 definitions. Hence the reason for disambiguating the terms by using illustration figures and additional text. For example, the p2p-state text describes that "Port-Restricted Cone NATs" are applicable to both TCP and UDP sessions. But, that "Address-Restricted Cone NAT" and "Full COne NAT" are specific to UDP only. > Similarly, if you want to adopt the new terms, > it would be best to copy the text verbatim. [suresh] The p2p-state draft has been around for some time (circa 2004). I believe, the draft text flows well using the terminology it has. To be honest, I am concerned about redoing the draft using BEHAVE terminology. That could be a big surgery and adds dependencies. UDP Behave is about to be an RFC. But, TCP Behave is not there yet. TCP behave terms do differ from the UDP draft. Dan and Bruce - My preference would be to use the terms as is instead of revising the draft with newer terms. I will be happy to make specific text changes where something is not clear. If this is agreeable to you, please suggest the speacific text where you see problem. Thanks. regards, suresh > > -d > From dwing at cisco.com Thu Jul 27 17:50:48 2006 From: dwing at cisco.com (Dan Wing) Date: Thu, 27 Jul 2006 14:50:48 -0700 Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060727210734.53208.qmail@web33310.mail.mud.yahoo.com> Message-ID: <079c01c6b1c6$b86cd920$c2f0200a@amer.cisco.com> > [suresh] Dan - Early on, in the terminology section, the > endpoint is referred as the tuple of (IP adress, Port). This is how > the endpoint is referred throughout the documnt, including the figures > (all 9 of them). The notation used in the figures to represent the > endpoint is :. Endpoint is not referred as just an > IP address, anywhere in the document. However, I could make endpoint > semantics more explicit be definig this as a term. I don't feel the normal definition of 'endpoint' is its IP address and UDP port. Does 'socket' or 'endpoint socket' have the meaning you are ascribing to 'endpoint'? ... > > A lot of pain resulted in the consensus text in RFC3489; if you > > want to use those old terms, I would strongly encourage adopting > > the definitions from RFC3489 using exactly the same text as in > > RFC3489 itself. > > [suresh] There is ambiguity in RFC 3489 definitions. Hence > the reason for disambiguating the terms by using illustration > figures and additional text. For example, the p2p-state text > describes that "Port-Restricted Cone NATs" are applicable to both > TCP and UDP sessions. But, that "Address-Restricted Cone NAT" > and "Full COne NAT" are specific to UDP only. Instead of clarifying a standards-track document (RFC3489) with an informational document, I see more value in just letting the old terms die out and be replaced with the mapping and filtering terms in -behave-nat-udp (sections 4.1 and 5). When RFC3489bis (draft-ietf-behave-rfc3489bis) is published, it will obsolete RFC3489. It seems useful that the only use of the terms will soon be a document marked 'Obsoleted by' so we can adopt the newer and more accurate terms. > > Similarly, if you want to adopt the new terms, > > it would be best to copy the text verbatim. > > [suresh] The p2p-state draft has been around for some time > (circa 2004). I believe, the draft text flows well using > the terminology it has. To be honest, I am concerned about > redoing the draft using BEHAVE terminology. That could be > a big surgery and adds dependencies. I agree it could be a large surgery on the document. I don't understand how it would add a dependency; neither Bruce nor I suggested adding a normative reference. Even if you did, the normative reference would be to behave-nat-udp which is very close to being finished in IESG and will be a standards- track document (so no worries about a downward reference). > UDP Behave is about to > be an RFC. But, TCP Behave is not there yet. TCP behave > terms do differ from the UDP draft. What is the value of TCP's different terms? I mean, does the different terminology help or hurt understanding, consensus, and interoperability? > Dan and Bruce - My preference would be to use the terms as is > instead of revising the draft with newer terms. I will be > happy to make specific text changes where something is not > clear. If this is agreeable to you, please suggest the > speacific text where you see problem. Thanks. The specific text where I see a problem is the use of RFC3489 terminology (cone, port restricted, symmetric) when RFC3489bis is an active WG document and will not include that terminology. That means, upon publication of draft-srisuresh-behave-p2p-state as Informational, it will be the only document that uses these soon-to-be-obsoleted terms. -d From srisuresh at yahoo.com Thu Jul 27 19:17:57 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Thu, 27 Jul 2006 16:17:57 -0700 (PDT) Subject: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <079c01c6b1c6$b86cd920$c2f0200a@amer.cisco.com> Message-ID: <20060727231757.10265.qmail@web33315.mail.mud.yahoo.com> --- Dan Wing wrote: > > > [suresh] Dan - Early on, in the terminology section, the > > endpoint is referred as the tuple of (IP adress, Port). This is how > > the endpoint is referred throughout the documnt, including the figures > > (all 9 of them). The notation used in the figures to represent the > > endpoint is :. Endpoint is not referred as just an > > IP address, anywhere in the document. However, I could make endpoint > > semantics more explicit be definig this as a term. > > I don't feel the normal definition of 'endpoint' is its IP address > and UDP port. Does 'socket' or 'endpoint socket' have the meaning > you are ascribing to 'endpoint'? > [suresh] I donot believe, there is a well-known definition to endpoint. The p2p-state draft refers this as a protocol specific tuple. I will define the term explicitly in Terminology section. > ... > > > A lot of pain resulted in the consensus text in RFC3489; if you > > > want to use those old terms, I would strongly encourage adopting > > > the definitions from RFC3489 using exactly the same text as in > > > RFC3489 itself. > > > > [suresh] There is ambiguity in RFC 3489 definitions. Hence > > the reason for disambiguating the terms by using illustration > > figures and additional text. For example, the p2p-state text > > describes that "Port-Restricted Cone NATs" are applicable to both > > TCP and UDP sessions. But, that "Address-Restricted Cone NAT" > > and "Full COne NAT" are specific to UDP only. > > Instead of clarifying a standards-track document (RFC3489) with > an informational document, I see more value in just letting the > old terms die out and be replaced with the mapping and filtering > terms in -behave-nat-udp (sections 4.1 and 5). When RFC3489bis > (draft-ietf-behave-rfc3489bis) is published, it will obsolete > RFC3489. It seems useful that the only use of the terms will > soon be a document marked 'Obsoleted by' so we can adopt the > newer and more accurate terms. > [suresh] I understand. > > > Similarly, if you want to adopt the new terms, > > > it would be best to copy the text verbatim. > > > > [suresh] The p2p-state draft has been around for some time > > (circa 2004). I believe, the draft text flows well using > > the terminology it has. To be honest, I am concerned about > > redoing the draft using BEHAVE terminology. That could be > > a big surgery and adds dependencies. > > I agree it could be a large surgery on the document. > > I don't understand how it would add a dependency; neither Bruce > nor I suggested adding a normative reference. Even if you > did, the normative reference would be to behave-nat-udp which > is very close to being finished in IESG and will be a standards- > track document (so no worries about a downward reference). > > > UDP Behave is about to > > be an RFC. But, TCP Behave is not there yet. TCP behave > > terms do differ from the UDP draft. > > What is the value of TCP's different terms? I mean, does the > different terminology help or hurt understanding, consensus, > and interoperability? > > > Dan and Bruce - My preference would be to use the terms as is > > instead of revising the draft with newer terms. I will be > > happy to make specific text changes where something is not > > clear. If this is agreeable to you, please suggest the > > speacific text where you see problem. Thanks. > > The specific text where I see a problem is the use of RFC3489 > terminology (cone, port restricted, symmetric) when RFC3489bis > is an active WG document and will not include that terminology. > That means, upon publication of draft-srisuresh-behave-p2p-state > as Informational, it will be the only document that uses these > soon-to-be-obsoleted terms. > [suresh] OK, I will try and revise the text so as not to refer RFC3489 terms. Thanks. regards, suresh > -d >