Subject: Re: [RPSEC] a link to my threat draft

From: [email-masked]
Date: Wed, 13 Nov 2002 09:50:29 -0500 (EST)

> I've been asked to put the draft I wrote up somewhere accessible.
>> Putting it on our ftp site was easier (bureaucratically) than putting
>> it on the web site, so you can reach it at:
>> ftp://ftp.tislabs.com/pub/rpsec/draft-murphy-threat-00.txt
>
>        The RPSEC working group is addressing security requirements of routing
>        protocols, not the security requirements of routers or of operations of
>        routing systems.  Therefore, this draft specifically does not address
>        threats to routers (hacking, denial of service flooding attacks, etc.)
>        or to specific routing protocol implementations (bugs, etc.).
>
>>From the charter:
>
>        The RPSEC working group is charged with the following tasks:
>
>        - Document threat models for routing systems
>        - Document security requirements for routing systems
>        - Provide a common area for discussion between security and routing
>          experts on the topic of securing the routing system
>

Good point, I should have chosen a different word than "system" since
it collides with the term used in the charter.  I'll change the draft
- how about "operational environment"?

When I see "routing system" in the charter, I think that means the
protocol and any databases it uses - not the protections on telnet
access to the routers or the quality controls on the router software
(or the presence of under floor water sensors or locks on the front
door or...).

I've obviously got one idea of the task of the working group that
is not shared by everyone on this list.

Here's another quote from the charter:

>The products of this working group will be used by routing protocol designers
>to ensure adequate coverage of security in the future, including well
>known and possible threats. 

There is no way that the routing protocol itself can ensure security
attributes of the router itself.  The routing protocols can only
ensure the security of the information they carry.  Expecting the
group to come up with security requirments that would help protocol
designers know how to avoid implementation bugs or logic bombs or
denial of service attacks (in data traffic flooding attacks) directed
at or through routers, or ensure the use of ingress/egress/prefix/AS_PATH
filters, etc., is not a winning strategy.  The routing protocols can't
protect those features.

The charter as written says that we're supposed to help those who are
designing protocols, not those who are trying to operate ISPs.  The
two might be coincident in BGP but they aren't coincident in other
routing protocols. Obviously the security for the operational
environment (hey, that almost works!) will effect the ability to route
traffic correctly in any routing protocol.  But the security of the
operational environment can't be protected by the routing protocol.
So the protocol designers can't be expected to meet security
requirements that relate to the operational environment.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 16:12:06 +0100 (CET)

On Wed, 13 Nov 2002 [email-masked] wrote:

> attributes of the router itself.

That's true, but a routing protocol can impose restrictions on a router
that make the router less secure. For instance, whithout reading the
RFC, I think a BGP router is required to use the same address for the
actual EBGP session as for the next hop (ignoring some not very ordinary
cases). This means the BGP session needs to live on an IP address that
is visible to the world, which makes all sorts of attacks easier and/or
protecting against them harder.

Also, something requiring sensitive private keys to be stored on a
router is a risky proposition, given that routers aren't always easily
physically secured: they must be present where the traffic is, and can't
always be moved to places that are secure. So maybe the protocols should
have provisions to be able to separate the location where forwarding
happens from the location where signatures are generated. Or maybe not.
But we should at least consider these questions.

> Expecting the

How can we know this before we discuss it?

At the very least protocol designers shouldn't create new holes, which
means they must be aware of existing ones.

Iljitsch

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2002 15:58:19 -0500

At 4:12 PM +0100 11/13/02, Iljitsch van Beijnum wrote:
><SNIP>

security protocol designs often do not address the question of the 
level of assurance associated with an implementation, although this 
is an important system security issue. for example, the statement 
above re the dangers of storing private signature generation keys in 
routers is relevant to system security, but is also an observation 
based on a particular notion of an implementation. if one anticipated 
the need to store crypto keys in a router, it can be done very 
securely with current crypto chip technology, for example.

Steve