Subject: RE: [RPSEC] RP Requirements Doc Comments...

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 19 Sep 2003 07:04:05 -0400

Russ,

Thanks for the feedback.
Overall the doc is a good start.

However, I have some concerns with the overall structure of the document.

First, the doc does not take advantage of the work/knowledge that was
acquired from the genral threat doc.

It seems to me that the approach must be slightly different.
The proper way to go (in my opinion) is to identify a list of threats that
we are trying to medigate.
Map this list to the class of protocols that we would like to address
Then put put a check list on the known methods to medigate the threats.
Prioritize threats that we will address (as applicabale to the protocols)
determine what in scope and what is not.

Then generate the list of requirements.

For example, talking about crypto sterngth without taking into consideration
what you are 
trying to protect or threats that you are trying to medigate is immature.

Otherwise, it seems to me that we will be trying to pull rabits out of a
magician hat.

These are my two cents (Canadian)

Abbie

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Wednesday, September 17, 2003 5:32 PM
> To: Routing Protocols Security Working Group
> Subject: [RPSEC] RP Requirements Doc Comments...
> 
> 
> 
> 2. General considerations
> 
> ....
> 
> 2.1 What MUST / SHOULD be protected ?
> 
>    Distribution of destination reachability information with 
> the required
>    policy considerations (QoS, trusted route, etc.) is what 
> is expected
>    from a routing protocol.
> 
> Possibly replace with:
> 
> Routing protocols act as distributed databases with very 
> quick synchornzation times. They are responsible for 
> distributing information about reachability to destinations 
> attached to the network, and the distribution of policies 
> about the available paths. Note that policy propogation 
> within a routing protocol which operates between 
> administrative routing domains, exterior gateway protocols, 
> is very difficult. This particular area of security is 
> fraught with difficulties making it next to impossible to 
> actually secure policy across multiple administrative domains.
> 
>    Reachability MUST be protected against unauthorized route deletions
>    and route additions. Note that these are high level operations;
>    aggregation, for instance, may result in the same consequences as
>    announcing new routes.
> 
> ....or the removal of some routing information, and the 
> policies attending that routing information.
> 
>    Route attributes (path information, metrics, trusted entity for the
>    forwarding of specific traffics) SHOULD also be protected.
> 
>    [TBD] We have to decide if route attributes require as much
>    protection as route existence, probably yes.  Note that 
> manipulation
>    of a routes associated attributes may achieve the same effects
>    as those resulting from addition / deletion.
> 
> I think you can mention this, but it's actually going to be 
> difficult to impossible to find any way of securing policies 
> within an EGP. Since each administrative domain can add 
> policies to a given route, anyone can essentially insert any 
> policy. The question: "Who's policy are we honoring" has to 
> be answered before we can begin to think about this. The 
> originator's policy? Or the AS we received the route from? Or 
> the AS that currently has the route? Or some other AS?
> 
>    Traffic overload may provoke DOS of routing negotiations, 
> while these
>    would help in balancing the high traffic. Forwarding is usually the
>    principal purpose of devices running routing protocols. In order to
>    achieve correctness of forwarding tables, means to enforce
>    availability of the medium to the routing protocol SHOULD be
>    provided.
> 
> You mean protection against traffic overload may provide 
> opportunities for DOS attacks? The wording is just backwards, 
> I think, in the first sentence.
> 
> 2.2 Transport Layer Considerations
> 
> ....
> 
>    A routing protocol designed to be, within certain extent, Transport
>    Layer independent, may provide options to activate inner security
>    features on-demand. Though such a flexibility would help avoiding
>    potential redundancy of functions with the Transport Layer and
>    adjusting performance requirements, such an approach is usually not
> 
> Do you mean "lower layer" when you say "inner?"
> 
>    desirable because of it's added complexity.
> 
> I don't understand what this sentence is saying, actually.
> 
>    The Tranport Layer may already grant the following properties:
> 
> "Grant" vs "provide?"
> 
>    o  Neighboring: a technology may provide a way to address adjacent
>       neighbors. The neighboring range in this kind of technology is
>       typically of one system away and relies on direct 
> mapping over the
>       Link Layer.
> 
> o Neighbor discovery and maintenance: A given transport layer 
> technology may provide a way to discover and communicate with 
> adjacenct devices participating in the routing domain (neighbors).
> 
> I don't know if you want to say anything about direct mapping 
> to the link layer--what would you mean by this? Something 
> like what IS-IS does? It doesn't seem to apply to OSPF, EIGRP, or BGP?
> 
>    o  Integrity: the Transport Layer may provide data 
> integrity. This is
>       insufficient to achieve security without proper means of
>       authenticating the system which provided the integrity proof in
>       the first place.
> 
> Replace with:
> 
> o Integrity: While the transport layer chosen by the routing 
> protocol designer may provide data integrity, most data 
> integrity techaniwues do not provide security. To provide 
> secure data integrity, the transport must use some form of 
> cryptographic hashing or signatures to validate data integrity.
> 
> Or something along these lines (?).
> 
>    o  Authenticity: if the underlying layer both provides authenticity
>       and integrity, many routing threats may be thwarted.  Further
>       considerations are required though, among which are 
> resistance to
>       replay, performance, Byzantine detection and robustness, etc.
> 
> I assume further requirements for integrity will be discussed 
> someplace else, later on? Otherwise, this is a bit skimpy.
> 
> 3. Cryptographic requirements
> 
> 3.1 Basic cryptographic requirements
> 
>    The following requirements are understood on a producer / 
> consumer of
>    the routing information basis. Forwarders of the 
> information may not
>    need to provide the following, if they do not modify the content of
>    messages.
> 
>       Integrity: data integrity is an obvious requirement.
> 
> Wht do you mean by integrity, though? Should you attempt to 
> define integrity in some way, or refer to a definition 
> provided in the security definitions draft?
> 
>       Anti-replay: this comes here mainly for protection 
> against active
>       attacks from subverted links, though this feature will also
>       provide added protection against natural duplication of packets.
>       Note that underlying layers may provide an unauthenticated
>       anti-replay feature, which would be of no use from a security
>       point of view.
> 
> Unless the actual data used for preventing replay is also 
> authenticated--I'd probably mention this. So, something like:
> 
> Anit-Replay: In order to routing protocol peering sessions on 
> subverted, or publicly accessible, links, the transport used 
> by a routing protocol SHOULD provide some form of anti-replay 
> protection. Note that if this anti-replay mechanism is not 
> part of a cryptographic system, or is not cryptographically 
> protected through integrity validation procedures,
> 
> 
> More later, as I get the chance to look over other parts.
> 
> :-)
> 
> Russ
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
>

