> -----Original Message----- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: 04 December 2013 16:04 > To: Michael Behringer (mbehring); opsec@ietf.org > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > Hi Michael, > > I realize that I am in the rough on this one and would be happy to back off.
This is about clarity, and a good discussion. Thanks! We want this draft to be factually correct and clear. > But before I do that, could you respond to my question regarding whether > numbering router-to-router interfaces from link-local really reduces the > attack surface of a router? After all, every resource that is vulnerable to > attack when numbered from global address space is also vulnerable when > numbered from link-local address space. You haven't reduced the number > of vulnerable interfaces, only the number and specificity of the addresses > by which they can be addressed. That is strictly speaking correct. An interface doesn't become un-vulnerable because it uses a link-local address. But a link local address can only be reached (and therefore attacked) from the link. That significantly reduces the exposure of that address, and this is a recognised concept: http://tools.ietf.org/html/rfc5082 (GTSM) states in section 5.3 clearly that on-link attacks are possible, yet I think there is consensus that there is value in reducing the attack horizon. So yes, link local reduces the number of addresses a device can be reached by. We try to be clear in section 2.2: " Reduced attack surface: Every routable address on a router constitutes a potential attack point: a remote attacker can send traffic to that address. Examples are a TCP SYN flood (see [RFC4987]), or SSH brute force password attacks. If a network only uses the addresses of the router loopback interface(s), only those addresses need to be protected from outside the network. This may ease protection measures, such as infrastructure access control lists. " Note we're talking about addresses, not interfaces (as you point out). Re-reading this paragraph, I still think it's factually correct. Now, as Gert has pointed out previously, if you address your entire core address space (loopbacks and interface addresses) out of the same supernet, and if you have iACLs at the edge blocking that supernet, you don't gain on this point. If you address them out of different blocks, your life becomes slightly easier. So it depends on your deployment model. Please suggest how we could be clearer, or if we're factually incorrect. Michael > > Ron > > > > -----Original Message----- > > From: Michael Behringer (mbehring) [mailto:mbehr...@cisco.com] > > Sent: Wednesday, December 04, 2013 3:59 AM > > To: Ronald Bonica; opsec@ietf.org > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > Ron, > > > > When we started this work we wanted to make a recommendation, > because > > we believe that there are advantages in the approach. Quite early it > > has become clear that there is no consensus in the IETF on whether the > > link local approach actually makes life simpler or not. Some people > > say it doesn't, some people say it does. > > > > So the agreement at the time was to list, factually, without any > > weighing of judgement, the technical aspects, pros and cons. This is > > what we're trying to do. > > > > We have removed all "recommend" and similar phrases. (Thanks to our > > reviewers, who kept us honest here). > > > > The idea is that a network operator has easy access to all the aspects > > to consider, potential advantages, and caveats. And this operator > > should now be able to say for his network: this advantage doesn't make > > much difference to me; the other one does. This caveat does apply to > > me, the other one not. And you're making those calls below; my point > > would be: We've seen in the early stages of this draft that it's hard > > to get global consensus on those. > > > > So I suggest we keep the document factual, and let operators make > > their own choices. This is what the document should achieve. It should > > not make a judgement on the value of any aspects, because those would > > be context-dependent. > > > > My question is: Is the document in any place not factual? Or missing > > facts? If so, please let us know - that should be fixed! > > > > Michael > > > > > -----Original Message----- > > > From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf Of Ronald > > Bonica > > > Sent: 03 December 2013 19:55 > > > To: opsec@ietf.org > > > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 > > > > > > Folks, > > > > > > Reading through Sections 2.2 and 2.3 of this document, I question > > > whether the benefits of numbering router interfaces from link-local > > > address space actually outweigh the cost. The document lists the > > following as benefits: > > > > > > 1) Smaller routing tables > > > 2) Simpler address management > > > 3) Lower configuration complexity > > > 4) Simpler DNS > > > 5) Reduced attack surface > > > > > > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider > > > numbering router-to-router interfaces from link-local space. In a > > > large network, the number of router-to-router interfaces is dwarfed > > by > > > the total number of interfaces. So, numbering router-to-router > > > interfaces reduces the magnitude of some problems, but not by a > > significant amount. > > > > > > Advantage #5 also is dubious. If you think of an address as being > > "the > > > attack surface" of a router, then numbering selected interfaces from > > > link-local reduces the attack surface. But miscreants don't attack > > > addresses. They attack the resource that an address represents. > > > Since all of those resources are accessible using the box's globally > > > routable loopback address, numbering some interfaces from link-local > > > really doesn't reduce the attack surface. > > > > > > I realize that this may not be the kind of review that you want. So, > > I > > > am happy to be told that mine is the minority opinion. > > > > > > -------------------------- > > > Ron Bonica > > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > > > > > > > _______________________________________________ > > > OPSEC mailing list > > > OPSEC@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
