Subject: [RPSEC] Threats Draft Issue 6: Section 4.7 Overload

From: Russ White <[email-masked]>
Date: Sun, 13 Jul 2003 22:09:53 -0400 (Eastern Daylight Time)

Sandy expressed some reservations about this section, stating that
overloading the control plane and overloading the data plane are two
seperate topics, and that routing protocol design could do little to help
in either of them.

Is there any concensus on this within the working group? I think we need
some more discussion, probably?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

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

---

From: Russ White <[email-masked]>
Date: Sun, 13 Jul 2003 22:36:47 -0400 (Eastern Daylight Time)

BTW--my initial comment was to drop this section entirely, since I don't
really see why we should even discuss data and control planes as concepts
within routing protocols. In fact, I think there are other sections within
the docuemt that discuss this, and I think they should all be dropped.

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Jul 2003 09:32:19 -0400

> the docuemt that discuss this, and I think they should all be dropped.

The only attack I can trivially think of has to do with DoS attacks
against the data plane that affect the control plane.  One example
is swamping the box with stuff that must be "process switched"
and thus potentially affecting the routing protocols.  The other
is saturating a link in such a fashion that control information can't
get through the link. 

A specific example of the latter is saturating your circuit to 99%
which causes your peering sessions to drop out.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 24 Jul 2003 15:55:01 +0200

> which causes your peering sessions to drop out.

Or to slow down in such a way that routing protocol convergence will
let enough time for the attacker to enjoy current / intermediate routes
state.

Anyway, I think we should agree on the fact that this has little to do
with the routing protocol. It would fit better in a document dealing
with security of routing devices operations.

-- 
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/

---

From: Alex Audu <[email-masked]>
Date: Fri, 25 Jul 2003 13:50:47 -0500

The fact that you can indirectly attack the control by attacking the data
plane
doesn't lessen the ramification that  it could be a threat to routing
functions. I think
this should be mentioned in the threat document.

Designers should be able to refer to the threat document to help them
develop
more threat-safe routing devices.

One benefit of separating Control and Data planes is that it may afford the
control plane somewhat of an isolated castle that could be more easily
shielded from outside attacks. One could do things like having separate
streams for data and control between control and forwarding planes. Also,
rate limiting could be used to improve
safety.

Regards,
Alex.

---

From: Russ White <[email-masked]>
Date: Fri, 25 Jul 2003 21:59:10 -0400 (Eastern Daylight Time)

> plane doesn't lessen the ramification that it could be a threat to
> routing functions. I think this should be mentioned in the threat
> document.
>
> develop more threat-safe routing devices.

I tend to diagree--this is at a lower layer, and we shouldn'tneed to
mention every possible lower layer attack. For instance, gaining access to
the console can also get you into a position to attack the routing system,
but I'm not certain we should include that in the threat analysis.

> One benefit of separating Control and Data planes is that it may afford
> the control plane somewhat of an isolated castle that could be more
> easily shielded from outside attacks. One could do things like having
> separate streams for data and control between control and forwarding
> planes. Also, rate limiting could be used to improve safety.

I don't think the conclusion that separating the data plane from the
control plane is much help in preventing port flooding attacks. The router
still has to receive packets in order to run a routing protocol; seperating
the data plane from the control plane isn't going to stop an attacker from
attacking thosse ports open for a router to receive packets.

Seperating the data and control plane is a good characteristic in many
situations, but as a method to provide security, I'm not certain it
actually helps anything (?).

:-)

Russ

---

From: Jean-Jacques Puig <[email-masked]>
Date: Sat, 26 Jul 2003 12:53:33 +0200

> this should be mentioned in the threat document.

Regarding the overloading threat section, I rally myself to this
position (extracted from the draft):
   This section combines overload of the control plane and the data
   plane (the control and data plane of the router, I presume, i.e., the
   routing protocol messages and the data traffic, not the control and
   data plane of the routing protocol itself as discussed in section
   2.1).

This, in order to state about which definition of the data plane we're
dealing with in this discussion.

The routing protocol (rp) design may help against the overload of the
rp's data plane part. But I do not see how it may prevent routing device
data plane overload (unless you insert in your routing protocol mesg to
negociate bandwith allocation between peers for the rp itself; but this
is the responsibility of another protocol IMO)

I think we should focus (in this draft) on direct attacks against the
rp.  I certainly agree that data plane overload threatens the routing
functions, but so does switching off the power supply of the device, or
cutting the fiber or hitting the device with a bat.

BUT I agree overload is a threat against routing functions and I agree
this kind of threats should be documented somewhere. Yet this draft is ,
IMHO, not the appropriate place, and that's why I talked about the
possibility of having a document dealing with the security of routing
devices.

> more threat-safe routing devices.

