Subject: [OPSEC] New Work: Protecting the control plane

From: Ronald Bonica <[email-masked]>
Date: Tue, 11 Jan 2011 12:25:56 -0500

Folks,

RFC-to-be draft-ietf-opsec-protect-control-plane recommends methods for protecting a router's control plane from outsider attack. However, the methods proposed in draft-ietf-opsec-protect-control-plane do not protect against:

- attacks from those spoofing the source address of a legitimate control plane peer
- attacks from legitimate control plane peers (that might be compromised or otherwise misbehaving)

Is anyone interested in authoring a draft to address these issues?

                                        Ron

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 09:46:35 -0800

Hi Ron,

> - attacks from those spoofing the source address of a legitimate control plane peer
This can be caught by authentication, mechanisms also using the source
address as a part of the hash.

> - attacks from legitimate control plane peers (that might be compromised or otherwise misbehaving)
This is considerably harder to know for IGP's. For BGP we can verify
the origin . One thing that can be done is Public Key Cryptography.
There are mechanisms available for the same already, however the
documents are experimental.

The question however is how important are these issues for the
operators to tackle?

Thanks,
Vishwas

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jan 2011 12:54:40 -0500

> address as a part of the hash.

maybe with something like gtsh.  people generate all sorts of garbage on the internet, using ONLY the src_ip+dst_ip is not enough, but a good starting point.

> The question however is how important are these issues for the

Based on real-life attacks, it's important to insure the attacks don't overwhelm the underpowered cpus that are in some devices.  Suggesting crypto as part of that is only useful if there is a dedicated crypto engine that is now required.

- Jared

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 11 Jan 2011 13:01:11 -0500

There are a few simple things that we can do (e.g., rate limit TCP SYNs)

                                    Ron

> -----Original Message-----
> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Tuesday, January 11, 2011 12:47 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [OPSEC] New Work: Protecting the control plane
> 
> Hi Ron,
> 
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 10:18:53 -0800

Hi Ron,

We already had a draft with that and a lot more:
http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09

We could resurrect it, if that is a requirement. It had gone all the
way to the IESG.

Thanks,
Vishwas

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 11 Jan 2011 11:25:01 -0700

GTSM would be much better for this part.

>> address as a part of the hash.

Its really hard to spoof a "large" ttl.
It is also cheep compared to hashing.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Vishwas Manral [[email-masked]]
Sent: Tuesday, January 11, 2011 11:18 AM
To: Ronald Bonica
Cc: [email-masked]
Subject: Re: [OPSEC] New Work: Protecting the control plane

Hi Ron,

Thanks,
Vishwas

>> The question however is how important are these issues for the
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 10:37:42 -0800

Hi Don,

You are right for a lot of cases.

However GTSM may not be able to work in all cases. Take the case of
OSPF Virtual link or IBGP session. The number of hops are determined
at run time.

GTSM also does not protect in a switched network case where one of the
machines, one IP hop away is spoofing for another machine on the same
network.

Thanks,
Vishwas

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jan 2011 13:44:48 -0500

> machines, one IP hop away is spoofing for another machine on the same

Perhaps I am not understanding what you are talking about, but protecting the control plane is best done with the simple checks first.  Certainly it's not going to help with the OSPF case, or necessarily with the iBGP case, but the ranging of these can help significantly.  OSPF I would view as an architectural fail on the part of a SP if they allowed the injection or reception of messages on untrusted links.  Certainly the concept of baseline filtering should be the first step.

GTSM does not prevent some of the layer-2 attacks that are feasible, but layer-2 switching and filtering can address this without the packets reaching the control-plane of a target device.

I don't want to presume to be an expert here, but in this case I don't see where those concerns can't be addressed with a layer-2 filtering technique.  (Not all switches may have this, but I can't make people actually abide by best practices either, so boiling that ocean is a step too far imho).

- Jared

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 10:51:45 -0800

Hi Jared,

Assume if there are 3 OSPF devices A, B, C attached to a network
(broadcast network - this is what I meant switched network).

Now GTSM cannot prevent A to spoof the source address C to be sent in
the packet to B even for single hop cases. This can happen if A is
compromised.

It would be the same case if in an IXP we allowed multiple EBGP
sessions over the same broadcast/ switched network. This could happen
an ISP is malicious.