---

From: Tony Tauber <[email-masked]>
Date: Mon, 22 Sep 2003 11:11:40 -0400 (EDT)

> Overall the doc is a good start.

I agree also.

> However, I have some concerns with the overall structure of the document.

That's fine. I pushed the authors to get something out for discussion
so that the structure/approach could be hashed out before too much
work was put into the meat.

> The proper way to go (in my opinion) is to identify a list of
> threats that we are trying to medigate.

Agreed, again.  Please take the lead from Sec. 3 (and 4?) of the
Threats doc if possible.

> Map this list to the class of protocols that we would like to
> address Then put put a check list on the known methods to medigate
> the threats.  Prioritize threats that we will address (as
> applicabale to the protocols) determine what in scope and what is
> not.

I like that idea also.  However, we probably want to _mitigate_ the
threats (or medicate them? .... 8-)

Tony

> For example, talking about crypto sterngth without taking into
> consideration what you are trying to protect or threats that you are
> trying to medigate is immature.
>
> Otherwise, it seems to me that we will be trying to pull rabits out
> of a magician hat.
>

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 23 Sep 2003 12:53:17 +0200

> Agreed, again.  Please take the lead from Sec. 3 (and 4?) of the

I also agree. However I think a routing protocol is designed for a
specific use, and this use is what determines the threats we need to
address. In fact, instead of mapping the selected threats list to the
class of protocols, I would do it the other way; That is:
	1 - Identify classes of protocols which map to different use
	(obvious classes are EGP / IGP)
	2 - By class, select threats that should/must/may be mitigated.
	3 - By class, mention threats that are significant but cannot be
	mitigated.
	4 - Present requirements which address threats common to all
	classes.
	5 - Present requirements which address threats in specific classes.
	6 - Eventually explain the how the requirements mitigates the
	threats (appendix)

	For point 1 and 2, considerations may be largely independent from
	the design of the protocol. However, this is no longer true from
	point 3 (Addressing security when using distance vectors is not the
	same pb than for link state, true ?). This makes the approach a bit
	difficult.

	Advices / comments on this proposed structure ?

-- 
Jean-Jacques Puig

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