Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05

From: Ronald Bonica <[email-masked]>
Date: Tue, 3 Dec 2013 18:54:44 +0000

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

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 4 Dec 2013 01:47:52 +0000

On Dec 4, 2013, at 1:54 AM, Ronald Bonica <[email-masked]> wrote:

> I question whether the benefits of numbering router interfaces from link-local address space actually outweigh the cost.

I'd be very interested to hear the view of the authors on how this differs in effect from numbering IPv4 router interfaces from RFC1918 spaces, and the operational issues which arise from doing so.  

While link-local addresses are generally unique, we should consider the experience to date in dealing with privately-addressed router interfaces on the public Internet, and determine whether the benefits of doing something similar with IPv6 outweigh the possible negatives.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 4 Dec 2013 08:59:27 +0000

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:[email-masked]] On Behalf Of Ronald Bonica
> Sent: 03 December 2013 19:55
> To: [email-masked]
> 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:
> 
> 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.
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Dec 2013 10:06:18 +0100

Hi,

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

... and this I support :-) - even if I'm in the "I don't like this approach"
camp.

> 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 th…

+1

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 4 Dec 2013 09:06:54 +0000

> From: OPSEC [mailto:[email-masked]] On Behalf Of Dobbins,
> Roland
> Sent: 04 December 2013 02:48
> To: [email-masked]
> Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05
> 
> 
> > I question whether the benefits of numbering router interfaces from link-
> local address space actually outweigh the cost.
> 
> I'd be very interested to hear the view of the authors on how this differs in
> effect from numbering IPv4 router interfaces from RFC1918 spaces, and the
> operational issues which arise from doing so.

Roland, in short: We're not addressing RFC1918 in this doc. It's outside scope. 

> While link-local addresses are generally unique, we should consider the
> experience to date in dealing with privately-addressed router interfaces on
> the public Internet, and determine whether the benefits of doing
> something similar with IPv6 outweigh the possible negatives.

The 1918 method is different. It would be an interesting discussion to have, in another document.
 
For the LLA approach, we were told in no uncertain terms that we should NOT make a judgement, but just list the facts to consider. That's what we tried to do. Each operator should be able to take those and make his judgement. 

Please let us know where we're not factual or misleading - that needs fixing. 

Michael

---

From: Rob Bird <[email-masked]>
Date: Wed, 4 Dec 2013 04:12:04 -0500

Well put!

> On Dec 4, 2013, at 4:06 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 15:03:45 +0000

Hi Michael,

I realize that I am in the rough on this one and would be happy to back off. 

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.

                                             Ron

> From: Michael Behringer (mbehring) [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2013 3:59 AM
> To: Ronald Bonica; [email-masked]
> 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.
> 
> 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
> 
> > 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:
> >
> > 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.
> >

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 4 Dec 2013 17:06:27 +0000

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: 04 December 2013 16:04
> To: Michael Behringer (mbehring); [email-masked]

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

> > link local approach actually makes life simpler or not. Some people
> > say it doesn't, some people say it does.
> >
> > 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.
> >
> > > addresses. They attack the resource that an address represents.
> > > Since all of those resources are accessible using the box's globally

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 4 Dec 2013 17:09:50 +0000

Michael,

OK, I am happy to back off on this one.

Chairs,

Please consider my review as being without objection.

                              Ron

> Sent: Wednesday, December 04, 2013 12:06 PM
> > 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.
> 
> > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > > whether the benefits of numbering router interfaces from
> > > > link-local address space actually outweigh the cost. The document
> > > > lists the
> > > following as benefits:
> > > >
> > > > 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
> > > > 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.
> > > >

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Dec 2013 12:16:23 -0500

> For the LLA approach, we were told in no uncertain terms that we should NOT make a judgement, but just list the facts to consider. That's what we tried to do. Each operator should be able to take t…

Yup, I think that this is one of the sticking points with this draft -- it seems fairly clear that you can do what the draft describes (we have an existence proof), much of the discussion has been on the "Are we advocating this as a solution?" topic. A number of folk have asked that we document be more of a "If you use LLA for links, this is what to keep in mind / this is what we have found" and not a value judgment on doing this.

When commenting can folk please also include if they think the draft tone correctly captures this?

<no hats>
I have read all the versions of this document and think that the tone has greatly improved, but feel that section 2.5 (Summary) still has a bit too much of the "this is a good idea" feel. Personally I think that the Summary section doesn't really add anything to the document and should be dropped.
</no hats>

W

--
"When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie."
-- Terry Pratchett

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 4 Dec 2013 17:27:07 +0000

Ron, thank you for your review! This is a hairy topic, and it's good to have these concerns and discussions voiced and sorted. 

Michael

> Sent: 04 December 2013 18:10
> > 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.
> >
> > 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.
> > "
> >
> > 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.
> >
> > > > 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.
> > > >
> > > > > 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:
> > > > >

---

From: joel jaeggli <[email-masked]>
Date: Wed, 04 Dec 2013 09:55:55 -0800

On 12/3/13, 10:54 AM, Ronald Bonica wrote:
> 1) Smaller routing tables 2) Simpler address management 3) Lower
> configuration complexity 4) Simpler DNS 5) Reduced attack surface
> 
> by the total number of interfaces. So, numbering router-to-router
> "the attack surface" of a router, then numbering selected interfaces
> 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 am happy to be told that mine is the minority opinion.

I'm generally concerned when the question of whether we should put our
stamp on something that we don't consider to be a good idea.

As I noted for the 88 minutes I feel a bit more sanguine about this if
it looks more like a case study, e.g. we "did it because of foo, this is
what we did."

personally I feel that this is a  bad idea in general there may be
specific cases where it is appropriate.

> -------------------------- Ron Bonica vcard:
> www.bonica.org/ron/ronbonica.vcf
> 
> 
> 
> _______________________________________________ OPSEC mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 16 Dec 2013 15:15:03 +0000

Warren, [sorry for late reply]

> From: Warren Kumari [mailto:[email-masked]]
> Sent: 04 December 2013 18:16
> To: Michael Behringer (mbehring)
> Cc: Warren Kumari; Dobbins, Roland; [email-masked]
[...]
> I have read all the versions of this document and think that the tone has
> greatly improved, but feel that section 2.5 (Summary) still has a bit too
> much of the "this is a good idea" feel. Personally I think that the Summary
> section doesn't really add anything to the document and should be
> dropped.

So I've been told throughout school and uni that a document should have intro, body and summary; I'm feeling somewhat reluctant to drop a summary, it just seems wrong. :-)  Let's see whether we can get one that "feels" right. What about:

   Using exclusively link-local addressing on infrastructure links has a number
   of advantages and disadvantages, which are both described in detail
   in  this document. A network operator can use this document to
   evaluate whether using link-local addressing on infrastructure links
   is a good idea in the context of his/her network or not. This document 
   makes no particular recommendation either in favour or against. 

I think this should be balanced, would you agree? 

Michael