Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
draft-ietf-ice-rfc5245bis-20

[Ballot discuss]
Thanks to everyone who has contributed to this document over the many years of
its development.

The document currently appears to contain normative statements that, while not
literally contradictory, certainly point implementors in conflicting directions.
§5.1.1.1 says:

>  o  Host candidates corresponding to IPv6 link-local addresses MUST
>    NOT be gathered.

Further down, §6.1.2.2 says:

>  To keep the amount of resulting candidate pairs
>  reasonable and to avoid candidate pairs that are highly unlikely to
>  work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with
>  other than link-local addresses.

This second passage is nonsensical if IPv6 link local addresses MUST NOT be
gathered. Please remove or amend one of these normative statements. If the first
statement is retained, please add rationale.

(As an aside, it makes more sense to cite 4291 the first time you mention IPv6
link local address rather than the second)

[Ballot comment]
I have a number of comments on technical content, followed by some editorial
nits.

---------------------------------------------------------------------------

§5.1.1.3:

>  o  For reflexive and relayed candidates, the STUN or TURN servers
>    used to obtain them have the same IP address.

This is ambiguous: it is unclear whether "the same IP address" refers to the
address that the ICE agent used to reach the TURN server, or whether the IP
address allocated by the TURN server on the client's behalf. In large-scale
TURN deployments, these addresses will frequently differ, since one IP address
can only support ~64k ports at once (and therefore TURN servers may need to
make use of multiple at once). Please clarify which IP address is to be used for
this comparison.

>  Similarly, two candidates have different foundations if their types
>  are different, their bases have different IP addresses, the STUN or
>  TURN servers used to obtain them have different IP addresses, or
>  their transport protocols are different.

The same clarification is required to this paragraph as well.

---------------------------------------------------------------------------

§5.2:

>  This default
>  SHOULD be chosen such that it is the candidate most likely to be used
>  with a peer.  For IPv6-only hosts, this would typically be a globally
>  scoped IPv6 address.  For dual-stack hosts, the IPv4 address is
>  RECOMMENDED.


I support Suresh's DISCUSS. I would propose that you recommend that dual-stack
hosts SHOULD allow configuration of whether IPv4 or IPv6 is used for the
default, and that the configuration needs to be based on which one its
administrator believes has a higher chance of success in the current network
environment. I am of the understanding, for example, that in certain Japanese
carriers, the selection of IPv6 as the default would maximize the chance of
success, even today.

---------------------------------------------------------------------------

§5.3:

>    Related Address and Port:  The related IP address and port of the
>        candidate.  These MAY be omitted or set to invalid values if
>        the agent does not want to reveal them, e.g., for privacy
>        reasons.

The term "Related Address and Port" is not defined anywhere. Is it the same as
the base address? Something else? Please add a definition to §4. (I'll note that
this term is also used in Figure 6.) It may also be useful to call forward to
§B.3 here, so that implementors aren't confused by the apparent uselessness of
including this information.

---------------------------------------------------------------------------

§8.1.1:

>  NOTE: A controlling agent that does not support this specification
>  (i.e. it is implemented according to RFC 5245) might nominate more
>  than one candidate pair.  This was referred to as aggressive
>  nomination in RFC 5245.

Please here or elsewhere (probably Appendix B) indicate why aggressive
nomination was removed (i.e., it's redundant with the ability to send data on
any valid pair even prior to nomination).

Also (editorial nit) please put quotation marks around the term "aggressive
nomination."

---------------------------------------------------------------------------

§8.1.2:

>    *  The agent MAY begin transmitting data for this data stream as
>        described in Section 12.1.

This seems redundant with the fact that the data could be sent even before
nomination, and runs the risk that implementors might interpret it to mean that
they must not send data *prior* to nomination. I think it would be safest to
remove this, and possibly reiterate right here that sending data is not blocked
on successful pair nomination.

---------------------------------------------------------------------------

§9:

>  To restart ICE, an agent MUST change both the password and the
>  username fragment for the data stream(s) being restarted.  The agent
>  MUST verify that it has not used the new values in recent ICE
>  sessions, as packets from those sessions might still be present in
>  the network.

To be clear: the password and ufrag, taken together, provide 152 bits of
randomness, and need to be selected randomly on restart. This passage appears to
be guarding against random collisions between 152-bit values in a small set.
Do I have that correct?

If so: I couldn't find a birthday paradox calculator that could deal with
5,708,990,770,823,839,524,233,143,877,797,980,545,530,986,496 potential values.
The only one that didn't generate an error outright gave a probability of 0,
which is as close as correct as to make no difference.

Unless I'm misunderstanding what is being asked of implementors, this second
MUST is superfluous and should be removed.

---------------------------------------------------------------------------

§15:

Please either update the example to use IPv6 in addition to IPv4, or provide
an additional example that uses IPv6 addresses.  See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for guidance on the use of
IPv6 in IETF specifications, including their examples.