Thanks,
Vishwas

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jan 2011 14:01:55 -0500

> (broadcast network - this is what I meant switched network).

Sure, and if you are allowing devices outside your control in the same broadcast domain to participate in your IGP, you have a much larger problem than just spoofed packets coming into the control plane.

> the packet to B even for single hop cases. This can happen if A is

Agree.

> sessions over the same broadcast/ switched network. This could happen

Yes, this is a challenge, but there is nothing preventing us from leveraging capabilities of dhcp, ra guard, etc.. to have packets filtered out at layer-2 that come from untrusted/unauthenticated ports.  The folks at AMS-IX, LINX, etc.. are highly professional and know where those IP <-> MAC entries appear.  Saying proto==6&&ip.ttl==255 && s.mac==HHHH.HHHH.HHHH is much easier than if (crypto_pass());

Crypto is not always the solution for every problem.  That being said, crypto does solve other problems.  It's much easier to get someone to do the 3-4 checks vs crypto when dealing with a slow processor in some platforms/vendors, and starts to become something that can be done in TCAM and FPGA much easier.

- Jared

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 11:13:22 -0800

Hi Jared,

I agree Crypto is not the solution for everything. It is for that
purpose I talked about the criticality of the requirement in the first
case.

It increases CPU load and also makes considerably worse the attacks on the CPU.

Thanks,
Vishwas

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 11 Jan 2011 15:13:43 -0700

Why didn't this one go forward?
It looks pretty good.

Hi Ron,

Thanks,
Vishwas

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 11 Jan 2011 18:00:21 -0500

Vishwas,

I think that draft-ietf-opsec-filter-caps answers a slightly different question. It has been three years since I looked at that draft, but as I recall, it attempts to describe all filtering capabilities that should be available on a router.

Today, we are asking a more specific question. Specifically we want to know what we should do to protect a router's control plane from either a) insider attack or b) attack from outsiders spoofing inside source addresses.

That said, I would be very happy to see somebody resume work on draft-ietf-opsec-filter-caps. As I recall, the IESG comments were extensive. So, the person signing up for that task should be ready for lots of work.

                                                     Ron

> Sent: Tuesday, January 11, 2011 1:19 PM
> To: Ronald Bonica
> Cc: [email-masked]

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 11 Jan 2011 16:18:15 -0700

We could probably add some of what your asking for to the cpp draft or call out that sharing a broadcast domain in your igp is risky and layer 2 security should be implemented. Add GTSM and we should be able to address most of the issues.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ronald Bonica [[email-masked]]
Sent: Tuesday, January 11, 2011 4:00 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [OPSEC] New Work: Protecting the control plane

Vishwas,

                                                     Ron

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Jan 2011 15:27:45 -0800

Hi Ron,

I agree more work is required to the last version of the draft.
However IMHO, I think older version of the drafts may be more
comprehensive and better, we could start with them.

Like Donald mentioned we can add the things you have referred to.

Thanks,
Vishwas

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jan 2011 09:22:50 +0200 (EET)

> machines, one IP hop away is spoofing for another machine on the same

IBGP sessions can be trivially protected by blocking source address 
spoofing of {all, the addressed used in IBGP} at your borders.  I have 
not done the analysis for OSPF on this.

It's true that on your border EBGP session the spoofing may harm you, 
especially towards transit or an IX (your second point).  There GTSM 
helps you, as well as TCP MD5 (or similar).  In transit case, your 
upstream's similar filtering may also help.

A long time ago, I wrote about this in:
http://tools.ietf.org/html/draft-savola-rtgwg-backbone-attacks-03

So, getting back to Ron's original questions:

- attacks from those spoofing the source address of a legitimate 
control plane peer
- attacks from legitimate control plane peers (that might be 
compromised or otherwise misbehaving)

... I think the first point can be reasonably well operationally 
addressed.

The second point more tricky, but as mentioned, some form of 
rate-limiting or CPU upper bound per neighbor could help here as well. 
But that is by design a tradeoff between resources and convergence 
time in a normal case.  For example, when you're legitimately 
establishing a BGP session where you get 350K routes, it's expected 
and desired that your router uses _almost_ all CPU on processing those 
routes as fast as it can.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 12 Jan 2011 14:48:32 +0100 (CET)

