Skip to main content

Last Call Review of draft-ietf-mif-happy-eyeballs-extension-09
review-ietf-mif-happy-eyeballs-extension-09-secdir-lc-eastlake-2016-09-01-00

Request Review of draft-ietf-mif-happy-eyeballs-extension
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-09-08
Requested 2016-08-19
Authors Gang Chen , Carl Williams , Dan Wing , Andrew Yourtchenko
I-D last updated 2016-09-01
Completed reviews Secdir Last Call review of -09 by Donald E. Eastlake 3rd (diff)
Intdir Early review of -09 by Ralph Droms (diff)
Intdir Early review of -09 by Jouni Korhonen (diff)
Opsdir Last Call review of -09 by Nevil Brownlee (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-mif-happy-eyeballs-extension by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 11)
Result Has issues
Completed 2016-09-01
review-ietf-mif-happy-eyeballs-extension-09-secdir-lc-eastlake-2016-09-01-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The goal of this Informational draft is to suggest extensions of Happy Eyeballs
(RFC 6555), originally targeted at IP protocol decisions in the a dual stack
environment, to the more general case of multiple provisioning domains. The
result is referred to as HE-MIF (Happy Eyeballs - Multiple Interfaces).

From a security point of view, I believe this document needs a bit more in the
Security Considerations section to be ready for publication. From a general
text point of view, it would benefit from an English language review (see
Editorials below).

Security:

The current Security Considerations section is the following sentence "

The security consideration is following the statement in [

RFC6555

]

and [

RFC6418

]."

 Having read the Security Considerations in those RFCs, I would say they are
 close to covering what should be mentioned in this document but there are two
 additional points that I think should be covered: (1) The dependence of the
 Happy Eyeballs interface and IP version choice on the results of generally
 unsecured connection attempts means that the interface and IP protocol used
 could be steered by an adversaries interference with such attempts. (2) To the
 extent that DNS query results affect HE-MIF decisions, DNSSEC should be used
 when available.

I would also re-write the existing Securities Considerations sentence to be
something more like: "For security considerations related to Happy Eyeballs,
see [RFC6555]. For Security Considerations related to multiple provisioning
domains, see [RFC6418]."

Editorial:

Section 1, 2nd sentence: "a issue" -> "an issue"

Section 1, 2nd paragraph: Shouldn't some of these sentences that are questions
end in a question mark?

Section 1, 3rd paragraph: "

defined in

[

RFC6555

] necessary" -> "

defined in

[

RFC6555

] that are necessary"

Section 3: "

scenarios the HE-MIF targeted to use" -> "

scenarios targeted by

HE-MIF

"

Section 4, 1st sentence: "

This section provides input parameter proposal that HE-MIF should

catch." -> "This section describes the recommended input parameters to the
HE-MIF decision process."

Section 5, last sentence of the 2nd paragraph: "

to proceed

the sort process." probably -> "on which to sort"

Section 5.1: "

mergence" -> "the merger"

     "

worth to note" -> "worthwhile to note" or "notable"

Section 5.2.3, 1st paragraph: "

receive certain next hop

 in a RA message" First of all, should be "an RA". But next hop what? You could
 replace "next hop" with "next hop information" but that is a bit vague. If
 this means "receive the next hop address in an RA message", say that.

Section 5.2.3, 2nd paragraph, 1st sentence: "

When destination and source pairs are identified, it should be

 treated with higher priority compared to others and choose to

 initiate the connection in advance." does not really make sense. Probably
 should say something like "When destination and source pairs are identified, a
 connection should be initiated only to the highest priority pair or pairs."

Section 5.2.3, last paragraph: "

would initiate" -> "would be initiated"

     "

most fast" -> "fastest" or possible "most expeditious"

Section 7.2, 1st paragraph: "

in replied ICMP" -> "in an ICMP reply"

Section 7.2, 2nd paragraph: "

More optimal timer may be expected." -> "A more optimal timer for the
circumstances is desirable."

     "

The memo didn't" -> "

This memo doesn't"

Section 7.2, 1st bullet item: "

compensate the issues" -> "compensate for this issue"

     "

it leaves a" -> "this is left to a"

Section 7.2, 2nd bullet item: "

in the principle of" -> "based on"

Section 7.3, 2nd bullet item: "

cause messy" -> "cause confusion"

Other editorial:

Replace "WiFi" by "Wi-Fi" throughout.

"

out of the

document scope" -> "out of this document's scope" or "beyond the scope of this
document"

"

beyond this document scope" -> "beyond the scope of this document" or "beyond
this document's scope"

Thanks,

Donald

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

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)

 155 Beaver Street, Milford, MA 01757 USA



d3e3e3 at gmail.com