---------------------------------------------------------------------------

§15:

>            |              |(9) Bind Req  |              |Begin
>            |              |S=$R-PUB-1    |              |Connectivity
>            |              |D=L-PRIV-1    |              |Checks
>            |              |<----------------------------|
>            |              |Dropped      |              |

This is quite misleading. If a host on the public Internet (as R is in this
example) sent a Binding Request to $L-PRIV-1 (10.0.1.1 in this example), it
would *not* be routed to the NAT, as is shown in this example. If it didn't get
blocked before reaching the default free zone, I believe it would be blackholed
once it did so. I would propose keeping the arrow, but having it end prior to
reaching the NAT line.

(Minor nit: please replace "L-PRIV-1" with "$L-PRIV-1")

---------------------------------------------------------------------------

§15:

>  Since the check was generated in the reverse direction of a
>  check that contained the USE-CANDIDATE attribute...

It was? I don't see that in the ladder, can't find it in the prose, and believe
it to be actually incorrect. By my understanding, the example would need an
additional messages 18 through 21, originating from L (as the controlling agent)
that nominates this pair.

I believe what you've shown is an aggressive nomination call flow, but this
document no longer supports aggressive nomination.

If I'm simply confused here, then please add the "USE-CANDIDATE" attribute to
the ladder diagram and to the corresponding text where it belongs.

---------------------------------------------------------------------------

§20.1 and §20.2:

Please add instructions to IANA to update the registry to point to this document
instead of RFC 5245.


===========================================================================

All of the following are editorial nits.

> J. Rosenberg
> jdrosen.net

You might want to double-check with the author that this is the intended
affiliation for this document.

---------------------------------------------------------------------------

§1:
>  sinks.  However this poses challenges when operated through Network

"However, this..."

>  (RTCP) [RFC3605].  Unfortunately, these techniques all have pros and
>  cons which, make each one optimal in some network topologies, but a

"...cons that make..."

>  to-peer connectivity checks.  The IP addresses and ports are
>  exchanged exchanged using ICE usage-specific mechanisms (for example,

Remove duplicate "exchanged"

>  including in a offer/answer exchange) and the connectivity checks are
>  performed using Session Traversal Utilities for NAT (STUN)

"STUN" has already been expanded in this section.

>  specification [RFC5389].  ICE also makes use of Traversal Using
>  Relays around NAT (TURN) [RFC5766], an extension to STUN.  Because
>  ICE exchanges a multiplicity of IP addresses and ports for each media
>  stream, it also allows for address selection for multihomed and dual-
>  stack hosts.  For this reason RFC 5245 [RFC5245] deprecated RFC 4091

"For this reaason, RFC..."

"...deprecated the solutions previously defined in..."

---------------------------------------------------------------------------

§2:

>  Figure 1 shows a typical ICE deployment.  The agents are labelled L
>  and R.  Both L and R are behind their own respective NATs though they
>  may not be aware of it.  The type of NAT and its properties are also
>  unknown.  L and R are capable of engaging in an candidate exchange

"...in a candidate..."

>  In addition to the agents, a signaling server and NATs, ICE is

"...signaling server, and NATs,..."

---------------------------------------------------------------------------

§2.4:

>  Once ICE is concluded, it can be restarted at any time for one or all
>  of the data streams by either ICE agent.  This is done by sending an
>  updated candidate information indicating a restart.

"...sending updated..."

---------------------------------------------------------------------------

§3:

>  This document specifies generic use of ICE with protocols that
>  provide means to exchange candidate information between the ICE
>  agents.  The specific details of (i.e how to encode candidate

"...specific details (i.e., how.."

(remove "of", include period and comma after "i.e")

>  information and the actual candidate exchange process) for different
>  protocols using ICE (referred to as using protocol) are described in

'...(referred to as "using protocol")...'

>  separate usage documents.
>
>  One mechanism for agents to exchange the candidate information by
>  using [RFC3264] based Offer/Answer semantics as part of the SIP

"...information is using..."

---------------------------------------------------------------------------

§4:

>  Responding Peer, Responding Agent, Responder:  A receiving agent is

"A responding agent..."

>  Component:  A component is a piece of a data stream.  A data stream
>    may require multiple components, each of which has to work in
>    order for the data stream as a whole to work.  For RTP/RTCP data
>    streams, unless RTP and RTCP are multiplexed in the same port,
>    there are two components per data stream -- one for RTP, and one
>    for RTCP.  A component has a candidate pair, which cannot be used
>    by other components

Add a period to the end of this sentence.

>  Default Destination/Candidate:  The default destination for a
>    component of a data stream is the transport address that would be
>    used by an ICE agent that is not ICE-aware.

Users are likely to be confused by the phrase "ICE agent that is not ICE-aware."
It certainly threw me for a loop. Perhaps "...used by a peer that is not
ICE-aware" or something like that.