Ron,

On Tue, 11 Jan 2011, Ronald Bonica wrote:

> Today, we are asking a more specific question. Specifically we want to know 
> what we should do to protect a router's control plane from either
> a) insider attack or

Maybe I am too much into conspiracy theories - but why kill the cow that gives 
the milk ? If I were a blackhat and I had a control over a router - I'd use it 
to selectively redirect traffic to the place where I could capture/MITM it, or 
to collect the credentials of the operators that log in, or social-engineer 
them. Not DoS the peer router and thus reveal myself.

That consideration aside: rate-limiting SYNs would not prevent from ACK floods, 
nor RST floods. So this would bring in the need to have a built-in stateful 
firewall in front of control plane. Which assumes that this firewall would be 
capable at handling the full state at line-rate. Which means then we solved the 
problem "at its root": the performance tradeoff in the control plane that 
creates this problem.

> b) attack from outsiders spoofing inside source addresses.

I would think that blocking one's infrastructure address space
on ingress to one's AS should take care of this. What am I missing ?

cheers,
andrew

>
> That said, I would be very happy to see somebody resume work on 
>draft-ietf-opsec-filter-caps. As I recall, the IESG comments were extensive. 
>So, the person signing up for that task should be ready for lots of work.
>
>                                                     Ron
>
>
>

---

From: George Jones <[email-masked]>
Date: Wed, 12 Jan 2011 14:54:08 +0000

On Tue, Jan 11, 2011 at 11:00 PM, Ronald Bonica <[email-masked]> wrote:

> Vishwas,
>
> I think that draft-ietf-opsec-filter-caps answers a slightly different
> question. It has been three years since I looked at that draft, but as I
> recall, it attempts to describe all filtering capabilities that should be
> available on a router.
>

The capabilities drafts were all about "The Router Can do X [filtering]" to
enable testing.

> what we should do to protect a router's control plane from either a) insider
> attack or b) attack from outsiders spoofing inside source addresses.
>

Filtering things aimed at the control plane, using features enumerated in
the capabilities drafts, would be one use case.

> So, the person signing up for that task should be ready for lots of work.
I'll go back and have a look at the IESG comments....but I think, at a
WG/AD/Charter level we'd need to revisit the roll of capabilities drafts ...
do they fit in the current charter ?  Are they useful ?  Will they
be used/change anything for the better ?    Perhaps you, I, Chris, Joel and
Joe should *talk* ?

---George

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 12 Jan 2011 11:42:33 -0500

Vishwas,

I am happy to see someone revive the old draft. However, be mindful of the old IESG comments. As I recall, they called or a considerable amount of work.

                                        Ron

> Sent: Tuesday, January 11, 2011 6:28 PM
> To: Smith, Donald
> Cc: Ronald Bonica; [email-masked]
> > We could probably add some of what your asking for to the cpp draft
> or call out that sharing a broadcast domain in your igp is risky and
> layer 2 security should be implemented. Add GTSM and we should be able
> to address most of the issues.
> >
> >
> >
> > I think that draft-ietf-opsec-filter-caps answers a slightly
> different question. It has been three years since I looked at that
> draft, but as I recall, it attempts to describe all filtering
> capabilities that should be available on a router.
> >
> > Today, we are asking a more specific question. Specifically we want
> to know what we should do to protect a router's control plane from
> either a) insider attack or b) attack from outsiders spoofing inside
> source addresses.
> >
> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were
> extensive. So, the person signing up for that task should be ready for
> lots of work.
> >
> >                                                     Ron
> >
> >
> >
> >> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica
> <[email-masked]>
> >> wrote:

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 12 Jan 2011 12:48:20 -0500

> on ingress to one's AS should take care of this. What am I missing ?

Hi Andrew,

While I agree that everyone should filter infrastructure addresses at the edge, it don't believe that edge filtering is sufficient. Reasons follow:

- some edge gear may not be capable of filtering
- if a single edge box is misconfigured (i.e., a single filter is missing), the entire core is vulnerable
- if a single edge box is compromised, the entire core is vulnerable.

So, I think that some operators may require multiple layers of protection. If the inner layer is cheap, it would be a very good idea to deploy it.

                                          Ron
                                          /speaking as individual contributor

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 12 Jan 2011 15:11:59 -0700

