From justin at affinix.com Thu Jan 7 16:50:57 2010 From: justin at affinix.com (Justin Karneges) Date: Thu, 7 Jan 2010 14:50:57 -0800 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <200905272212.48744.justin@affinix.com> References: <200905272212.48744.justin@affinix.com> Message-ID: <201001071450.57642.justin@affinix.com> On Wednesday 27 May 2009 22:12:48 Justin Karneges wrote: > A user in the Psi room tried to convince me that the client should not use > STUN to determine the external source port. Instead, the external source > port should be assumed to be the same as the internal source port. This > assumption might allow the client to work even behind a STUN-incompatible > NAT, as long as the NAT is the kind that tends to use the same external > port as the internal. You could call this a "leap of faith" approach. > > The leap of faith approach does work. In fact, it is possible to configure > Psi one way or the other (use STUN, or use leap of faith), and with some > NATs I can only get success with leap of faith. In Psi, this configuration > is currently subpar for two reasons: 1) you have to explicitly specify your > external IP address, and 2) you can't use STUN at the same time. > > After the discussion with this user, it occurred to me: why not support > both mechanisms simultaneously, and use STUN to obtain the external address > to be used for leap of faith? The process would go like this: > > 1) bind local port X > 2) contact stun server from port X, to obtain reflexive address SA, port > SX 3) bind local port Y > 4) result is two srflx candidates: SA:SX, SA:Y, using different > priorities > > The approach is complex, because then you have two local ports to manage. > But as far as I can tell, it shouldn't break the protocol, and the > potential to support even more NATs without needing TURN may make it worth > implementing. > > What do others think? I've been thinking more about this, and I wonder how we should decide which remote candidate shall be considered for leap of faith. Psi tries the candidates in order, and in most cases I believe this means it will end up trying some "host" candidate first followed by a "srflx" candidate. But if the "host" candidate causes any NATing (say, because my subnet is 192.168.1.x and yours is 10.10.10.x), then attempting the host candidate first will break the leap of faith. Probably it only worked for me in my tests because the peer happened to use the same subnet addressing scheme. So how should a client decide which candidate to try first? Some ideas: 1) Choose the highest priority "srflx" candidate. If no srflx candidate exists, choose the highest priority "host" candidate. If no "host" candidate exists then it doesn't matter what is tried first. 2) Have a way for the remote client to indicate the order that the candidates should be tried, or at least indicate which one is the LoF candidate. For example, the spec could be changed to say that the candidates must be tried in the order they are received, or we could add an XML attribute for flagging a candidate as LoF. -Justin From olivier.crete at collabora.co.uk Thu Jan 7 18:54:54 2010 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Thu, 07 Jan 2010 19:54:54 -0500 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <201001071450.57642.justin@affinix.com> References: <200905272212.48744.justin@affinix.com> <201001071450.57642.justin@affinix.com> Message-ID: <1262912094.22686.63.camel@TesterTop3> On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > 1) Choose the highest priority "srflx" candidate. If no srflx candidate > exists, choose the highest priority "host" candidate. If no "host" candidate > exists then it doesn't matter what is tried first. The candidates are always tried ordered with the highest priority first, see ICE-19 section 5.7.2. I don't understand why you need two local ports? You expect that the NAT will allocate the same port to the packets going to the STUN server but a different port to the following ones ? Or are you going on pure luck ? -- Olivier Cr?te olivier.crete at collabora.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From justin at affinix.com Thu Jan 7 22:42:34 2010 From: justin at affinix.com (Justin Karneges) Date: Thu, 7 Jan 2010 20:42:34 -0800 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <1262912094.22686.63.camel@TesterTop3> References: <200905272212.48744.justin@affinix.com> <201001071450.57642.justin@affinix.com> <1262912094.22686.63.camel@TesterTop3> Message-ID: <201001072042.34665.justin@affinix.com> On Thursday 07 January 2010 16:54:54 Olivier Cr?te wrote: > On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > > 1) Choose the highest priority "srflx" candidate. If no srflx candidate > > exists, choose the highest priority "host" candidate. If no "host" > > candidate exists then it doesn't matter what is tried first. > > The candidates are always tried ordered with the highest priority first, > see ICE-19 section 5.7.2. Correct. The problem is that the host candidates will generally be prioritized first, but to perform the leap-of-faith correctly you need your first connectivity check to go to a srflx candidate. > I don't understand why you need two local ports? You expect that the NAT > will allocate the same port to the packets going to the STUN server but > a different port to the following ones ? Yes, that's exactly it. If you're behind a NAT that fails with STUN but would succeed with leap-of-faith, the act of contacting the STUN server will break the leap-of-faith from working. -Justin From olivier.crete at collabora.co.uk Thu Jan 7 23:05:55 2010 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Fri, 08 Jan 2010 00:05:55 -0500 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <201001072042.34665.justin@affinix.com> References: <200905272212.48744.justin@affinix.com> <201001071450.57642.justin@affinix.com> <1262912094.22686.63.camel@TesterTop3> <201001072042.34665.justin@affinix.com> Message-ID: <1262927155.7906.1.camel@TesterBox.tester.ca> On Thu, 2010-01-07 at 20:42 -0800, Justin Karneges wrote: > On Thursday 07 January 2010 16:54:54 Olivier Cr?te wrote: > > On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > > > 1) Choose the highest priority "srflx" candidate. If no srflx candidate > > > exists, choose the highest priority "host" candidate. If no "host" > > > candidate exists then it doesn't matter what is tried first. > > > > The candidates are always tried ordered with the highest priority first, > > see ICE-19 section 5.7.2. > > Correct. The problem is that the host candidates will generally be > prioritized first, but to perform the leap-of-faith correctly you need your > first connectivity check to go to a srflx candidate. Your implementation could very well give a higer prio to the "leap of faith" candidate, which is imho a host candidate, not a srflx candidate.. Since its not really what any server told you. -- Olivier Cr?te olivier.crete at collabora.co.uk Collabora Ltd -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From justin at affinix.com Thu Jan 7 23:33:29 2010 From: justin at affinix.com (Justin Karneges) Date: Thu, 7 Jan 2010 21:33:29 -0800 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <1262927155.7906.1.camel@TesterBox.tester.ca> References: <200905272212.48744.justin@affinix.com> <201001072042.34665.justin@affinix.com> <1262927155.7906.1.camel@TesterBox.tester.ca> Message-ID: <201001072133.30055.justin@affinix.com> On Thursday 07 January 2010 21:05:55 Olivier Cr?te wrote: > On Thu, 2010-01-07 at 20:42 -0800, Justin Karneges wrote: > > On Thursday 07 January 2010 16:54:54 Olivier Cr?te wrote: > > > On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > > > > 1) Choose the highest priority "srflx" candidate. If no srflx > > > > candidate exists, choose the highest priority "host" candidate. If > > > > no "host" candidate exists then it doesn't matter what is tried > > > > first. > > > > > > The candidates are always tried ordered with the highest priority > > > first, see ICE-19 section 5.7.2. > > > > Correct. The problem is that the host candidates will generally be > > prioritized first, but to perform the leap-of-faith correctly you need > > your first connectivity check to go to a srflx candidate. > > Your implementation could very well give a higer prio to the "leap of > faith" candidate, which is imho a host candidate, not a srflx > candidate.. Since its not really what any server told you. Giving highest priority to the leap of faith candidate would allow it to be checked first, but the drawback is it would also become the highest nominated candidate for the actual data traffic which is not what we want. For example, if both clients happen to be on the same network, but they give highest priority to an external IP address, then it may cause all of their traffic to route through the NAT instead of truly direct. For best results, the connect check order needs to be different from the nomination order. -Justin From justin at affinix.com Fri Jan 8 00:10:28 2010 From: justin at affinix.com (Justin Karneges) Date: Thu, 7 Jan 2010 22:10:28 -0800 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <201001072133.30055.justin@affinix.com> References: <200905272212.48744.justin@affinix.com> <1262927155.7906.1.camel@TesterBox.tester.ca> <201001072133.30055.justin@affinix.com> Message-ID: <201001072210.28610.justin@affinix.com> On Thursday 07 January 2010 21:33:29 Justin Karneges wrote: > For best results, the connect check order needs to be different from the > nomination order. I just thought of something amusing: since XEP-0176 supports trickling candidates, you can always force a certain connect check order by trickling the candidates out in that order, even if their priorities are not in that order. Maybe a simple solution is to make the connect check order match the order the candidates were received in all cases, whether trickled or all at once. -Justin From olivier.crete at collabora.co.uk Fri Jan 8 00:21:08 2010 From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=) Date: Fri, 08 Jan 2010 01:21:08 -0500 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <201001072133.30055.justin@affinix.com> References: <200905272212.48744.justin@affinix.com> <201001072042.34665.justin@affinix.com> <1262927155.7906.1.camel@TesterBox.tester.ca> <201001072133.30055.justin@affinix.com> Message-ID: <1262931668.7906.3.camel@TesterBox.tester.ca> On Thu, 2010-01-07 at 21:33 -0800, Justin Karneges wrote: > On Thursday 07 January 2010 21:05:55 Olivier Cr?te wrote: > > On Thu, 2010-01-07 at 20:42 -0800, Justin Karneges wrote: > > > On Thursday 07 January 2010 16:54:54 Olivier Cr?te wrote: > > > > On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > > > > > 1) Choose the highest priority "srflx" candidate. If no srflx > > > > > candidate exists, choose the highest priority "host" candidate. If > > > > > no "host" candidate exists then it doesn't matter what is tried > > > > > first. > > > > > > > > The candidates are always tried ordered with the highest priority > > > > first, see ICE-19 section 5.7.2. > > > > > > Correct. The problem is that the host candidates will generally be > > > prioritized first, but to perform the leap-of-faith correctly you need > > > your first connectivity check to go to a srflx candidate. > > > > Your implementation could very well give a higer prio to the "leap of > > faith" candidate, which is imho a host candidate, not a srflx > > candidate.. Since its not really what any server told you. > > Giving highest priority to the leap of faith candidate would allow it to be > checked first, but the drawback is it would also become the highest nominated > candidate for the actual data traffic which is not what we want. For > example, if both clients happen to be on the same network, but they give > highest priority to an external IP address, then it may cause all of their > traffic to route through the NAT instead of truly direct. > > For best results, the connect check order needs to be different from the > nomination order. It doesn't matter, because the real host candidate will never reach the other side if there is a NAT. Using another order than the priority order is just asking for trouble. -- Olivier Cr?te olivier.crete at collabora.co.uk Collabora Ltd -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From justin at affinix.com Fri Jan 8 02:15:28 2010 From: justin at affinix.com (Justin Karneges) Date: Fri, 8 Jan 2010 00:15:28 -0800 Subject: [Jingle] ICE: STUN and leap of faith, at the same time In-Reply-To: <1262931668.7906.3.camel@TesterBox.tester.ca> References: <200905272212.48744.justin@affinix.com> <201001072133.30055.justin@affinix.com> <1262931668.7906.3.camel@TesterBox.tester.ca> Message-ID: <201001080015.28358.justin@affinix.com> On Thursday 07 January 2010 22:21:08 Olivier Cr?te wrote: > On Thu, 2010-01-07 at 21:33 -0800, Justin Karneges wrote: > > On Thursday 07 January 2010 21:05:55 Olivier Cr?te wrote: > > > On Thu, 2010-01-07 at 20:42 -0800, Justin Karneges wrote: > > > > On Thursday 07 January 2010 16:54:54 Olivier Cr?te wrote: > > > > > On Thu, 2010-01-07 at 14:50 -0800, Justin Karneges wrote: > > > > > > 1) Choose the highest priority "srflx" candidate. If no srflx > > > > > > candidate exists, choose the highest priority "host" candidate. > > > > > > If no "host" candidate exists then it doesn't matter what is > > > > > > tried first. > > > > > > > > > > The candidates are always tried ordered with the highest priority > > > > > first, see ICE-19 section 5.7.2. > > > > > > > > Correct. The problem is that the host candidates will generally be > > > > prioritized first, but to perform the leap-of-faith correctly you > > > > need your first connectivity check to go to a srflx candidate. > > > > > > Your implementation could very well give a higer prio to the "leap of > > > faith" candidate, which is imho a host candidate, not a srflx > > > candidate.. Since its not really what any server told you. > > > > Giving highest priority to the leap of faith candidate would allow it to > > be checked first, but the drawback is it would also become the highest > > nominated candidate for the actual data traffic which is not what we > > want. For example, if both clients happen to be on the same network, but > > they give highest priority to an external IP address, then it may cause > > all of their traffic to route through the NAT instead of truly direct. > > > > For best results, the connect check order needs to be different from the > > nomination order. > > It doesn't matter, because the real host candidate will never reach the > other side if there is a NAT. I was talking about two clients on the same network sharing the same NAT. In that case both the real host candidates and external IP address candidates could succeed. From justin at affinix.com Wed Jan 20 02:32:26 2010 From: justin at affinix.com (Justin Karneges) Date: Wed, 20 Jan 2010 00:32:26 -0800 Subject: [Jingle] IPv6 addresses and scope id Message-ID: <201001200032.26901.justin@affinix.com> This is not really a Jingle/ICE-specific question, but I came across the problem today, and I wonder if anyone has a suggestion. How should IPv6 scope ids be handled in the bind, offer, and send steps of ICE? 1) Bind: What scope id should be used for the bind? It seems that scope ids are needed for non-global addresses, and the actual values are platform-specific. Do I really need some logic like: if(!address.isGlobal()) if(windows) scope = index; else scope = name; It seems really gross that I should have to do such a thing. 2) Offer: Should the scope id be included in IPv6 addresses sent over the signaling channel? My guess is no, that the addresses should be bare, since scope id is a local issue. 3) Send: When sending to a remote IPv6 address, I need to include the scope id. This would mean taking the addresses received over the signalling channel, and then tacking on a locally-understood scope id to the end of it. Maybe the same approach as the Bind case should be used. Sorry for the somewhat off-topic question. I've been googling for hours finding no real answer, and we have a smart group on this mailing list. -Justin From justin at affinix.com Sat Jan 23 02:35:39 2010 From: justin at affinix.com (Justin Karneges) Date: Sat, 23 Jan 2010 00:35:39 -0800 Subject: [Jingle] IPv6 addresses and scope id In-Reply-To: <201001200032.26901.justin@affinix.com> References: <201001200032.26901.justin@affinix.com> Message-ID: <201001230035.39174.justin@affinix.com> On Wednesday 20 January 2010 00:32:26 Justin Karneges wrote: > This is not really a Jingle/ICE-specific question, but I came across the > problem today, and I wonder if anyone has a suggestion. How should IPv6 > scope ids be handled in the bind, offer, and send steps of ICE? Replying to myself: > 1) Bind: What scope id should be used for the bind? It seems that scope > ids are needed for non-global addresses, and the actual values are > platform-specific. Do I really need some logic like: > > if(!address.isGlobal()) > if(windows) > scope = index; > else > scope = name; > > It seems really gross that I should have to do such a thing. As far as I can tell this is what you're actually supposed to do. It's not quite as bad as I thought though: the scope is really always the interface index in low-level IPv6 APIs, and the potentially platform-specific number/name difference is only introduced when you start stringifying. > 2) Offer: Should the scope id be included in IPv6 addresses sent over the > signaling channel? My guess is no, that the addresses should be bare, > since scope id is a local issue. Alright, I'm almost 100% sure the IPv6 addresses sent should be bare (and if you receive a non-bare address, then you should ignore its scope id). Relatedly, you must only create one local candidate per bare IPv6 address. So if you happen to have two identical link-local IPv6 addresses on your machine, assigned to different interfaces, you should not bind to both and attempt to use both because that can lead to ambiguous candidate pair nomination. For example, it is a rather extreme case, but if you have two such addresses X%1 and X%2, and the peer has Y%1 and Y%2, and X%1 and Y%1 are on one network and X%2 and Y%2 are on the other, it is possible for an X<->Y connectivity check to succeed on two paths, but the peers won't know which one to really use since their priorities would be the same. You might be able to make this work by not using aggressive-nomination. And if only one side has duplicate addresses, then it could work too. However, the fact that when it doesn't work it fails in a way that breaks ICE is enough for me to say don't bother. ICE just wasn't designed to handle the case where you have multiple of the same IP address (which IMO is quite fair). > 3) Send: When sending to a remote IPv6 address, I need to include the scope > id. This would mean taking the addresses received over the signalling > channel, and then tacking on a locally-understood scope id to the end of > it. Maybe the same approach as the Bind case should be used. For this, I'm using the scope id of the socket doing the sending. So when a candidate pair is created, there is this logic: if(pair.local.address.is_link_local) pair.remote.address.scope_id = pair.local.address.scope_id; I believe I've reasoned everything out then, and this is the approach Psi will use unless someone tells me it is wrong. -Justin