Subject: [RPSEC] Consensus calls

From: Tony Tauber <[email-masked]>
Date: Wed, 10 Dec 2003 05:08:14 +0000 (GMT)

Folks,

At the meeting in Minneapolis, the sense of the room was that there
was positive support for these proposals:

1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as
   a WG work item?

2) Should the RPSEC charter be amended to allow for the acceptance of
   protocol-specific work?  (Removing the sentence below should do that.)

   ++> It is also a non-goal at this point to produce new or change the
   ++> current security mechanisms in the existing routing protocols.

3) Should draft-convery-bgpattack-01.txt be accepted as a WG work item?

4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item?

Please respond with your opinions.

(See meeting minutes at http://ietf.org/proceedings/03nov/minutes/rpsec.htm
for more details if desired.)

Thanks,

Tony

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 10 Dec 2003 13:16:49 -0500

Hi,

I am just curious about item 2 below.  Do you mean just protocol 
specific threats and requirements, or solutions as well?

Lakshminath

---

From: Danny McPherson <[email-masked]>
Date: Wed, 10 Dec 2003 21:47:46 -0700

>
> No. This document is a hodge podge. It mixes the authors's solution 
> ideas with  requirements statements. It is very uneven in its 
> treatment of topics, and has numerous errors, e.g., characterizing 
> anti-replay as a crypto mechanism. It is not a generic requirements 
> document, as the title suggests.

Then provide some input to the authors.  Accepting it as a starting 
point
at least gets us moving forward (although I am impressed you presumably 
took
a moment to actually look at the document) -- as opposed to simply 
continuing
with fumbling over two solutions to problems we've yet to define.

I find the lack of interest/input and sentiment such as this very
annoying.

> no, see my response to #2 above.

So I'm confused.  What is it you believe we should be doing
AND how would you go about accomplishing it?

-danny

---

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

> 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

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 11 Dec 2003 12:52:57 +0100

On Wed, Dec 10, 2003 at 02:01:29PM -0500, Stephen Kent wrote:
> At 5:08 +0000 12/10/03, Tony Tauber wrote:
> >Folks,
> >
> ideas with  requirements statements.

True. The purpose of the current state of the document is to provide
input for discussion within the WG. Such a document cannot be directly
the reflect of a consensus that has not yet been discussed ! And setting
generic requirements is certainly as much a matter of reaching to a
consensus as of considering technical issues; may be even more. However,
current state does not preclude this document from being relevant wrt WG
charter.

> It is very uneven in its 
> anti-replay as a crypto mechanism.

Right. We had major TOC changes on this document, so one may consider
some parts are messy. However, we made these changes according to
overall feedback we received and I think this was the good way to go.
Also, we will certainly welcome your feedback on the different points you
raise, as we value your skills. Regarding anti-replay, I confess that I
have a natural tendency to bundle it with integrity and authentication,
as anti-replay alone is usually worthless; this is a pragmatic point of
view rather than a functional classification. If you think this
distinction is important, we will arrange sections differently. However,
I think that, *currently*, features usefulness should be valued and
discussed much more than the accuracy of their classification.

> It is not a generic requirements 

This is also a *draft*, a work in progress. If it is irrelevant with the
topics addressed by the WG, then it will get rejected sooner or later
and this will be perfectly normal. But better than just waiting for
this, you also have the power to influence its content and to guide it
with your views on the topic through your comments.

Whether this doc moves to a wg item or not, I will soon start successive
calls for feedback on the different parts. We have to move forward.

-- 
Jean-Jacques Puig

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Dec 2003 14:53:32 -0500

>    ++> current security mechanisms in the existing routing protocols.

To echo several other people here, letting RPSEC help produce requirements
as well as analyses of existing protocols will allow the group
to not only produce good requirements, but also suggest to other
working groups on how to improve their protocols.

However, I think that once things have gotten beyond analysis and
requirements that details should fall back to the individual protocol
WGs.  A relationship similar to the OPS group MIB-doctors would probably
be appropriate.

-- 
Jeff Haas 
NextHop Technologies