Defense in depth is a basic principle of security so I agree:)

"Pampers use multiple layers of protection to prevent leakage.
Rommel used defense in depth to defend European fortresses." (A.White)
[email-masked] gcia

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Ronald Bonica
> Sent: Wednesday, January 12, 2011 10:48 AM
> To: Andrew Yourtchenko
> Cc: [email-masked]
> While I agree that everyone should filter infrastructure
> addresses at the edge, it don't believe that edge filtering
> is sufficient. Reasons follow:
>
> - if a single edge box is misconfigured (i.e., a single
> filter is missing), the entire core is vulnerable
> So, I think that some operators may require multiple layers
> of protection. If the inner layer is cheap, it would be a
> very good idea to deploy it.
>
>                                           Ron
>                                           /speaking as
> individual contributor
>

---

From: Jared Mauch <[email-masked]>
Date: Wed, 12 Jan 2011 17:26:32 -0500

> on ingress to one's AS should take care of this. What am I missing ?

Easier said then entered after

'conf t' or 'configure;commit'

sadly 

:(

- Jared

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Jan 2011 19:59:09 -0500

On Jan 12, 2011, at 8:48 AM, Andrew Yourtchenko wrote:

>> either
> Maybe I am too much into conspiracy theories - but why kill the cow  
> that gives the milk ? If I were a blackhat and I had a control over  
> a router - I'd use it to selectively redirect traffic to the place  
> where I could capture/MITM it, or to collect the credentials of the  
> operators that log in, or social-engineer them. Not DoS the peer  
> router and thus reveal myself.

In many enterprises everything with the enterprise is viewed as  
"inside" and no real protection (CPP or otherwise) is provided from  
address space within the enterprise.

>
> That consideration aside: rate-limiting SYNs would not prevent from  
> ACK floods, nor RST floods. So this would bring in the need to have  
> a built-in stateful firewall in front of control plane. Which  
> assumes that this firewall would be capable at handling the full  
> state at line-rate. Which means then we solved the problem "at its  
> root": the performance tradeoff in the control plane that creates  
> this problem.
>

Well, for one, you are making the assumption that folk have actually  
numbered their infrastructure out of "infrastructure space", and not  
just chosen IPs out of whatever block happened to be nearby.... ;-)

W

>> extensive. So, the person signing up for that task should be ready  
>> for lots of work.
>>
>>                                                    Ron
>>
>>
>>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 13 Jan 2011 11:04:42 +0100 (CET)

Hi Ron,

On Wed, 12 Jan 2011, Ronald Bonica wrote:

> So, I think that some operators may require multiple layers of protection. If 
> the inner layer is cheap, it would be a very good idea to deploy it.

Agreed, if it is there, shame not to use it. I think what was causing 
the question in me, is this. I would say what we would do depends on 3 factors:

1) the threat model
2) means of identification for the traffic ("legit"/"illegit")
3) means of enforcing the policy of allowing only legit traffic.

I think (1) is somewhat defined, while possibly we have different 
pictures in mind for (2)/(3).

I was thinking of the latter in terms of a simple ACL-like mechanism before the 
traffic exits the data plane, while it is definitely not the only way, and you 
had in mind something different ?

cheers,
andrew

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 13 Jan 2011 11:17:32 +0100 (CET)

On Wed, 12 Jan 2011, Warren Kumari wrote:

>>> Today, we are asking a more specific question. Specifically we want to 
>>> know what we should do to protect a router's control plane from either
>>> a) insider attack or
>> 
>> Maybe I am too much into conspiracy theories - but why kill the cow that 
>> gives the milk ? If I were a blackhat and I had a control over a router - 
>> I'd use it to selectively redirect traffic to the place where I could 
>> capture/MITM it, or to collect the credentials of the operators that log 
>> in, or social-engineer them. Not DoS the peer router and thus reveal 
>> myself.
>
> In many enterprises everything with the enterprise is viewed as "inside" and 
> no real protection (CPP or otherwise) is provided from address space within 
> the enterprise.
>

Right. But does this invalidate my point ? i.e. the fact that the mere access to 
the control plane (DoS-resistant or not) is much more important than DoS 
protection per se. Foot-shooting aside, of course.

