Subject: Re: [RPSEC] Basis of Requirements?

From: Stefan Mink <[email-masked]>
Date: Sat, 01 Oct 2005 08:25:30 +0200

Hi Tony,

Tony Li wrote:
> I agree that we can devote some resources to protecting the control 
> plane.  In fact, we must, otherwise we can make no progress at all, as 
> one subsystem must be in advance of the other.  However, just as with 
> your vault door analogy, we should not be installing 3ft. of titanium on 
> the front door at this point: it's not cost effective.  I would welcome 
> a solid core door and Schlage lock.  That would be a cost that is 
> proportional to the threat that will be directed to the control plane.  
> If we have other resources at our disposal, we should focus them on the 
> forwarding plane.

I think its much more important to secure the control plane than the
forwarding plane, as attacks involving the forwarding plane are
locally: I can only the forwarding plane of *my* devices directly;
if I want to temper with other peoples forwarding planes, I have
to attack control plane or hack their systems to get "local" access :]

We will never get to the point that we can keep people from
messing around with their networks, but we need to give the neighboring
networks means, to detect this: this is probably only possible
by comparing ongoings on the forwarding plane with the status of
the control plane.

The result is: we need to first secure the control plane...

Concerning the 3ft titanium front door I agree: we must not only
secure origin authorization (front door) but also redistribution
authorization (backdoor) ;)

    tschuess
              Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Paul Jakma <[email-masked]>
Date: Sat, 1 Oct 2005 20:20:36 +0100 (IST)

On Sat, 1 Oct 2005, Stefan Mink wrote:

> I think its much more important to secure the control plane than 
> the forwarding plane, as attacks involving the forwarding plane are 

> We will never get to the point that we can keep people from messing 
> around with their networks, but we need to give the neighboring 
> networks means, to detect this: this is probably only possible by 
> comparing ongoings on the forwarding plane with the status of the 
> control plane.
>

The forwarding-plane problem isn't that *your* forwarding plane could 
be attacked, but that, even if you have a way to determine which of 
your neighbour's control planes appear trustworthy (in terms of what 
they're telling you about the state of their routing), it says 
nothing about your *neighbour's* forwarding-planes.

It is your neighbour who may be subverting their own forwarding-plane 
(so it would not matter a jot if they could not subvert the 
inter-domain protocol without you noticing).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
  Fry: Ooh, Big Pink. It's the only gum with the breath freshening power of ham.
  Bender: And it pinkens your teeth while you chew.

---

From: Stefan Mink <[email-masked]>
Date: Sun, 02 Oct 2005 23:03:15 +0200

Hi Paul,

Paul Jakma wrote:
> The forwarding-plane problem isn't that *your* forwarding plane could be 
> attacked, but that, even if you have a way to determine which of your 
> neighbour's control planes appear trustworthy (in terms of what they're 
> telling you about the state of their routing), it says nothing about 
> your *neighbour's* forwarding-planes.

oh, thats exactly what I wanted to say :)
(I was putting myself into the role of the attacker...)

An attacker can only use the devices he has control over to manipulate
the forwarding plane in a way not corresponding to the control plane
state. (this is my definition of a "forwarding plane attack").

So since you can not *prevent* attacks on the forwarding plane in other
networks, the only defense we have here is *detection*. We nead means
to check whether events on the forwarding plane correlate with
state on the control plane. This already happens today somewhat via
reverse path forwarding (RPF), which checks whether a packet has a
source that corresponds to a route pointing in that direction. There
are many szenarios where you can use RPF only partially or in a
weakened form (e.g. due to asymmetric routing), but its a start.

What's still missing in my opinion is, that on a packet not only
the reverse path is being checked, but also the "forward path":
did the neighboring AS that sent the packet really got a route from
you for the destination address in the packet . I'm not aware of
any comparable check so far. With such a check you could recognize
if somebody installs static routes on his devices to send traffic
via you he is not meant to.

Anyway: such checks use the control plane (what is the other party
allowed to do on the forwarding plane?) and as long as we can not
rely on the data in the control plane, we can not secure the
forwarding plane. I don't think this working group can to all the
work in one step, so securing the front door via securing the control
plane makes it at least harder for the attacker, since the effects on
attacks on the forwarding plane are much more limited: an attacker
can only attack traffic flowing "naturally" through his network. He
can not attack traffic in other parts of the internet where he is
not involved in the packet transport.

    tschuess
              Stefan

