Subject: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Jan 2018 21:42:20 -0600

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?