This is the whole pb: I don't think the threat document has the purpose
of helping in the development of devices, but of allowing proper
evaluation of current routing protocols and good design of future ones.

Because I wasn't sure about it, I had a look at the WG charter and felt
a bit confused: It introduces the need for documented routing security
requirements (which includes both our point of view), states the scope
is router-to-router protocols and that the document should benefit for
routing protocol designers, and eventually enounces task of the WG is
firstly to document threat models for routing systems. As I'm not native
English speaker, may be I misunderstood here.

As a conclusion, may be we should address the requirements for:

A threats document related to routing protocols
A threats document related to routing devices / systems

If needed, such documents may get merged in a single at the last minute.

Does the WG think it would be suitable ?

> rate limiting could be used to improve

I can only agree here, though I don't think it is directly related to
the intrinsec security of the rp.

--
Jean-Jacques Puig

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 27 Jul 2003 23:03:05 -0400

On Fri, Jul 25, 2003 at 09:59:10PM -0400, Russ White wrote:
> mention every possible lower layer attack.

Mostly, this is just a specific form of DoS attack.  It is 
very casually worth mentioning because an implementor may choose
to put some form of QoS into their data plane to guarantee that
control traffic makes it through.

> For instance, gaining access to

One can be done remotely, the other one cannot.

And no, sending in a ninja death squad to attack the actual hardware
doesn't count as a legitimately documentable threat.

> attacking thosse ports open for a router to receive packets.

As I'm sure you're aware, NOC's often keep an administrative ethernet
segment that is not on the forwarding plane of customer traffic.
This means that their customer links can be utterly saturated and 
otherwise unusable and yet the box may be administered through this
backdoor.

Control traffic could in some sense be done in a similar fashion.
The main thing that keeps us from doing this is the need to tightly
bind the circuit and the state of that circuit into the routing state.

A mechanism of some form that allowed a circuit of some form to
be partitioned such that it had guaranteed bandwidth for control
traffic would remove, or at least distance, the control plane from
a "data plane" DoS.

> actually helps anything (?).

I forget - exactly how did we choose to document DoS cases in the
document?  If all DoS is out of scope, then this is certainly
out of scope.  If not, it is worth considering - but not spending
a serious amount of time on.  To do so would tread very closely
on implementation details.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 28 Jul 2003 10:11:37 -0400 (Eastern Daylight Time)

> possibility of having a document dealing with the security of routing

Right.... The issue, to me, is not whether or not this is a legitimate
threat against the routing system, but rather we should include this sort
of a threat here?

I think Jeff has argued for mentioning it, but not going into great detail.
There may be some value in having a section where we mention things like
this, but don't go into detail. It would be analogous to the sections in
the BGP attack tree that talk about things "outside" the actual attack tree
as possible attacks, but it's not an actual attack that this specific
document goes into detail on.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2003 10:21:20 -0400

> I think Jeff has argued for mentioning it, but not going into great detail.

Basically:
"Denial of service and resource starvation are two attacks against
a routing system.  Unless the mechanisms used in these attacks
are capable of being dealt with by changes to the protocol, such
attacks are outside the scope of this document."

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 28 Jul 2003 10:27:44 -0400 (Eastern Daylight Time)

This sounds fine to me....

:-)

Russ

---

From: Jean-Jacques Puig <[email-masked]>
Date: Mon, 28 Jul 2003 16:41:14 +0200

> > attacks are outside the scope of this document."

Ok for me: this is a clear statement of that it is both a threat and
outside the scope of the doc.

-- 
Jean-Jacques Puig

---

From: Alex Audu <[email-masked]>
Date: Mon, 28 Jul 2003 10:30:31 -0500

Russ,  I am not sure if the console is a core part of a routing device.
So,..stretching that argument to include a console is a big stretch.

One way to attack the routing protocol is to slow it down by starving  it
of  processing cycles. If the forwarding and control functions are being
handled by the same processor, then the control can be directly affected by
flooding the ports with data. Separating the control decouples the
procesing cycles,..and improves the survivability of the control. How
effective that is depends on the design.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Mon, 28 Jul 2003 11:25:32 -0500

Hi Jean-Jacques,

I guess you are right about the fact that overload attacks may not reflect
accurately on the level of security  inherent in the routing protocol.  But I
believe
the job of the WG is to document the threats that contribute to the
problem space. Then let the designers take this document as input and worry
about the solution space for both routing protocol, and the routing device.

Regards,
Alex.

---

From: Russ White <[email-masked]>
Date: Mon, 28 Jul 2003 13:30:11 -0400 (Eastern Daylight Time)

So, could we build concensus around the text that Jeff proposed below? Or
does someone object to this, would like to change it, etc?

:-)

Russ