Using Only Link-Local Addressing inside an IPv6 Network
draft-ietf-opsec-lla-only-11

I have no strong objection to the publication of this document although
there is to me a faint whiff of what a sceptic might call snake oil.
Some of that arises from an imbalance of language ("advantages" 
against "caveats" rather than "opportunities" against "disadvantages")
and some of it could have been dispelled by answering the shepherd 
write-up question on implementation by describing the existing 
deployments that use this technique.

Anyway, here are two editorial issues for you to consider...

Are the last two paragraphs of 2.2 in the right section? They do not
appear to describe "advantages" of the proposed scheme.

The text "using only link-local addresses on infrastructure links" is
lumpy to read, but does convey exactly what you mean. There is a 
temptation to read it as "using link-local addresses only on
infrastructure links" and you will need to watch the RFC Editor to make
sure that bug doesn't creep in. And you will need to fix Section 3 
where you have 
   Using LLAs only on infrastructure links reduces the attack surface of
   a router

= Section 2.3 =
If it seems reasonable, might it be possible to say "LLAs have usually been EUI-64 based" rather than "LLAs are usually EUI-64 based" given that there is some movement away from embedding hardware addresses in IIDs (e.g., draft-ietf-6man-default-iids)?

Thanks for addressing my DISCUSS.

I have not seen a response to Peter Yee's Gen-ART review, although some of the suggested issues have been corrected.

FWIW, I still think Peter was right in these two items that have not been changed:

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 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.

Overall, I think this is a well written draft and think the security benefits could be very positive.  

In section 2.2, could you move up the reference to RFC6752 and then you can avoid the last sentence in this section.  I think it makes it cleaner and leads you right to the detailed description for iACL.

Suggest change from: "This may
   ease protection measures, such as infrastructure access control lists
   (iACL)."
To: "This may
   ease protection measures, such as infrastructure access control lists
   (iACL). [RFC6752]"  

I agree with the point made in this paragraph and think another advantage is that you can define ACLs for the pass through traffic at this point that is 'invisible' for direct attacks.  Some firewalls operate in what they call bridge mode for that purpose.

Please see the recommendation in the SecDir review to include references to security considerations sections in previously mentioned RFCs in the draft.  Here's a link in case you didn't see it.

https://www.ietf.org/mail-archive/web/secdir/current/msg04709.html

   During WG and IETF last call the technical correctness of the
   document has been reviewed, however debate exists as to whether to
   recommend this technique.  The deployment of this technique is
   appropriate where it is found to be necessary.

Wow. The above (especially the second sentence), along with the shepherd writeup, does make one wonder whether the WG really wanted to publish this document. I'm not about to stand in the way, but to say that the "technique is appropriate where it is found to be necessary" is not a very meaningful claim.

nitty nits only:

section 1: "attack horizon" isn't the usual phrase, "attack
surface" is I think more common (and is used later for this).

section 1: "The deployment of this technique is appropriate
where it is found to be necessary" seems to be a tautology.

2.4: I think uRPF and PTMUd are used without expansion.
(And why the small 'd' in PMTUd, don't recall that before.)