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

From: Jonathan Lennox <[email-masked]>
Date: Thu, 31 Mar 2011 14:06:49 -0400

I've reveiwed ice-tcp-10 -- better late than never, I suppose.

In general, this document seems very solid, and in my opinion is ready for WGLC; I have only a few minor technical quibbles and suggestions, plus a few editorial comments.

Section 10.1:

   Next, the sender checks
   to see if the resulting set of bytes would be viewed as a STUN packet
   based on the rules in Sections 6 and 8 of [RFC5389].  This includes a
   check on the most significant two bits, the magic cookie, the length,
   and the fingerprint.  If, based on those rules, the bytes would be
   viewed as a STUN message, the sender SHOULD utilize a different
   number of bytes so that the length checks will fail.

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

I'd also suggest adding a suggestion: "One possible adjustment is to split the payload in two after its sixth byte. The seventh byte of a STUN packet, the hexadecimal A4 from the magic cookie, begins with the bits 1 0, so neither the first split payload (which is too short) nor the second one (which begins with the wrong bits) could falsely appear to be a STUN packet."  Wordsmithing, or alternate simple suggestions, welcome.

I'd also suggest that a sender MAY pre-emptively adjust any payload that matches a subset of these checks, e.g. just the significant bits, length, and magic cookie, if it wishes to avoid calculating fingerprints over the data it's sending.

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.

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.

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.

Neither of these issues are specific to ICE-TCP, other than the fact that UDP-Tunneled candidates weren't mentioned in the original ICE.

Editorial:

Section 10.1:

  For
   media streams that are not RTP-based and do not normally use RFC
   4571, the agent treats the media stream as a byte stream, and assumes
   that it has its own framing of some sort.  

This is an extreme quibble, but conceivably you could have a higher-level byte stream with no framing whatsoever (e.g. dumb file transfer over SIP: open a media stream, dump a file, close the stream).  It doesn't change anything about this protocol, though.

Section 4.5:

   Since an ICE ICE offerer always uses an active candidate as default,
   an ICE ICE answerer will always use a passive candidate as default
   and include the a=setup:passive attribute in the answer.

"ICE" is repeated, twice.

--
Jonathan Lennox
[email-masked]

---

From: Ari Keranen <[email-masked]>
Date: Thu, 31 Mar 2011 23:57:35 +0200

Hi Jonathan,

> I've reveiwed ice-tcp-10 -- better late than never, I suppose.

Definitely. Thanks!

> In general, this document seems very solid, and in my opinion is
> ready for WGLC; I have only a few minor technical quibbles and
> suggestions, plus a few editorial comments.
>
> Section 10.1:
>
> Next, the sender checks to see if the resulting set of bytes would be
> viewed as a STUN packet based on the rules in Sections 6 and 8 of
> [RFC5389].  This includes a check on the most significant two bits,
> the magic cookie, the length, and the fingerprint.  If, based on
> those rules, the bytes would be viewed as a STUN message, the sender
> SHOULD utilize a different number of bytes so that the length checks
> will fail.
>
> 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'd also suggest adding a suggestion: "One possible adjustment is to
> split the payload in two after its sixth byte. The seventh byte of a
> STUN packet, the hexadecimal A4 from the magic cookie, begins with
> the bits 1 0, so neither the first split payload (which is too short)
> nor the second one (which begins with the wrong bits) could falsely
> appear to be a STUN packet."  Wordsmithing, or alternate simple
> suggestions, welcome.
>
> I'd also suggest that a sender MAY pre-emptively adjust any payload
> that matches a subset of these checks, e.g. just the significant
> bits, length, and magic cookie, if it wishes to avoid calculating
> fingerprints over the data it's sending.

Thanks a lot for the text suggestions, but since *any* way for splitting 
the payload is sufficient (the length will not match), I think we are 
better of without additional text on this. Especially considering how 
corner case this is to begin with..

> 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). Also, server reflexive 
active candidates are useful with relays since with TURN one needs to 
give the TURN server the address of the peer (set permissions) for 
incoming connections.

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.

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

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

> Neither of these issues are specific to ICE-TCP, other than the fact
> that UDP-Tunneled candidates weren't mentioned in the original ICE.
>
>
> Editorial:
>
> Section 10.1:
>
> For media streams that are not RTP-based and do not normally use RFC
> 4571, the agent treats the media stream as a byte stream, and
> assumes that it has its own framing of some sort.
>
> This is an extreme quibble, but conceivably you could have a
> higher-level byte stream with no framing whatsoever (e.g. dumb file
> transfer over SIP: open a media stream, dump a file, close the
> stream).  It doesn't change anything about this protocol, though.

True. Maybe we can make that " [...] of some sort, if needed".

> "ICE" is repeated, twice.

Good catch! That should say "ICE TCP".

Thanks,
Ari

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 1 Apr 2011 02:09:41 -0400

> While a bit of a corner case, I think this proves SHOULD is an 

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.

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

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

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

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

--
Jonathan Lennox
[email-masked]