Found 1 record.
Status: Rejected (1)
RFC 6544, "TCP Candidates with Interactive Connectivity Establishment (ICE)", March 2012Source of RFC: mmusic (rai)
Errata ID: 3231
Publication Format(s) : TEXT
Reported By: Nigel Pattinson
Date Reported: 2012-05-23
Rejected by: Robert Sparks
Date Rejected: 2012-06-07
Section 4 - 11 says:
Apologies in advance - I have some feedback on the specification which I feel may be useful, but it is not by nature errata - I wasn't sure how else to report this.
In our company we have just implemented support for ICE-TCP, and in our opinion there are some areas of the specification which could use some clarification. Note that our implementation is designed to be used in an XMPP/Jingle context rather than with SIP, which potentially makes a difference in some of the areas mentioned below.
The specification makes no mention of foundations for TCP candidates. 184.108.40.206 in [RFC5245] specifies that TCP foundations must be different from UDP foundations, but it is unclear whether or not passive, active, and simultaneous open candidates should have distinct foundations. The same is true for NAT-assisted and tunneled candidate types - should these have distinct foundations from server-reflexive/relayed candidates ? We have guessed that in all cases they should be distinct.
220.127.116.11 in [RFC5245] states that server reflexive candidates should be kept alive until ICE processing completes. 11.2 in RFC 6544 does not contradict this, but does not clarify it either. This implies that TCP connections to a STUN server should be kept open for this duration, with STUN binding requests being sent at intervals. It is not clear to us that doing so would have any benefit, but we are not NAT experts. Either way it would be good if the ICE-TCP specification made it clear whether or not this was necessary or desirable.
When the offerer has relayed candidates obtained from a TURN server, it may not be possible to ensure that permissions are created for those passive candidates prior to the peer attempting to connect. This may result in failure of the peer's active check, and hence possibly in failure of ICE as a whole. The same basic problem can happen in ICE-UDP, but the UDP check would almost certainly be retried at a time when the permissions are in place, and so should succeed eventually. The situation could be exacerbated by the Jingle recommendation that candidates are sent to the peer as soon as they are discovered - in this case even the answerer's relayed candidates may not have the permissions in place when they are needed. We're not sure if there is a foolproof solution to these problems, but we do feel that the potential for failures should at least be mentioned.
7.1 states that for tcp-active candidates, unallocated ports should be used. This may result in many port allocations, so we wonder whether it would be preferable to reuse the same port for all connections made from a tcp-active candidate (where supported by the host OS, of course).
Sections 7.1 and 7.2 both note that a peer-reflexive candidate will 'typically' be produced. In 7.1 this is in reference to a STUN response received on an active TCP candidate, whereas in 7.2 it is in reference to a STUN request received on a passive TCP candidate. It is unclear to us whether the wording is intended to mean that this is different to the equivalent case in UDP, where a peer-reflexive candidate might, but would not 'typically', be produced. The only difference between TCP and UDP that we can see in this area is that the port actually used for active TCP candidates differs from that advertised, since all active TCP candidates are offered with 9 as the port number. We assume that this is the core reason behind the wording used, but think that it would be better if the specification explicitly stated this. We also believe that it is possible to correctly identify the correct active TCP candidate despite the lack of explicit port number information, simply by treating 9 as a wildcard that matches any port. Doing so has the benefit that all the information held against the candidate (especially priority and foundation) can be used as intended, whereas if a new peer-reflexive candidate is created this information will always be ignored for active TCP candidates. Currently our implementation does this wildcard matching, so will only produce peer-reflexive candidates in the same situations it would do if using UDP.
11.1 states that connections should be reopened if they have dropped or been closed for some reason, and have media that needs to be sent. This might make sense in an RTP context, but seems very dubious to us in the more general TCP case as it violates the normal reliability guarantees that TCP supplies. We think this requires further thought and at the very least should be configurable.
Nigel - Thank you for your detailed feedback. As you anticipated, entering an errata is not the best path for you to begin this conversation. Instead, please send your comments to the MMUSIC working group's mail list. (See https://www.ietf.org/mailman/listinfo/mmusic).