>
>> 
>> That consideration aside: rate-limiting SYNs would not prevent from ACK 
>> floods, nor RST floods. So this would bring in the need to have a built-in 
>> stateful firewall in front of control plane. Which assumes that this 
>> firewall would be capable at handling the full state at line-rate. Which 
>> means then we solved the problem "at its root": the performance tradeoff in 
>> the control plane that creates this problem.
>> 
> Well, for one, you are making the assumption that folk have actually numbered 
> their infrastructure out of "infrastructure space", and not just chosen IPs 
> out of whatever block happened to be nearby.... ;-)

touche ;-)

cheers,
andrew

---

From: Warren Kumari <[email-masked]>
Date: Thu, 13 Jan 2011 09:05:41 -0500

On Jan 13, 2011, at 5:17 AM, Andrew Yourtchenko wrote:

>>>> different question. It has been three years since I looked at  
>>>> that draft, but as I recall, it attempts to describe all  
>>>> filtering capabilities that should be available on a router.
>>>> Today, we are asking a more specific question. Specifically we  
>>>> want to know what we should do to protect a router's control  
>>>> plane from either
>>>> a) insider attack or
>>> Maybe I am too much into conspiracy theories - but why kill the  
>>> cow that gives the milk ? If I were a blackhat and I had a control  
>>> over a router - I'd use it to selectively redirect traffic to the  
>>> place where I could capture/MITM it, or to collect the credentials  
>>> of the operators that log in, or social-engineer them. Not DoS the  
>>> peer router and thus reveal myself.
>>
> Right. But does this invalidate my point ? i.e. the fact that the  
> mere access to the control plane (DoS-resistant or not) is much more  
> important than DoS protection per se.

Oh no, not at all... Just that both are important and should be  
secured / protected...

W

> Foot-shooting aside, of course.
>
>>
>>> That consideration aside: rate-limiting SYNs would not prevent  
>>> from ACK floods, nor RST floods. So this would bring in the need  
>>> to have a built-in stateful firewall in front of control plane.  
>>> Which assumes that this firewall would be capable at handling the  
>>> full state at line-rate. Which means then we solved the problem  
>>> "at its root": the performance tradeoff in the control plane that  
>>> creates this problem.
>> Well, for one, you are making the assumption that folk have  
>> actually numbered their infrastructure out of "infrastructure  
>> space", and not just chosen IPs out of whatever block happened to  
>> be nearby.... ;-)
>
> touche ;-)
>
> cheers,
> andrew
>
>
>>
>> W
>>
>>> cheers,
>>> andrew
>>>> extensive. So, the person signing up for that task should be  
>>>> ready for lots of work.
>>>>
>>>>                                                  Ron
>>>>> On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica <[email-masked] 
>>>>> >
>>>>> wrote:
>>>>>> There are a few simple things that we can do (e.g., rate limit  
>>>>>> TCP
>>>>> SYNs)
>>>>>>
>>>>>>                                  Ron

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 28 Jan 2011 15:35:51 -0800

> floods, nor RST floods. So this would bring in the need to have a
> built-in stateful firewall in front of control plane. Which assumes that
> this firewall would be capable at handling the full state at line-rate.
> Which means then we solved the problem "at its root": the performance
> tradeoff in the control plane that creates this problem.

It not necessary to have a stateful device to rate-limit syns... the
problem you have really is if your rate-limiting is in effect, and one
of your valid tcp connections goes down, it needs to not get clobbered
by the rate limiter... Like many kinds of policers if deployed wrongly
it can make it easier rather than harder to take out the box (think arp
policer as another example)

>>>> � � � � � � � � � � � � � � � � � �Ron
>>>>
>>>>

---

From: "Smith, Donald" <[email-masked]>
Date: Sat, 29 Jan 2011 07:07:48 -0700

(coffee != sleep) & (!coffee == sleep)
 [email-masked]
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joel Jaeggli [[email-masked]]
Sent: Friday, January 28, 2011 4:35 PM
To: Andrew Yourtchenko
Cc: [email-masked]
Subject: Re: [OPSEC] New Work: Protecting the control plane

This risk is at least partially mitigated by having an OOBR mgmt network so that should be part of the risk mitigation recommendations;)