>  Nomination, Regular Nomination:  The process of the controlling agent
>    indicating to the controlled agent which candidate pair the ICE
>    agents will use for sending and receiving data.

With the exception of its use in §13 (which I think should be removed), the term
"Regular Nomination" (which was used to distinguish from the now-removed
aggressive nomination) does not appear in this document. I suggest it be removed
from this definition.

>  Timer HTO:  The timeout timer for a given STUN or TURN transaction.

It would be nice if the document indicated some mnemonic for "HTO" (that is:
expand or explain this acronym, please).

---------------------------------------------------------------------------

§5.1.1.1:

>  For other than RTP/RTCP streams, use of multiple components is

"For uses other than..."

>  discouraged since using them increases the complexity of ICE

"...discouraged, since..."

---------------------------------------------------------------------------

§5.3:

>  The using protocol may (or may not) need to deal with backwards
>  compatibility with older implementations that do not support ICE.  If
>  the fallback mechanism is being used...

It's not clear what "the fallback mechanism" refers to in this sentence.

---------------------------------------------------------------------------

§5.4:

>  Certain middleboxes, such as ALGs, can alter signaling information in
>  ways that break ICE.

"...break ICE (for example, by rewriting IP addresses in SDP)."

---------------------------------------------------------------------------

§6.1.1:

>  Both agents are full:  The initiating agent which started the ICE

"...agent that started..."

>  Both lite:  The initiating agent which started the ICE processing

"...agent that started..."

>  NOTE: There are certain 3PCC (third party call control) scenarios
>  where an ICE restart might cause a role conflict.

Please add an informative citation to RFC 3725.

---------------------------------------------------------------------------

§6.1.2:

>  There is one check list for each data stream.  To form a check list,
>  initiating and responding ICE agents form candidate pairs, computes
>  pair priorities, orders pairs by priority, prunes pairs, removes
>  lower-priority pairs, and sets check list states.

Please match up your number tense here. Either:

  There is one check list for each data stream.  To form a check list,
  initiating and responding ICE agents form candidate pairs, compute
  pair priorities, order pairs by priority, prune pairs, remove
  lower-priority pairs, and set check list states.

...or...

  There is one check list for each data stream.  To form a check list,
  each initiating and responding ICE agent forms candidate pairs, computes
  pair priorities, orders pairs by priority, prunes pairs, removes
  lower-priority pairs, and sets check list states.

---------------------------------------------------------------------------

§6.1.2.6:

>                      Figure 8: Initial Pair State

I think calling this a figure is quite a stretch. I was really thrown for a loop
after reading four paragraphs to find this non-sequitur label just hanging out
at the end of the section.

---------------------------------------------------------------------------

§6.1.4.2:

>  Once the agent has picked a candidate pair, for which a connectivity
>  check is to be performed, the agent performs the check by sending a

"...a candidate pair for which..."

---------------------------------------------------------------------------

§6.2:

>  Lite implementations skips most of the steps in Section 6 except for

"Lite implementations skip..."

---------------------------------------------------------------------------

§7.2.5.2.2:

  An ICE agent MAY support processing of ICMP errors for connectivity
  checks.  If the agent supports processing of ICMP errors, and if a
  Binging request generates a hard ICMP error, the agent SHOULD set the

"...Binding request..."

---------------------------------------------------------------------------

§9:

>  An ICE agent MAY restart ICE for existing data streams.  An ICE
>  restart causes all previous state of the data streams, excluding the
>  roles of the agents to be flushed.

"...excluding the roles of the agents, to be flushed."

(insert comma)

---------------------------------------------------------------------------

§12.1:

>  Once selected pairs have been produced for a data stream, an agent
>  MUST send data on those pairs.

"...on those pairs only."

---------------------------------------------------------------------------

§12.2:

>  Even though ICE agents are only allowed to send data using valid
>  candidate pairs (and, once selected pairs have been produced, only on
>  the selected pairs) ICE implementations SHOULD by default be prepared
>  to receive data on any of the candidates provided in the most recent
>  candidate exchange with the peer.  ICE usages MAY define rules that
>  differs from this, e.g., by defining that data will not be sent until

"...rules that differ..."

---------------------------------------------------------------------------

§13:

>  One of the complications in achieving interoperability is that ICE
>  relies on a distributed algorithm running on both agents to converge
>  on an agreed set of candidate pairs.  If the two agents run different
>  algorithms, it can be difficult to guarantee convergence on the same
>  candidate pairs.  The regular nomination procedure described in

There is only one nomination procedure here; this makes more sense as "The
nomination procedure described in..."

>  Section 8 eliminates some of the tight coordination by delegating the
>  selection algorithm completely to the controlling agent.
>  Consequently, when a controlling agent is communicating with a peer
>  that supports options it doesn't know about, the agent MUST run a
>  regular nomination algorithm.  When regular nomination is used, ICE

