Using Only Link-Local Addressing inside an IPv6 Network
RFC 7404

Note: This ballot was opened for revision 10 and is now closed.

(Spencer Dawkins) Yes

Comment (2014-08-18 for -10)
No email
send info
Thank you for documenting what many folk (including me) partially understand!

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

Comment (2014-08-21 for -10)
No email
send info
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.

(Richard Barnes) No Objection

Alissa Cooper No Objection

Comment (2014-08-20 for -10)
No email
send info
= 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)?

(Adrian Farrel) No Objection

Comment (2014-08-18 for -10)
No email
send info
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

(Stephen Farrell) No Objection

Comment (2014-08-20 for -10)
No email
send info
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.)

(Brian Haberman) (was Discuss) No Objection

Comment (2014-09-25)
No email
send info
Thanks for addressing my DISCUSS.

(Kathleen Moriarty) No Objection

Comment (2014-08-20 for -10)
No email
send info
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

(Pete Resnick) No Objection

Comment (2014-08-21 for -10)
No email
send info
   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.

(Martin Stiemerling) No Objection

(Ted Lemon) (was Discuss) Abstain

Comment (2014-08-21 for -10)
No email
send info
I promised to drop my DISCUSS at the end of the telechat.   There was rather overwhelming advice from operators who actually have large deployments in the field that this was a bad idea, and I think that should be reflected in the document, but I'm not going to actively block the document because the text doesn't currently reflect that message.

That said, I would like to see the text updated to clearly say that some experienced operators consider this a bad idea, and that operators who are considering deploying this method should bear that in mind and not take the fact that this document has been published by the IETF as an indication that this is a preferred method of deployment.