Subject: Re: [RPSEC] Charter Bashing...

From: Russ White <[email-masked]>
Date: Wed, 3 Apr 2002 20:00:36 -0500 (EST)

> I don't see why evaluating the security of current routing
> protocol security mechanisms should be out of charter. I
> think we should come up with threats and countermeasures
> generically, and then look at existing mechanisms in existing
> protocols and evaluate them. What threats do they answer? Are
> there weaknesses that can be fixed?

I think the main concern here is that we could easily rathole on
this, with the group spending a lot of time worrying about what
the current security options are, what they really mean, and what
their weaknesses are.

> But obviously, we do need this group. I think we need to
> approach the problem from both sides: we need to understand
> what routing security means (I tried to do some of that in my
> talk at the BOF). Then, how draconian are we willing to be?
> What kinds of solutions answer what kinds of threats and what
> are the costs of these solutions (e.g., CPU, configuration,
> bandwidth)? (and studying them generically, not worrying
> about shoehorning things into packet formats of existing
> protocols).

Okay--so the first part seems to be working on what security
really means. Do we want to address bona-fide attacks from inside
and outside the network? Do we want to include things which
aren't attacks, but rather things which are 'mistakes,' or
'configuration errors,' or 'implementation errors?' I think we
probably do, but if anyone has a different opinion.... 

By the way--I think there are at least two reasons to include
these things. The first is that if you are thinking about a new
mechanism, it makes more sense to make it cover more things
rather than fewer. The second is that I'm not even certain the
two problems--attacks vs other issues--are really seperable in a
way that is clean enough to try and address them
seperately. Solutions for the two are going to overlap, whether
we intend it or not.

> Then also approaching it from another angle: looking at what
> we have in existing protocols and evaluating them for minor
> tweaking (perhaps a mechanism doesn't avoid replay, but could
> with minor enhancements), as well as noting that an existing
> mechanism only solves some problems that might be called
> "routing security", and deciding whether the mechanism should
> be enhanced with mechanisms that solve more, or perhaps
> replacing that mechanism with more powerful mechanisms.

I think once we have frameworks and requirements, it might be
worth thinking about how the existing work fits in those
frameworks and requirements. My primary concern would be (as
above) going into long detailed discussions about current
methods, and (possibly even) having mud flung all over the place,
with no real product as the outcome. If that makes sense.

So, I suppose the real question is: Can we look at the existing
mechanisms, and compare them to the requirements and frameworks,
and see what we can learn from this excercise, without causing a
diminishing amount of work to actually be done? It's hard to say,
so I'll leave it for others to comment on.

:-)

Russ

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

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

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 3 Apr 2002 18:16:40 -0500 (EST)

I don't see why evaluating the security of current routing protocol
security mechanisms should be out of charter. I think we should
come up with threats and countermeasures generically, and then
look at existing mechanisms in existing
protocols and evaluate them. What threats do they
answer? Are there weaknesses that can be fixed?

Otherwise, I find the charter mystifying. If the assumption is
that existing mechanisms are perfect and should not be thought
about or improved upon, then we don't need this group.

But obviously, we do need this group. I think we need to approach
the problem from both sides: we need to understand what routing
security means (I tried to do some of that in my talk at the BOF).
Then, how draconian are we willing to be? What kinds of solutions
answer what kinds of threats and what are the costs
of these solutions (e.g., CPU, configuration, bandwidth)?
(and studying them generically, not worrying about shoehorning
things into packet formats of existing protocols).

Then also approaching it from another angle: looking
at what we have in existing protocols and evaluating them for
minor tweaking (perhaps a mechanism doesn't avoid replay, but could
with minor enhancements), as well as noting that an existing mechanism
only solves some problems that might be called "routing security",
and deciding whether the mechanism should be enhanced with mechanisms
that solve more, or perhaps replacing that mechanism with more
powerful mechanisms.

Radia

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 05 Apr 2002 10:35:12 -0500

I think one of the most important tasks of this group is to get a buy-in
from the router vendors (as many as possible).  For many vendors,
security-related functions are low-priority (and in my experience,
trying to convince a product manager of the need of security-related
features is a thankless/fruitless task :).

People in different routing-related WGs (both unicast and multicast) have
been aware of the need of "security".  However, between the routing community
and the security community there seems to be some differing understandings of
what "security" means. It would be good if this group could be the forum
where the two communities could meet.

I do agree with Radia that we should consider current routing protocol
security mechanisms.  This ranges from the simple manually-keyed MD5/HMAC
approaches to more comprehensive solutions like S-BGP.  Afterall,
the reason why some security people have devised solutions (like S-BGP) is
because they have studied the problem (for a number of years now).
Having their experiences and knowledge would be beneficial for everybody.

thomas
------

---

From: Russ White <[email-masked]>
Date: Sat, 6 Apr 2002 08:26:13 -0500 (EST)

> I think one of the most important tasks of this group is to
> get a buy-in from the router vendors (as many as possible).  
> For many vendors, security-related functions are low-priority
> (and in my experience, trying to convince a product manager
> of the need of security-related features is a
> thankless/fruitless task :).

Perhaps, but it's getting easier, I think. :-)

> People in different routing-related WGs (both unicast and
> multicast) have been aware of the need of "security".  
> However, between the routing community and the security
> community there seems to be some differing understandings of
> what "security" means. It would be good if this group could
> be the forum where the two communities could meet.

Agreed.... Maybe I should add some wording to the charter to this
effect.

Russ