---

From: Paul Jakma <[email-masked]>
Date: Sun, 2 Oct 2005 23:08:22 +0100 (IST)

On Sun, 2 Oct 2005, Stefan Mink wrote:

> An attacker can only use the devices he has control over to 
> manipulate the forwarding plane in a way not corresponding to the 
> control plane state. (this is my definition of a "forwarding plane 
> attack").

> So since you can not *prevent* attacks on the forwarding plane in 
> other networks, the only defense we have here is *detection*.

ACK.

Note that even with the most secure of systems, you still will not be 
able to detect attacks, if they are sufficiently well co-ordinated. 
You can only /try/ detect them.

> the reverse path is being checked, but also the "forward path": did 
> the neighboring AS that sent the packet really got a route from you 
> for the destination address in the packet . I'm not aware of any 
> comparable check so far. With such a check you could recognize if 
> somebody installs static routes on his devices to send traffic via 
> you he is not meant to.

Right, you could introduce some kind of probing mechanism with which 
to verify the claims of UPDATEs received. Not sure how well this 
would scale though (probes would have to be ongoing..). ;)

> rely on the data in the control plane, we can not secure the 

Personally, I think this /might/ be the wrong way around. For so long 
as the integrity of the forwarding plane can not be verified, 
integrity-assurance mechanisms in the control-plane, even if 
'perfect', will remain easily subverted.

Susan Hares comment regarding profiles of users is really interesting 
too. A secure control plane on top of an unassured forwarding-plane 
may be useful security to some, useless to others.

That's not to say there wouldn't be value in such mechanisms, eg:

> I don't think this working group can to all the work in one step, 
> so securing the front door via securing the control plane makes it 
> at least harder for the attacker, since the effects on attacks on 
> the forwarding plane are much more limited: an attacker can only 
> attack traffic flowing "naturally" through his network. He can not 
> attack traffic in other parts of the internet where he is not 
> involved in the packet transport.

Right, narrowing scope of attacks down from "any BGP speaker" to 
"MITM AS" would have value, at least in an internet context.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Bachelor Chow. Now with flavor." -announcer

---

From: Stefan Mink <[email-masked]>
Date: Mon, 03 Oct 2005 02:10:35 +0200

Paul Jakma wrote:
> able to detect attacks, if they are sufficiently well co-ordinated. You 
> can only /try/ detect them.

can you give me an example, which attacks are not detectable?

Maybe we should first agree on a definition on "forwarding plane
attack" and collect types of attack. I fear that there is no common
sense yet. This already starts with the scope of "forwarding plane":
Do we talk about the forwarding plane of an entire AS, or is it the
forwarding plane of one specific router? Does the differentiation
matter?

>> What's still missing in my opinion is, that on a packet not only the 
>> reverse path is being checked, but also the "forward path": did the 
>> neighboring AS that sent the packet really got a route from you for 
>> the destination address in the packet . I'm not aware of any 
>> somebody installs static routes on his devices to send traffic via you 
>> he is not meant to.
> 
> Right, you could introduce some kind of probing mechanism with which to 
> verify the claims of UPDATEs received. Not sure how well this would 
> scale though (probes would have to be ongoing..). ;)

lets solve a problem first and then optimize, ok? ;)

    tschuess
              Stefan

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Oct 2005 09:55:16 +0100 (IST)

> can you give me an example, which attacks are not detectable?

The obvious case would be where all your neighbours conspire against 
you :). (Though, with sufficient higher-level security, such evil 
neighbours at least should not be able to trick you into thinking 
everything is still ok - you would think things had failed, but you 
wouldn't be able to distinguish between failure and an attack).

> sense yet. This already starts with the scope of "forwarding 
> plane": Do we talk about the forwarding plane of an entire AS, or 
> is it the forwarding plane of one specific router? Does the 
> differentiation matter?

I don't think so, I think a per-AS model is fine.

> lets solve a problem first and then optimize, ok? ;)

Sure.

Actually, I suspect a part of identifying acceptable requirements is 
to agree also on the acceptable costs. Security/cost tends to be an 
inevitable trade-off.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
There is brutality and there is honesty.  There is no such thing as brutal
honesty.