Re: [Gen-art] Gen-ART Telechat review of draft-ietf-opsec-lla-only-10

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Peter Yee [mailto:[e-mail]]
> Sent: 21 August 2014 22:16
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
> 
>