[Technical Errata Reported] RFC6544 (3231)

The following errata report has been submitted for RFC6544,
"TCP Candidates with Interactive Connectivity Establishment (ICE)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6544&eid=3231

--------------------------------------
Type: Technical
Reported by: Nigel Pattinson <nigel.pattinson <at> kaseya.com>

Section: 4 - 11

Original Text
-------------

Corrected Text
--------------

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

4.1.1.4 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 w
 e 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 specific
 ation 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 treat
 ing 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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6544 (draft-ietf-mmusic-ice-tcp-16)
--------------------------------------
Title               : TCP Candidates with Interactive Connectivity Establishment (ICE)
Publication Date    : March 2012
Author(s)           : J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG