> -----Original Message----- > From: Peter Yee [mailto:peter@xxxxxxxxxx] > Sent: 21 August 2014 22:16 > To: draft-ietf-opsec-lla-only.all@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx > 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 > >