-----Original Message-----
From: Peter Yee [mailto:peter(_at_)akayla(_dot_)com]
Sent: 21 August 2014 22:16
To: draft-ietf-opsec-lla-only(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Gen-ART Telechat review of draft-ietf-opsec-lla-only-10
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 wait for direction from your document shepherd or AD before
posting a new version of the draft.
Document: draft-ietf-opsec-lla-only-10
Reviewer: Peter Yee
Review Date: August-21-2014
IETF LC End Date: April-7-2014
IESG Telechat date: August-21-2014
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 (remaining) arguments
for use of link-local addresses to be terribly compelling, but I'm not 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, 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. I'd still
consider dropping this marginal example. The TCP SYN flood suffices to
make the point.
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.
Both points have been addressed in previous mails.
Nits:
Page 4, 5th paragraph, 2nd sentence: delete the comma after "[RFC4987])"
and change the "or" to "and".
Overtaken by other edits (second example was deleted)
Page 6, 1st full paragraph, 1st sentence: replace "a" with "an" before "MPLS
LSP".
Changed.
Thanks for the thorough review!
Eric and Michael
-Peter Yee