"...MUST run the nomination algorithm described in Section 8. When this
algorithm is used,..."

---------------------------------------------------------------------------

§14.2:

>  ICE agents SHOULD use the default Ta value, 50 ms, but MAY use

"ICE agents SHOULD use a default Ta value of 50 ms, but MAY use..."
                      ^                  ^^

>    1.  Let MaxBytes be the maximum number of bytes allowed to be
>        outstanding in the network at start-up, which SHOULD be 14600
>        bytes per RFC 6928.

Please add a citation to RFC 6928 (rather than just mentioning its RFC number).

---------------------------------------------------------------------------

§14.3:

>    RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))

I can't tell whether the "*N" in "Ta*N" is a typo, or if the document simply
doesn't define the meaning of "N" anywhere. Please either fix the formula, or
add a description of the meaning of "N."

---------------------------------------------------------------------------

§16.1:

>  This specification defines four new STUN attributes, PRIORITY, USE-
>  CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.

"...new STUN attributes: PRIORITY, ..."

---------------------------------------------------------------------------

§17.1:

>  Consequently, it is not necessary to replace or reconfigure existing
>  firewall and NAT equipment in order to facilitate deployment of ICE.
>  Indeed, ICE was developed to be deployed in environments where the
>  Voice over IP (VoIP) operator has no control over the IP network
>  infrastructure, including firewalls and NAT.

"...and NATs."

>  That said, ICE works best in environments where the NAT devices are
>  "behave" compliant, meeting the recommendations defined in [RFC4787]
>  and [RFC5382].  In networks with behave-compliant NAT, ICE will work

"...behave-compliant NATs, ..."

---------------------------------------------------------------------------

§17.2.1:

>  First and foremost, ICE makes use of TURN and STUN servers, which
>  would typically be located in the data centers.

"...in data centers."


---------------------------------------------------------------------------

§17.3:

>  Deployments utilizing a mix of ICE and ICE-lite interoperate
>  perfectly.  They have been explicitly designed to do so.

"Perfectly" seems a bit hubristic. Perhaps "...interoperate with each other."


---------------------------------------------------------------------------

§18:

>  The IAB has studied the problem of "Unilateral Self-Address Fixing",

Since you use the "UNSAF" acronym further down, please use this opportunity to
expand it.

>  and the difference has a significant impact on the issues raised by
>  IAB.  Indeed, ICE can be considered a B-SAF (Bilateral Self-Address

"...raised by the IAB."

---------------------------------------------------------------------------

§18.2

>  less, and can eventually be remove when their usage goes to zero.

"...be removed..."

---------------------------------------------------------------------------

§19:

The text in the top-level "Security Considerations" section is its own topic,
similar to those found in Section 19's subsections. Please give it its own title
(e.g., "19.1.  IP Address Privacy")

---------------------------------------------------------------------------

§19.1:

>  UDP header of the message triggering the error.  These fields also
>  needs to be validated.  The IP destination and UDP destination port

"...need..."

>  needs to match either the targeted candidate address and port, or the

"...need..."

>  candidates base address.  The source IP address and port can be any

"...candidate's..."

---------------------------------------------------------------------------

§19.4:

>  In addition to attacks where the attacker is a third party trying to
>  insert fake candidate information or stun messages, there are attacks

"...STUN..."

---------------------------------------------------------------------------

§20.3:

>      The ICE option indicates that the ICE agent using the ICE option
>      is compliant and implemented according to RFC XXXX.

Suggest removing "compliant and" from this.

---------------------------------------------------------------------------

§21:

>  o  Make technical changes, due to discovered flows in RFC 5245 and

"...discovered flaws..."

---------------------------------------------------------------------------

§22

>  Harald Alvestrand and Roman Shpount.  Ben Campbill did the AD review.

"Ben Campbell"

---------------------------------------------------------------------------

§B.1:

>  rate at which they will create new bindings.  Experiments have shown

I agree with EKR that a citation to these experiments is called for.

>  that once every 5 ms is well supported.  This is why Ta has a lower

"...well-supported..."

---------------------------------------------------------------------------

§B.8:

>  Additionally, using a Binding Indication allows integrity to be
>  disabled, allowing for better performance.  This is useful for large-
>  scale endpoints, such as PSTN gateways and SBCs.

Expand "PSTN" and "SBC".

[Ballot discuss]
* Section 5.2.  Lite Implementation Procedures

"For dual-stack hosts, the IPv4 address is RECOMMENDED."

I am trying to understand the reasoning behind this unequivocal choice (which probably might have made sense in 2010). At least, there is some explanatory text required to justify this.

[Ballot comment]
Review in context at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3312

IMPORTANT:

*  If the agent's tie-breaker value is larger than or equal to the
        contents of the ICE-CONTROLLING attribute, the agent generates
IMPORTANT: This algorithm seems like it's not going to work properly.
Consider the case where A and B happen to have the same tie-breaker
and both think they are controlling, and the Binding Requests
cross. Each now sends a 487 and then they switch to
controlled. Ugh. Unless I'm missing something, if the tie-breakers
match, you are stuck. Given that the chance is 2^{-64} this seems
to not be a critical failing, but the algorithm still seems wrong.


REST:
  single solution that is flexible enough to work well in all
  situations.
This section seems pretty dated. Aren't ICE and ICE-style solutions pretty much the de facto standard now.



  may not be aware of it.  The type of NAT and its properties are also
  unknown.  L and R are capable of engaging in an candidate exchange
  process, whose purpose is to set up a data session between L and R.
Nit: a candidate exchange. This appears to be a result of changing offer/answer (where "an" was appropriate) to "candidate"



  At least one viable candidate has a transport address obtained
  directly from a local interface.  Such a candidate is called a host
Nit: this is awkward. Perhaps "The first category of candidates are those with a transport ..."



  When the agent sends the TURN Allocate request from IP address and
  port X:x, the NAT (assuming there is one) will create a binding
Nit: "a TURN Allocate"



  the next candidate pair on the list periodically.  These are called
  ordinary checks.  When a STUN transaction succeeds, one or more
  candidate pairs will become so called valid pairs, and will be added
Nit: I would quote "ordinary check" here and "triggered check" below.



  provide means to exchange candidate information between the ICE
  agents.  The specific details of (i.e how to encode candidate
  information and the actual candidate exchange process) for different
Nit: i.e -> i.e.,



  Nomination, Regular Nomination:  The process of the controlling agent
      indicating to the controlled agent which candidate pair the ICE
Given that you have removed Aggressive Nomination, do you still need to refer to "Regular Nomination"



  candidate gathering, (2) candidate prioritization, (3) redundant
  candidate elimination, and (4) sending of the candidates to the peer.
This is an odd diagram. There's no reason why these have to happen in sequence and in fact in Trickle ICE, they don't, so this diagram seems misleading., as well as potentially contradicting the beginning of S 5.1.1.

"An ICE agent gathers candidates when it believes that communication is imminent. "



  When candidates are obtained, unless the agent knows for sure that
  RTP/RTCP multiplexing will be used (i.e. the agent knows that the
  other agent also supports, and is willing to use, RTP/RTCP
Nit: "i.e.,"



      addresses that do allow location tracking, that are configured on
      the same interface, and are part of the same network prefix MUST
      NOT be gathered.
You need to remove both of these commas, because they indicate a nonrestrictive clause, but this is a restrictive clause.



  The gathering process is controlled using a timer, Ta.  Every time Ta
  expires, the agent can generate another new STUN or TURN transaction.
No comma here.



  The agent will receive a Binding or Allocate response.  A successful
  Allocate response will provide the agent with a server reflexive
Or nothing or an error.



              (2^8)*(IP precedence) +
              (2^0)*(256 - component ID)
Isn't this the same formula as in S 5.1.2.1.



      Foundation:  A sequence of up to 32 characters.
The Foundation is never transmitted, AFAIK. So why does it have to be up to 32 characters? It certainly wasn't exchanged in 5245.



  data stream, and for updating the peer with the ICE's selection, when
  needed.  The controlled agent is told which candidate pairs to use
  for each data stream, and does not require updating the peer to
Told by who?



  pair priorities, orders pairs by priority, prunes pairs, removes
  lower-priority pairs, and sets check list states.  If candidates are
  added to a check list (e.g, due to detection of peer reflexive
Please fix your subject verb agreement here.



      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
This was kinda terrible in 5245. Given that you use it once, maybe just have

+ GT(G, D)

And then say GT(G, D) == 1 if G>D and 0 otherwwise.



                      Figure 8: Initial Pair State
This figure caption is kind of a mess. I suggest just removing it.



  state in the check list set has been processed, the first check list
  is picked again.  Etc.
Nit: "again, etc."



  pair to the remote candidate of the pair, as described in
  Section 7.2.4.
IMPORTANT: You don't just send a STUN request, you start a STUN transaction,


  lists.  On the other hand the responding agent either performs the
  triggered or ordinary checks as described above.
I don't understand this paragraph. What distinction are you trying to draw.



  o  The base is local candidate of the candidate pair from which the
      Binding request was sent.
Nit: "is the local"



  The ICE agent constructs a candidate pair whose local candidate
  equals the mapped address of the response, and whose remote candidate
IMPORTANT: When does this happen?


  a different check list than the one to which the pair that generated
  the connectivity checks), or it may be a pair not currently in any
  check list.
IMPORTANT: How would a valid pair be on some other check list?


      this specification.  There may be a conflict, but it cannot be
      detected.
What previous version? This was required in 5245. Maybe at this point we can just deprecate this?






7.3.1.3.  Learning Peer Reflexive Candidates
This entire section seems to duplicate 7.2.5.3.1



        in-progress transaction.  Cancellation means that the agent
        will not retransmit the request, will not treat the lack of
        response to be a failure, but will wait the duration of the
Why are you cancelling In-Progress checks when you receive a peer-reflective check? If you receive two in a row, then it seems like this delays a successful check. More generally, this document should explain how you end up in this situation: you only get here when "the source transport address of the request does not match any existing remote candidate", so how can it be on a check list unless this is the second observation of a peer reflexive.



  Prior to nominating, the controlling agent let connectivity checks
  continue until some stopping criterion is met.  After that, based on
lets.



  The criterion details for stopping the connectivity checks and for
  selecting a pair for nomination, are outside the scope of this
"criterion details" seems ungrammatical. 5245 had "criteria". What's wrong with that?



  have ceased using a given local candidate (a candidate may be used by
  multiple ICE sessions, e.g. in forking scenarios), the agent can free
  that candidate.  The three-second delay handles cases when aggressive
Nit: "e.g.,"



  Session Description Protocol (SDP) [RFC4566] is defined in
  [I-D.ietf-mmusic-ice-sip-sdp].
Presumably you want to cite 5245 S 14, which states:

Consequently, when a controlling agent is communicating with a peer
that supports options it doesn't know about, the agent MUST run a
regular nomination algorithm.  When regular nomination is used, ICE
will converge perfectly even when both agents use different pair
prioritization algorithms.


  15 seconds.  Agents MAY use a bigger value, but MUST NOT use a value
  smaller than 15 seconds.
This is a very old number. Is it supported by an modern measurement?



  will converge perfectly even when both agents use different pair
  prioritization algorithms.  One of the keys to such convergence is
  triggered checks, which ensure that the nominated pair is validated
Given that you have removes aggressive, you presumably want to revise this section



16.  STUN Extensions
None of the stuff here is "New" any longer, as it was allocated in RFC 5245.



  First and foremost, ICE makes use of TURN and STUN servers, which
  would typically be located in the data centers.  The STUN servers
  require relatively little bandwidth.  For each component of each data
Nit: this used to read "the network operators data centers" and when you removed "network operators" this became ungrammatical



  there will be four transactions per call (one for RTP and one for
  RTCP, for both caller and callee).  Each transaction is a single
  request and a single response, the former being 20 bytes long, and
Is this currently true? How many people still don't support RTP-MUX?



  can and will vary over time.  In a network with 100% behave-compliant
  NAT, it is exactly zero.  At time of writing, large-scale consumer
  deployments were seeing between 5 and 10 percent of calls requiring
This text dates to 5245. Is that still true?



  something incorrect about the results of the connectivity checks.
  The possible false conclusions an attacker can try and cause are:
IMPORTANT: This section would be a lot stronger if it was factored by attacker capabilities as well. As-is it is very hard to understand.


  possible attack.  Fortunately, this attack is mitigated completely
  through the STUN short-term credential mechanism.  The attacker needs
  to inject a fake response, and in order for this response to be
This text is a bit confusing. If you can generate a drop, then you can mount this attack.



  invalid attack, this attack is mitigated by the STUN short-term
  credential mechanism in conjunction with a secure candidate exchange.
This also isn't quite correct. Consider the case where A is behind a filtering element (e.g., a firewall) and shares a broadcast network with the attacker. The attacker then captures an outgoing message that would have been filtered and tunnels it to B, and then tunnels the response back. This can cause B and A to think they have a valid path when they do not. It seems like this attack is described several paragraphs down, but in sort of a confusing way.



19.4.1.  STUN Amplification Attack
It's probably worth noting that this form of attack is a lot worse when WebRTC is involved.



  rate at which they will create new bindings.  Experiments have shown
  that once every 5 ms is well supported.  This is why Ta has a lower
  bound of 5 ms.  Furthermore, transmission of these packets on the
Citation needed.

[Ballot comment]
Important nits; please address:

1) Sec 14.2: RFC 6928, RFC 5389, and RFC 6298 should be actual references and listed in the reference section.

2) Sec 14.2: Maybe you should really not use normative language in the reasoning part of this section?!
    I find especially this SHOULD in the following sentence confusing (as it doesn't give a reference to another RFC that defines this):
  "Let MinPacing be the minimum pacing interval between
          transactions, which SHOULD be 5ms."
  Given that the previous text says:
  "all transactions from all agents [...] MUST NOT be sent more often than once
  every 5ms"
  My recommendation: please use lower cases "shoulds" and "musts" in the reasoning part!

3) Sec 19.4.1: "(say, Ta=20ms)"
Maybe use also a value of 50ms here to avoid confusion.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ice-rfc5245bis-16. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that upon approval of this document, there are two actions which we must complete.

First, in the STUN Attributes registry and the STUN Error Codes registry, both located on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at:

https://www.iana.org/assignments/stun-parameters/

IANA has previously registered four STUN attributes:

0x0024 PRIORITY
0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED
0x802A ICE-CONTROLLING

and has previously registered one STUN error response code:

487 Role Conflict: The client asserted an ICE role (controlling or
controlled) that is in conflict with the role of the server.

For each of these five registrations the existing reference will be changed to [ RFC-to-be ].

IANA Question --> Can you confirm that all references to RFC5245 should be replaced by the new [ RFC-to-be ]?

Second, in the ICE Options registry located on the Interactive Connectivity Establishment (ICE) registry page located at:

https://www.iana.org/assignments/ice/

a single new registration will be made:

Name: ice2
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review should be completed before your document can be approved for publication as an RFC. However, this registry does not yet have a designated expert. We've submitted a management item to the IESG requesting expert designation.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

Peter Thatcher is the document shepherd.  Ben Campbell is the Area Director.  The intent of the document is to "describe a protocol for Network Address Translator (NAT) traversal for UDP-based communication".  The working group has chosen a Proposed Standard because this document obsoletes a previous Proposed Standard.

The document was discussed and reviewed very actively for many years by many parties.  There is much interest in the community because there are many documents which depend on this document, especially in the RTCWEB work, and because there are many deployed implementations of the existing Proposed Standard (RFC 5245).  Notable discussions include the decisions of the "Ta" value (how frequently packets are sent), backwards compatibility with RFC 5245 endpoints, removal of "aggressive nomination", generalization of ICE to more than just RTP/RTCP, and generalization of ICE signaling to more than just SDP offer/answer.  There was a long-term, lively discussion with a large number of folks followed by thorough review by a smaller number of very interested folks.  Consensus was usually not quick, but was broad when finally reached.  One particular point of controversy waws around the Ta value and packet pacing, which required significant experimentation by working members in the real world and participation from many other working groups, especially from the transport area.  This point was resolved by finding a technical solution that all groups were happy with and which seemed to work well in real world experimentation.  Reviews on specific areas (such as the Ta value) were done by folks in the transport area.  Other reviews were done by members of other working groups (such as RTCWEB and MMUSIC).  The reviews were extensive and no further review is necessary.  The document shepherd has no specific concerns or issues with the document.  There are many RFC 5245 implementations and at least some of those (especially RTCWEB implementations) are already being updated. 

It is confirmed that each author has stated their direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

The list and authors were asked to disclose any IPR, after which one item was disclosed.  All other feedback was that there was no other known IPR related to this document.

There is one downward reference to RFC6928.  There is one IANA Consideration, a new registration, but no new registry.  There is no known significant discontent with the document or the process, which might result in appeals to the IESG or especially bad feelings in the working group.

The following Last Call announcement was sent out (ends 2018-01-26):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, ice-chairs@ietf.org, ice@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org, pthatcher@google.com, Peter Thatcher
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal) to Proposed Standard


The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document: - 'Interactive
Connectivity Establishment (ICE): A Protocol for Network
  Address Translator (NAT) Traversal'
  as 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 2018-01-26. 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


  This document describes a protocol for Network Address Translator
  (NAT) traversal for UDP-based communication.  This protocol is called
  Interactive Connectivity Establishment (ICE).  ICE makes use of the
  Session Traversal Utilities for NAT (STUN) protocol and its
  extension, Traversal Using Relay NAT (TURN).

  This document obsoletes RFC 5245.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ballot/

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

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



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6928: Increasing TCP's Initial Window (Experimental - IETF stream)

Hi,

This is my AD Evaluation of draft-ietf-ice-rfc5245bis-15. Most of my comments are editorial, but there are enough of them I think we will need another revision prior to IETF LC.

I recognize some of my comments address text that did not change from 5245. I tried to minimize that, but this is enough of a rewrite that it’s hard to completely isolate just the updated text. I suspect that last call reviewers and members of the IESG will also find that hard in places.)

Thanks!

Ben.
————————

Substantive Comments:

- 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs over a path with more NATs, or is it more a matter of selecting a path with no NATs over a path with “some” NATs? (If the former, how does it figure out how many NATs are between an agent and it’s servers and peers? Is this just a matter of timing?)

- 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you envision circumstances where it might make sense _not_ to set the state to Failed?

-17, first paragraph: “ If these
  potential attacks can not be mitigated, the implementation may want
  to institute controls for which addresses are revealed to the
  negotiation and/or probing process.  Such controls need to be
  specified as part of the ICE usage.”

This seems ambiguous. Is it the implementation’s decision to institute such controls, or is each ICE usage spec expected to make a decision that applies to all implementations of that usage?

Should “secure signaling techniques” distinguish between HBH and E2E techniques, in light of the later discussion about insider attacks?

-17,1, false peer reflexive candidate: Should this mention SRTP (or DTLS-SRTP)  as a mitigating countermeasure?


Editorial Comments and Nits:

Is there a reason that the Security Considerations and IANA considerations are not in the conventional locations (i.e. the last two sections before the references)? (I see that is also true in 5245, so this is mostly curiosity.)

-1, last paragraph: Would it make sense to change “exchanged via mechanisms” (which seems a tautology) to “exchanged via various mechanisms”,  “exchanged by application-specific mechanisms”, or something similar?

— Didn't 5245 already deprecate RFC 4091 and 4092? That is, _this_ document does not do that.

-2.1, first paragraph: "Naturally, one viable candidate has a transport address obtained directly from a
  local interface”

Shouldn’t that say “one or more viable candidates have….”? or “At least one…”?

-2.1, 4th paragraph from end: It would be helpful to describe what “valid pair” means earlier in the document.

-2.3, figure 4: The figure still says “flag”, while the text has been changed in several place to speak of the nominated “attribute”. Please use one or the other consistently.

-4: There are at least a few uses of lower case “must” and “should” that do not appear to have been intended as keywords. If that is the intent, please update this to use the boilerplate from 8174.  (The 2119 boilerplate is ambiguous on whether lower case instances count as keywords.)

s/“… defined in the STUN…” / “… defined in STUN… “ or “… defined in the STUN protocol …”

-5, last paragraph: The figure does not actually mention “default candidate selection”.

-5.1.1, last paragraph, last sentence: Is the MAY applicable just to the responding agent, or both agents?

-5.1.1.2, first paragraph : “Those requirements are at SHOULD strength…”
I suggest putting “SHOULD” in quotes when talking about a requirement stated elsewhere. (Even if that “elsewhere” is in the same sentence :-)  )

-5.1.1.3, first paragraph: "Two candidates MUST have the same foundation when all of the following are true”
That seems like a statement of fact. (Same for the last paragraph talking about different foundations.)

- 5.1.2.1: Missing article before “IP Address for which the candidate…”
(This section also seems to have a lot of 2119 keywords that are really statements of fact or definition. But I recognize those come from the original 5245 text.)

-6.1.2, 2nd sentence: “ To form a check list, an ICE agent (initiating and responding) forms candidate pairs"
Consider : “To form check lists, initiating and responding ICE agents form candidate pairs…”

-7.2.5.2.1: “MUST be equal the destination IP address”

Consider “MUST equal” or “MUST be equal to”

-12.3: “ As discussed below, ICE agents are encouraged to re-adjust jitter buffers…”
Please cite the specific section(s).

- 17, last 3 paragraphs: With the expansion of the security considerations, this list does not include all the countermeasures mentioned in the later sections.

-17.2, last bullet: Why call out viruses specifically? It seems like there are a lot of ways a server might be compromised that do not involve viruses per se. (Same in 17.3).

-17.4.1: Since the description of the voice hammer attack has been removed, can you cite something that does describe it? (Appendix A still refers to section 17 to describe the voice hammer attack.)

-17.4.1, 2nd paragraph: s/they’ll/“they will”

-22: Did you consider making this section an appendix?

Peter Thatcher is the document shepherd.  Ben Campbell is the Area Director.  The intent of the document is to "describe a protocol for Network Address Translator (NAT) traversal for UDP-based communication".  The working group has chosen a Proposed Standard because this document obsoletes a previous Proposed Standard.

The document was discussed and reviewed very actively for many years by many parties.  There is much interest in the community because there are many documents which depend on this document, especially in the RTCWEB work, and because there are many deployed implementations of the existing Proposed Standard (RFC 5245).  Notable discussions include the decisions of the "Ta" value (how frequently packets are sent), backwards compatibility with RFC 5245 endpoints, removal of "aggressive nomination", generalization of ICE to more than just RTP/RTCP, and generalization of ICE signaling to more than just SDP offer/answer.  There was a long-term, lively discussion with a large number of folks followed by thorough review by a smaller number of very interested folks.  Consensus was usually not quick, but was broad when finally reached.  One particular point of controversy waws around the Ta value and packet pacing, which required significant experimentation by working members in the real world and participation from many other working groups, especially from the transport area.  This point was resolved by finding a technical solution that all groups were happy with and which seemed to work well in real world experimentation.  Reviews on specific areas (such as the Ta value) were done by folks in the transport area.  Other reviews were done by members of other working groups (such as RTCWEB and MMUSIC).  The reviews were extensive and no further review is necessary.  The document shepherd has no specific concerns or issues with the document.  There are many RFC 5245 implementations and at least some of those (especially RTCWEB implementations) are already being updated. 

It is confirmed that each author has stated their direct, personal knowledge that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

The list and authors were asked to disclose any IPR, after which one item was disclosed.  All other feedback was that there was no other known IPR related to this document.

There are no downward references.  There is one IANA Consideration, a new registration, but no new registry.  There is no known significant discontent with the document or the process, which might result in appeals to the IESG or especially bad feelings in the working group.