Subject: RE: [RPSEC] Draft Status....

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 23 Jul 2002 17:57:45 -0700

-----Original Message-----
From: Senthilkumar Ayyasamy [mailto:[email-masked]]
Sent: Monday, July 22, 2002 9:02 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RPSEC] Draft Status....

>Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP
>as their transport. Each type of transport has its own set of
>vulnerabilities.
  I accept your point that all the above listed protocols have their own 
list of vulnerabilities. As russ mentioned in one of his previous mails, we 
can have many documents relating to threat models for different routing 
protocol/routing types. I think there are some documents already on table( 
but mostly solution space which is not the goal of this working group but 
may provide some pointers.)

    But my concern is requirement document should be generic enough to cover

all issues be it mobility, unicast/anycast/multicast, routing algo. It 
should provide input to respective routing protocol WG for further work.

[Gregory] While being generic enough to cover all the issues that may arise
from mobility, unicast/anycast/multicast routing algo would be nice, some of
us have the sense that this will not be adequate to fulfill the goal of
enabling routing protocol designers to design secure routing protocols. As I
presented in Yokohama, we will likely need to slice it somehow into
sub-focus areas. How to slice it is the big question.

I have some queries:

1. Is there a need for separate security mechanism for routing and 
forwaring? Are their any tradeoffs ?

[Gregory] In a pure architectural framework sense, the routing protocols
make up part of the "control plane" of a network. If I understand you
correctly, the forwarding data is the application data, or the "data plane".
The world of large service network designers learned over the past 70 years
from SS7 and the PSTN that it makes sense to treat the Control Plane data as
separate from Data Plane data. I'm not recommending an actual physical
separation, or even a true logical separation between the two planes at this
point. But I am encouraging us to see the routing protocols as the Control
Plane, and to see the effort of securing that plane as a separate task from
securing the Data Plane. We may end up using some similar mechanisms (like
IPsec or such) where applicable.
 
2. whether we need to have end to end security mechanism or between  peers?

[Gregory] If by "end-to-end" you mean
"application-host-to-application-host," then from my thinking above I'd say
end-to-end is out of scope in this wg effort, and we ought focus on routing
peer to routing peer or within a routing group, in the case of
multicast-dependent protocols, like OSPF, RIP, PIM, etc.

-senthil

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 24 Jul 2002 18:59:12 -0700

Gregory,

> sub-focus areas. How to slice it is the big question.

Agree. Even though the model should be generic in a sense of not being
specific for a given protocol, it should still have enough details
for each class of a particular subsystem.

> forwaring? Are their any tradeoffs ?
...
>... But I am encouraging us to see the routing protocols as the Control
> securing the Data Plane.

Definitely.

> multicast-dependent protocols, like OSPF, RIP, PIM, etc.

My reading of this question was a little bit different, i.e, whether
we want to work on such issues as authenticity of reachability
announcements or their withdrawals vs just securing the transport.

My opinion is securing the transport connection is not enough,
and though particular protocol designers may choose to limit their
security mechanisms to transport integrity and authentication, this
WG should look further.

Alex

---

From: Russ White <[email-masked]>
Date: Thu, 25 Jul 2002 08:20:43 -0400 (EDT)

> Agree. Even though the model should be generic in a sense of
> not being specific for a given protocol, it should still have
> enough details for each class of a particular subsystem.

I think the difference in opinion here is in the way we are
looking at the threat models.... As a (simple, an probably
absurd) model, let's say we were to look at the "threat model of
an onion." Now, we could say that there are many types of onions,
and each one has a different threat model, or we could argue that
onions are all similar enough to have enough characteristics in
common so they can all share the same threat model.

This is where we are at the moment, and I can see valid concerns
on both sides. This is one reason why I think multiple threat
models can be valid and useful.

Beyond the obvious issue of what types of onions there are,
though, there are multiple other ways of looking at this problem:

-- What is the threat if an onion is used as a projectile? Then
the threat model becomes an issue of looking at things like onion
hardness, density, and maximum achievable velocity under various
conditions, and the effective range given the ballistic
coefiicient of an onion.
-- What if the threat model is approaching the onion as a poison
carrier? Then you must be concerned about the chemical
composition of the beast, and the ability of the onion taste to
cover the taste of particular classes of poisons.
-- What if the threat model is approaching the onion as a device
to make people cry? Then you would have an entirely different set
of problems and issues to address.

To me, each of these "threat models" is valid. Beyond the simple
concept of a threat model for each type of protocol, or a threat
model for other things, I see several threat models approaching
the problem from other viewpoints that are all valid, useful, and
would help in building a requirements doc.

And I hope my example is not too absurd to blow your thinking cap
off.

:-)

Russ

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

---

From: Alex Zinin <[email-masked]>
Date: Fri, 26 Jul 2002 22:13:33 -0700

Russ,

> And I hope my example is not too absurd to blow your thinking cap

Hey, liked the analogy a lot! :) I guess we should indeed
wait to see what the other model will give us...

Not trying to start an analogy argument, but it seems to me
that in your example, the difference between models is in
the set of characteristics that are considered in each, and,
potentially, one could have one model, with classification
of threats based of the onion's physical characteristics,
chemical substances, internal structure, etc. etc.

Anyways, we should probably really stop it here and wait
till we see the other doc :)

Alex

---

From: Tony Tauber <[email-masked]>
Date: Mon, 29 Jul 2002 17:53:52 -0400 (EDT)

On Fri, 26 Jul 2002, Alex Zinin wrote:

> Russ,
>
> > And I hope my example is not too absurd to blow your
> > thinking cap off.
>
> Hey, liked the analogy a lot! :)

I liked it also.

> chemical substances, internal structure, etc. etc.

One thing that occurred to me a little while ago is that there's the
system-level memory threats which can be realized by expanding an
attribute that's not (I think) of contstrained length like communities
or AS path in BGP or by de-aggregating explosively and causing memory
exhaustion as a result.

Limiting the length of all the attributes could help such a
vulnerability, but the scaling for raw number of routes and balancing
that with other demands in your embedded system seems sorta outside
the scope of a protocol spec.

I should say that I don't have experience actually coding any of these
protocols so I'm not sure how big a problem these things might be.

> till we see the other doc :)

Which other model?  I wasn't in Yokahama.  Is this reference related
to the meeting? (I might be dense - just back from vacation and
catching up on 1500 emails.)

Tony

---

From: Alex Zinin <[email-masked]>
Date: Mon, 29 Jul 2002 23:32:33 -0700

Tony,

> protocols so I'm not sure how big a problem these things might be.

Hmmm... On the one hand, this falls into the "robustness" category
(how many neighbors and routes can an implementation support, etc.),
on the other hand all implementations will have finite amount of
resources and such an attack can be mounted by compromising a trusted
router or by using some protocol vulnerabilities. Essentially, what
we're seeing here is a very generic dilemma (improvising):

  1) I have to maintain state created/requested by "others" in order
     ensure correct operation of the protocol (example: I have to
     have all LSPs from all routers in an area to properly calc
     the SPT and route correctly), assuming that everyone in the
     distributed system is cooperating

  But:
     
  2) Some "other" may not be cooperating (compromised) and inject too
     much state or there may be too many "others", so I just can't keep up.

Going back to my favorite list of subsystems :), this is the type
of threats specific to the DB maintenance subsystem, i.e., a router
may pass the transport-level authentication checks perfectly well,
but may still be dangerous.

So, yes, this is a threat. As far as addressing it--we're yet to
get to that point--the threat analysis is the first step.

> catching up on 1500 emails.)

In the first message in this thread Russ mentioned he knows at
least one other draft that might provide a different view at
the threat model.

Alex