TCP Candidates with Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-tcp-16

[Ballot discuss]
Based on the response from the authors to the Gen-ART Review by
  Vijay Gurbani on 31-Oct-2011, I am expecting to see updates for
  Section 1 and Section 4.1.

[Ballot comment]
- on page 3, 2nd last para where it talks about "one of the
agents" it might be clearer to say "one of the agents (the
offerer)"

- lack of ICE-clue means I didn't get the last para of
p5; probably just me but maybe take a look and see if you
can make it easier on the ICE-impaired?

- the last para of section 3 was unexpected - would it be better
elsewhere? Such as after initial offers are explained?

- in 4.1 would s/highly receommended/highly RECOMMENDED/ be better
2119-wise?

- 4.1 last para, be good to reference the section of whatever RFC
defines Ta (5245 section 16 I guess)  - when I searched RFC 5389 I
didn't find the string " Ta " which confused me.

- end of 4.3 talks about a "passive" attribute value but the
ABNF in 4.5 uses abbreviations "act", "pass" and "so." Why
the inconsistency? "Pass" might also be confusing (e.g. vs.
"fail"). Maybe saving those few bytes isn't worth it?

- 5.2: "Server reflexive active candidates can be derived from
passive or S-O candidates by using the same IP address as a
passive or S-O server reflexive candidate from the same interface
has." Seems like a broken sentence.

- 7.2 Is "on the base of any TCP candidate" going to be clear
to readers? Its not that clear to me but then I'm not familiar
with ICE really, so it might just be me.

- I guess I wonder how common STUN shared secrets are in the
wild. Is this really a practical mitigation? Would it make
sense to note this and to say that appication layer security
ought be used since its unlikely one can really ensure that
there is no bad actor involved if using ICE? (This isn't a
DISCUSS on the basis, that you're probably hosed or don't
care without that application layer security but I guess a
lot of media applications understand this nowadays.)

- Section 12 typo: s/Same considerations apply/The same
considerations apply/

[Ballot comment]
Please initiate an activity to write a new separate RFC on the following issue so that it can update both the TCP and UDP versions:

"I would like to understand better how this specification takes into account the rules specified in RFC 3484 (and follow-ups). RFC 5245 does point to that spec, but only in the context of dual stack behavior. There are other important considerations as well even when considering plain old IPv6 alone, such as link local vs. ULA vs. global addressing. Some of the choices here may have a fundamental impact on whether the communications succeed. As an example, some services may only be on for link local communications for security purposes; the same scheme for ULAs was proposed by Cisco, Microsoft, and Apple engineers in recent homenet discussions. I'm not necessarily suggesting that draft-ietf-mmusic-ice-tcp is the place where this is specified or that a reference to RFC 3484 is the solve-it-all answer. I'm kind of hoping that this is already specified somewhere. If not, please consider specifying something about this, with a reference or some other explanation that helps the devices make the right decisions in these complex scenarios."

But thank you fow writing this document. It is a complex topic but the document was quite easy to read.

[Ballot discuss]
I would like to understand better how this specification takes into account the rules specified in RFC 3484 (and follow-ups). RFC 5245 does point to that spec, but only in the context of dual stack behavior. There are other important considerations as well even when considering plain old IPv6 alone, such as link local vs. ULA vs. global addressing. Some of the choices here may have a fundamental impact on whether the communications succeed. As an example, some services may only be on for link local communications for security purposes; the same scheme for ULAs was proposed by Cisco, Microsoft, and Apple engineers in recent homenet discussions. I'm not necessarily suggesting that draft-ietf-mmusic-ice-tcp is the place where this is specified or that a reference to RFC 3484 is the solve-it-all answer. I'm kind of hoping that this is already specified somewhere. If not, please consider specifying something about this, with a reference or some other explanation that helps the devices make the right decisions in these complex scenarios.

[Ballot comment]
Section 1

  However, ICE only defines procedures for UDP-based
  transport protocols.

I think "UDP-based transport protocols" is wrong snce UDP *is* a
transport protocol. 5245 talks about "UDP-based media streams" and
"UDP".

[Ballot discuss]
Based on the response from the authors to the Gen-ART Review by
  Vijay Gurbani on 31-Oct-2011, I am expecting to see updates for
  Section 1 and Section 4.1.

[Ballot comment]
Are you sure we can't get consent to publish this without the pre5378 boilerplate?

On page 17, the sentence "STUN is never run within the TLS or DTLS-SRTP session." is too strong. STUN may not occur within those sessions because of ICE, but some application that's using that candidate later may have a reason to run STUN there. I suggest adding "as part of the ICE procedures" to the end of that sentence.

[Ballot comment]
- on page 3, 2nd last para where it talks about "one of the
agents" it might be clearer to say "one of the agents (the
offerer)"

- lack of ICE-clue means I didn't get the last para of
p5; probably just me but maybe take a look and see if you
can make it easier on the ICE-impaired?

- the last para of section 3 was unexpected - would it be better
elsewhere? Such as after initial offers are explained?

