Subject: Re: [RPSEC] Charter Bashing... (fwd)

From: Russ White <[email-masked]>
Date: Wed, 3 Apr 2002 19:50:48 -0500 (EST)

Sorry--having mailer problems.... So I'm forwarding this to the
list manually.

:-)

Russ

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

---------- Forwarded message ----------
Date: Wed, 3 Apr 2002 18:16:40 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [RPSEC] Charter Bashing...

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

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