Skip to main content

Last Call Review of draft-ietf-opsec-lla-only-07
review-ietf-opsec-lla-only-07-genart-lc-yee-2014-04-14-00

Request Review of draft-ietf-opsec-lla-only
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-04-07
Requested 2014-03-27
Authors Michael H. Behringer , Éric Vyncke
I-D last updated 2014-04-14
Completed reviews Genart Last Call review of -07 by Peter E. Yee (diff)
Genart Telechat review of -10 by Peter E. Yee (diff)
Secdir Last Call review of -07 by Christopher Inacio (diff)
Opsdir Last Call review of -07 by Suzanne Woolf (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-opsec-lla-only by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 11)
Result Ready w/issues
Completed 2014-04-14
review-ietf-opsec-lla-only-07-genart-lc-yee-2014-04-14-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-opsec-lla-only-07
Reviewer: Peter Yee
Review Date: April-7-2014
IETF LC End Date: April-7-2014
IESG Telechat date: TBD

Summary: This draft is basically ready for publication as an Informational
RFC, but has issues that should be fixed before publication. [Ready with
issues.]

This document discusses the (controversial) use of IPv6 link-local addresses
on router infrastructure links.  I don't find all of the arguments for use
of link-local addresses to be terribly compelling, but I'm not utterly
averse to the document's publication as a summary of some of the pros and
cons for those who desire to configure their routers in the manner
prescribed.  There may be other reasons that should be taken into
consideration, but I lack a network operator's experience to discuss them.

Minor:

Page 4, 4th paragraph: I don't buy this argument.  DNS can be simplified for
non-link-local addresses by simply not registering those addresses in DNS.
Use of link-local addresses isn't a requirement to simplify DNS.

Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks aren't
really reduced unless the reduction is simply not being able to attack a
single router over multiple interfaces in parallel.  A better scheme for
reducing SSH brute force password attacks might be to limit the rate of
responses to SSH login attempts in the face of repeated failures.
Considering dropping this marginal example.

Page 4, 6th paragraph, 1st sentence: I'm not sure what is meant by "the same
result".  Is this in reference to all 5 paragraphs that precede the 6th?  If
so, you might wish to elaborate with "the same results as the above" .
However, if the same results can be obtained without going to link-local
addressing as this paragraph indicates, why is the use of link-local
addressing being suggested?  The paragraph might do well to explain why one
scheme is preferable over the other.

Page 6, 1st partial paragraph: the argument is made that "more work" is
required to discover all of an IXPs loopback interface addresses before a
generic attack can be mounted.  This wouldn't seem to be a lot of upfront
work and once it has been done, the advantage is negated.  I don't find the
argument particularly persuasive.  

Nits:

Page 2, Section 2 title: change "Address" to "Addressing".

Page 3, second paragraph: change "non link-local" to "non-link-local".

Page 4, 1st paragraph, 3rd sentence: change "accellerated" to "
accelerated".

Page 4, 5th paragraph, 2nd sentence: delete the comma after "[RFC4987])" and
change the "or" to "and".

Page 6, 1st full paragraph, 1st sentence: change "allow" to "allows" and
insert "an" before "MPLS LSP".


		-Peter Yee