Subject: RE: [RPSEC] Consensus calls

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 11 Dec 2003 07:01:51 -0500

Russ,

Somehow, may be requirements should be done in the same working groups that
the protocol belongs to.

Form what your are saying to happen, it means that this WG should have the
expertize in the specific protocol that is being addressed and on top of
that the security experts. It might be easier to just add the security
experts to the original "owner" group.

This is just my two cents.

Abbie

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 11, 2003 6:52 AM
> To: Dondeti, Lakshminath [BL60:1A14:EXCH]
> Cc: Tony Tauber; [email-masked]
> Subject: Re: [RPSEC] Consensus calls
> 
> 
> 
> > I am just curious about item 2 below.  Do you mean just protocol 
> > specific threats and requirements, or solutions as well?
> 
> RPsec would take on requirements work, not solution work, 
> with this change. In other words, RPsec could provide the 
> requirements docs that other working groups would use to 
> build solutions in their specific protocols.
> 
> :-)
> 
> Russ
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
>

---

From: Russ White <[email-masked]>
Date: Thu, 11 Dec 2003 07:11:08 -0500 (EST)

> Somehow, may be requirements should be done in the same working groups
> that the protocol belongs to.
>
> Form what your are saying to happen, it means that this WG should have
> the expertize in the specific protocol that is being addressed and on top
> of that the security experts. It might be easier to just add the security

And if the protocol specific requirements are done in the protocol working
groups, then the protocol working groups will either need to attract or
build the security expertise this working group already has access to. It
makes more sense to me to build the requirements, at least, where we have
the security expertise, and then to hand those off to the protocol working
groups for action.

There is also some efficiency gained in "centeralizing" the work on
requirements documents, and other advantages.

BTW, this isn't a "non thought out" decision. It's been discussed for some
time among the working group chairs and AD's within routing for at least
three IETF's.

:-)

Russ

---

From: Tony Tauber <[email-masked]>
Date: Thu, 11 Dec 2003 14:32:01 +0000 (GMT)

On Thu, 11 Dec 2003, Russ White wrote:

> > Somehow, may be requirements should be done in the same working
> > groups that the protocol belongs to.
> >
> > Form what your are saying to happen, it means that this WG should
> > have the expertize in the specific protocol that is being
> > addressed and on top of that the security experts. It might be
> > easier to just add the security experts to the original "owner"
> > group.

If the security in established RPs is wanting, it's because their
"owner" groups have failed to add it.  Why?  Probably because "the
world has changed" to the point where security is more of a concern
than before; and/or because the security awareness wasn't in those
groups.  How might we "just add the security experts" to other groups?
Also see Russ's "efficiency" below.

> And if the protocol specific requirements are done in the protocol
> working groups, then the protocol working groups will either need to
> attract or build the security expertise this working group already
> has access to. It makes more sense to me to build the requirements,
> at least, where we have the security expertise, and then to hand
> those off to the protocol working groups for action.
>
> BTW, this isn't a "non thought out" decision. It's been discussed
> for some time among the working group chairs and AD's within routing
> for at least three IETF's.

Whatever people think of how effective RPSEC is now or may be in the
future, the guiding philosophy behind its establishment is as Russ
outlined above.  Part of the hope is, I believe, through
"cross-training" more security expertise will diffuse into the
protocol-specific groups and RPSEC will no longer be necessary.

Also, don't forget "operations" as the third leg of this stool besides
"security" and "routing".  To paraphrase Radia, perfectly good
security mechanisms can be misused through improper implementation
_or_ deployment.

Tony