- in 4.1 would s/highly receommended/highly RECOMMENDED/ be better
2119-wise?

- 4.1 last para, be good to reference the section of whatever RFC
defines Ta (5245 section 16 I guess)  - when I searched RFC 5389 I
didn't find the string " Ta " which confused me.

- end of 4.3 talks about a "passive" attribute value but the
ABNF in 4.5 uses abbreviations "act", "pass" and "so." Why
the inconsistency? "Pass" might also be confusing (e.g. vs.
"fail"). Maybe saving those few bytes isn't worth it?

- 5.2: "Server reflexive active candidates can be derived from
passive or S-O candidates by using the same IP address as a
passive or S-O server reflexive candidate from the same interface
has." Seems like a broken sentence.

- 7.2 Is "on the base of any TCP candidate" going to be clear
to readers? Its not that clear to me but then I'm not familiar
with ICE really, so it might just be me.

- I guess I wonder how common STUN shared secrets are in the
wild. Is this really a practical mitigation? Would it make
sense to note this and to say that appication layer security
ought be used since its unlikely one can really ensure that
there is no bad actor involved if using ICE? (This isn't a
DISCUSS on the basis, that you're probably hosed or don't
care without that application layer security but I guess a
lot of media applications understand this nowadays.)

- Section 12 typo: s/Same considerations apply/The same
considerations apply/

[Ballot discuss]
Why is it that "RTP over TLS MUST NOT be used" (end of p10)
and why is this specification dictating that to other
specifications that might want to make use of ICE? There may be
good reasons for that but they're not explained and a) I wonder:-)
and b) dictating what other specs using this one can and cannot do
seems like it might be a bit wrong.

I guess the obvious change could be to explain why this MUST
NOT needs to be present, or to remove it, depending.

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

IANA will create a new registry, called the "Interactive Connectivity
Establishment (ICE) Transport Extensions"

This new registry will be located in:

http://www.iana.org/assignments/ice-options/ice-options.xml

Future assignments and changes to the new registry will be done through
IETF Review or IESG Approval as defined by RFC 5245.

Each assignment in the registry consists of an extension token and a
reference.

The registry will have the following initial registration:

Token Reference
----- ----------------------------------
TCP [ RFC-to-be ] Section 4.5

IANA understands that this is the only action required to be completed
upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TCP Candidates with Interactive Connectivity Establishment (ICE)) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'TCP Candidates with Interactive Connectivity Establishment (ICE)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Interactive Connectivity Establishment (ICE) defines a mechanism for
  NAT traversal for multimedia communication protocols based on the
  offer/answer model of session negotiation.  ICE works by providing a
  set of candidate transport addresses for each media stream, which are
  then validated with peer-to-peer connectivity checks based on Session
  Traversal Utilities for NAT (STUN).  ICE provides a general framework
  for describing candidates, but only defines UDP-based transport
  protocols.  This specification extends ICE to TCP-based media,
  including the ability to offer a mix of TCP and UDP-based candidates
  for a single stream.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/798/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?


Flemming Andreasen is the Document Shephard. I have reviewed this
version of the document and believe it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had good review in the WG, including from people with
key expertise in NAT traversal active in other WGs.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document identifies a TCP amplification attack and a suggested
remedy against it. Additional security review of this particular attack
and ways of mitigating it would be helpful.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns or issues with the document. An IPR
disclosure has been filed against ice-tcp in:

https://datatracker.ietf.org/ipr/798/

The disclosure was made to the MMUSIC mailing list and led to the
observation that there are IPR disclosures against the base ICE
mechanism as well:

https://datatracker.ietf.org/ipr/799/

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=838
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=839
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=840

The above disclosures have been made to the MMUSIC list. A clarification
question was posted regarding the last three.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus on the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There are no such issues.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist

and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have verfied that the document satisfies all ID nits. The idnits tool
warns against use of private IPv4 addresses in examples, however the
usage is correct.

Btw, the ID checklist at http://www.ietf.org/id-info/checklist.html
appears to be out of date with respect to required sections and
references for IPR and Copyright Notices.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split and there are no issues with the normative
references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

IANA Considerations are present and satisfies the above. There is no
designated expert required.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

ABNF fragments have been verified to the extent possible.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

Technical Summary

Interactive Connectivity Establishment (ICE) defines a mechanism for

NAT traversal for multimedia communication protocols based on the

offer/answer model of session negotiation. ICE works by providing a

set of candidate transport addresses for each media stream, which are

then validated with peer-to-peer connectivity checks based on Session

Traversal Utilities for NAT (STUN). ICE provides a general framework

for describing candidates, but only defines UDP-based transport

protocols. This specification extends ICE to TCP-based media,

including the ability to offer a mix of TCP and UDP-based candidates

for a single stream.

Working Group Summary

This document is a product of the MMUSIC WG. The document has been in
progress for a while with significant Working Group interest,
contribution and review. There are no controversial issues.

Document Quality

The document has received significant review and the quality is good.
The chairs are aware of multiple implementations of the mechanism.