Subject: Re: [MMUSIC] Review of ice-tcp-10

From: Ari Keranen <[email-masked]>
Date: Fri, 01 Apr 2011 09:33:23 +0200

On 1.4.2011 8:09, Jonathan Lennox wrote:
> On Mar 31, 2011, at 11:57 PM, Ari Keranen wrote:
>> On 31.3.2011 20:06, Jonathan Lennox wrote:
>>>
>>> I think this needs to be MUST -- under what circumstances would
>>> a sender want to insert false-positive STUN packets in the
>>> stream?
>>>
>>> (Of course, depending on the content, it's possible that the
>>> sender knows a priori that there can be no false positives, for
>>> instance if it's sending a 7-bit-ASCII protocol.)
>>
>> While a bit of a corner case, I think this proves SHOULD is an
>> appropriate one here :)
>
> I think the sender MUST ensure there are no false-positive STUN
> packets in the stream, but as discussed here and the subsequent
> discussion, there are a number of ways to accomplish this.  Whether
> to give implementation guidance as to how best to do it is a separate
> matter, and I see your point about not wanting to go on too much
> about it.

I had an off-line discussion about this, and it seems having this as a 
MUST makes things simpler, and should not hurt really anyone. So let's 
make it a MUST in the next revision.

>>> For section 5.2, Server Reflexive Candidates (and also the
>>> prioritization formulas):
>>>
>>> Unless I'm missing something, Server Reflexive Candidates are
>>> only possible and useful for Simultaneous-Open connections, not
>>> Active or Passive?  Either this should be pointed out, or there
>>> should be an explanation of how you'd create, and how you'd make
>>> use of, Server-Reflexive Active or Passive candidates.
>>
>> AFAIK, server reflexive should be OK also for passive candidates
>> (once you do the tricks described in Appendix B).
>
> Ah, I see -- so you're recommending doing the "send from your receive
> port" trick to STUN your passive candidate, in hopes the NAT has
> Endpoint-Independent Filtering.  I don't know how likely that policy
> is going to be in practice (for pure server-reflexive, as opposed to
> NAT-assisted, candidates), but I guess it couldn't hurt to try it, so
> long as your OS supports the Appendix B tricks.

Exactly.

>> I could add to the server reflexive candidate section something
>> along the lines of:
>>
>> Obtaining server reflexive passive candidates may require sending
>> requests from the passive candidate; see Appendix B for
>> implementation details. Server reflexive active candidates can be
>> derived from the passive or S-O candidates by using the same IP
>> address as the passive or S-O server reflexive candidate has.
>
> That makes sense.
>
> It's probably worth having some language describing why they're
> useful, too (i.e. the TURN permissions issue) -- I probably won't be
> the only person to miss that.

OK, I'll add that too.

>>> For section 5.3, UDP-Tunneled Candidates:
>>>
>>> When UDP tunneling is done by your operating system (as is the
>>> case with Teredo on Microsoft Windows), it may not be obvious
>>> based on the system APIs that a given candidate is in fact a
>>> UDP-tunneled candidate and not a host candidate.  If there is a
>>> need to give UDP-tunneled candidates a lower type-preference, it
>>> should be pointed out that implementations will need to detect
>>> local pseudo-interfaces that are actually UDP tunnels.
>>
>> OK. This is a bit of an implementation detail, but I can try to
>> add something along those lines to the section 5.4.
>
> As you wish.  (It's not just Teredo on Windows; most OS-provided
> tunnel addresses will look like an additional interface address, I
> think.)
>
>>> There's also the complexity that Teredo candidates may, in fact,
>>> end up being Relayed candidates, when matched up with non-Teredo
>>> IPv6 addresses.  Handling this (and de-prioritizing the pairs)
>>> based on the normal rules of ICE would be very difficult,
>>> however, other than by unilateral action of the controlling
>>> endpoint.
>>
>> Yes. But given how complex this goes, I think we're better of
>> without trying to define something for this.
>
> I agree we can't standardize this in any useful way, yes; but it
> could be a consideration for the controlling endpoint's choice of
> which pair to nominate, so it might be worth pointing out.
>
> On the other hand, it's not TCP-specific, and it's an implementation
> detail; I know you're trying to stop the document from getting too
> long.  So as you wish.

OK. I think it makes sense to avoid extra complexity here, but adding 
the short note about detecting the tunnel interface is still worth it.

Cheers,
Ari