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

From: Russ White <[email-masked]>
Date: Wed, 17 Sep 2003 17:31:39 -0400 (Eastern Daylight Time)

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 10:50:43 -0400 (EDT)

I'm working on my own list of comments, but also want to respond to
what others have written.  See below:

On Wed, 17 Sep 2003, Russ White wrote:

>    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:
>
> synchornzation times.

Is that always true?  Is RIP a distributed database?  I don't get that
RIP routers' view must be synchronized to work.  Which is not to say
they can just disagree w/o care and still have things work right.

> 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.

Certainly a worthwhile point.  Could be a SHOULD or MAY?

>    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.
>
>    Route attributes (path information, metrics, trusted entity for
>    the forwarding of specific traffics) SHOULD also be protected.
>
>    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?

Again, perhaps MAY to at least acknowledge some desirability.

>    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
>

It seems that what is meant is "internal to the protocol;
transport-layer agnostic".  Do you want "may" to be "MAY"?

>    o  Integrity: the Transport Layer may provide data integrity.
>    This is insufficient to achieve security without proper means of

Perhaps all of that is over-specified?  Should the requirement be
described as the need to provide for data integrity, authenticity,
etc. as mitigation to threats outlined in the Threats document?
Could go on to describe how such services may be imparted by the
transport layer but include details as to how that is to be done with
the given transport features.

>       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.

What do you have in mind in that last sentence?  Any examples?

> authenticated--I'd probably mention this.

Similarly, I'm not enough of a security geek to know if there are
non-cryptographic or non-authenticated ways of providing anti-replay
protection.

> So, something like:
> subverted, or publicly accessible, links,

Remember, all links should be considered vulnerable to subversion so
the "publically accessible" serves only as an additional caveat.
People shouldn't think "well, it's not "publically accessible"
(whatever that means) so foo isn't needed".

> the transport used by a routing protocol SHOULD provide some form of
> anti-replay protection.

Could we say that the protocol MUST be resistant to replay attacks and
perhaps go on to say that such protection could be provided w/in the
protocol (eg. some kind of global sequence number hash? just an idle
thought) or within the transport layer.  Come to think of it, if the
transport layer is not an end-to-end thing (like TCP) but a hop-by-hop
method (like IP), the problem may get stickier, especially if the
forwarders are also expected to act on the update (eg. increase
metric).

> Note that if this anti-replay mechanism is
> not part of a cryptographic system, or is not cryptographically
> protected through integrity validation procedures,

Sentence fragment?

Tony

---

From: Russ White <[email-masked]>
Date: Mon, 22 Sep 2003 15:11:43 -0400 (Eastern Daylight Time)

> RIP routers' view must be synchronized to work.  Which is not to say they
> can just disagree w/o care and still have things work right.

Yes, even though the databases might not synch, a routing protocol is still
a distributed database, essentially.

> Certainly a worthwhile point.  Could be a SHOULD or MAY?

I think so.... MAY might be reasonable. There are conditions under which a
routing system could actually validate these sorts of things, but I think
another draft is shortly forthcoming which will explain this in greater
detail (figure wednesday of this week).

> Again, perhaps MAY to at least acknowledge some desirability.

Yep, that would work....

> It seems that what is meant is "internal to the protocol; transport-layer
> agnostic".  Do you want "may" to be "MAY"?

I'm not certain--I just wanted to make certain we define what we mean when
we say "inner" here.

> described as the need to provide for data integrity, authenticity, etc.
> as mitigation to threats outlined in the Threats document? Could go on to
> describe how such services may be imparted by the transport layer but
> include details as to how that is to be done with the given transport
> features.

It should probably follow the threats doc better....

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2003 15:25:15 -0400

My apologies for coming in mid-conversation, but:

> a distributed database, essentially.

Sort of. A routing protocol is a way of distributing information that
is used to determine reachability.  A distributed database is one
way to do that, like the LSDB based protocols.  RIP and BGP are
"routing by rumor" to borrow someone elses words.

At best, in RIP and BGP, you have the portion of your neighbors database
that they use, but you don't have a picture of the entire network.
This changes the attack spaces.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 22 Sep 2003 15:28:55 -0400 (Eastern Daylight Time)

> Sort of. A routing protocol is a way of distributing information that is
> used to determine reachability.  A distributed database is one way to do
> that, like the LSDB based protocols.  RIP and BGP are "routing by rumor"
> to borrow someone elses words.
>
> that they use, but you don't have a picture of the entire network. This
> changes the attack spaces.

Well, it's a loosely syncrhonized database. What else would you
characterize it as? It's providing reachability information (data in the
form of a table) to a group of peers (distributed).

Again, loosely, but there's no other characterization for it, unless you
want to classify it as some completely new type of application.

And, btw, link state protocols aren't so pure as you might think. When you
hit an area or routing domain border, the databases stop synch'ing even in
link state protocols.

:-)

Russ

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 23 Sep 2003 15:06:51 +0200

> want to classify it as some completely new type of application.

	It may be difficult to speak of a distributed database, even with
	taking into considerations a loose synchronization; A distributed
	database must achieve consistency conditions and the knowledge of
	all local parts should help rebuilding the distributed information
	with few incoherences. Local routing databases have no requirements
	to be consistent with the other parts of the system, and may
	effectively not be.
	
	At best, they are correlated databases; these databases are built
	with knowledge of direct neighbors and of local networks (local
	part), remote views of the other networks (remote part) and local
	configuration directives (config part). Attacks may affect directly
	or indirectly any of these parts. Yet I agree the concept of a
	distributed routing database is very convenient to get a quick
	understanding of most issues (like, hum, underclaiming ;).
	
	Finally, local databases are merely 'views' of the topology and
	routers observers with deforming glasses and deforming megaphones:
	It is hard to tell what the original object is only with these
	views.

	So I would avoid speaking of a routing protocol as a distributed
	database, moreover the final running code should not be confused
	with a data storage.

-- 
Jean-Jacques Puig

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2003 15:38:19 -0400

> hit an area or routing domain border, the databases stop synch'ing even in

I think my quibble is with the word "distributed".  RIP et al are
only "distributed" in the sense that I tell you, you tell someone else.
However, you tell me what you have and use not what someone else told you.
Your example of the link-state protocols serves as a good example.
To carry the example further, I tell you, you just pass along what I
tell you and so on until it reaches a boundary.  Everyone then uses
the information.

What this alludes to is a scope of trust.  In RIP and BGP, we are
expected to trust that the person directly adjacent to us has
trustworthy information.  In OSPF and ISIS, we have to trust that
the information is flooded through the domain correctly.  

None of this changes our security issues, but it does mean we should
take some care to make sure that we're talking about the scope of
the issue within the proper context.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 23 Sep 2003 16:13:34 +0200

> > > received the route from? Or the AS that currently has the route? Or

	I agree EGP security is an interesting challenge and this will need
	long discussion. But we should take care that the whole document
	does not fall exclusively on this topic. This is why I need more
	feedback about the doc structure. Hot-Topics are expected to be
	EGPs, distance vector protocols and possibly the confidentiality
	requirement. The main difficulty is that there are several ways to
	classify RPs, and that each classification underlines different
	security issues.

> I'm not certain--I just wanted to make certain we define what we mean when

	Sorry; "built-in" is meant here.

> It should probably follow the threats doc better....

	Agree. This will change.

-- 
Jean-Jacques Puig

---

From: Tony Tauber <[email-masked]>
Date: Tue, 23 Sep 2003 10:53:20 -0400 (EDT)

On the topic of "EGP issues, including policy", I'd like to see if we
might set it (really BGP) off to the side a bit for the time being as
I think that inter-domain BGP as it's used today is kind of a special,
degenerate (not in the pejorative sense) case of a routing protocol.

If we think of a routing protocol fundamentally as a way to build a
functional network through distribution of reachability information,
would that allow us to make some general requirements and put
inter-domain policy in a different section?  Just tossing it out there.

Tony

On Tue, 23 Sep 2003, Jean-Jacques Puig wrote:

> 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 ?
>·
>·

On Tue, 23 Sep 2003, Jean-Jacques Puig wrote:

> > > > 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?
>
> 	I agree EGP security is an interesting challenge and this will
> 	need long discussion. But we should take care that the whole
> 	document does not fall exclusively on this topic. This is why
> 	I need more feedback about the doc structure. Hot-Topics are
> 	expected to be EGPs, distance vector protocols and possibly
> 	the confidentiality requirement. The main difficulty is that
> 	there are several ways to classify RPs, and that each
> 	classification underlines different security issues.

---

From: Russ White <[email-masked]>
Date: Tue, 23 Sep 2003 11:22:36 -0400 (EDT)

> might set it (really BGP) off to the side a bit for the time being as I
> think that inter-domain BGP as it's used today is kind of a special,

Inter-domain could be put in a different document--which is probably the
right long term solution.

My original point was not to bring BGP specifically into the picture, but
to illustrate that making "securing the path" a requirement is problematic.
EGPs are the easiest place to illustrate this, but I also believe it to be
true in all distance vector protocols, and link state protocols once they
pass over an area or l1/l2 edge.

So, let's not worry about the EGP specific part, but rather on this not
being a requirement we can actually specify, perhaps (?).

:-)

Russ