Subject: [RPSEC] Charter Update

From: Russ White <[email-masked]>
Date: Thu, 01 Dec 2005 13:23:27 -0500

Y'all:

We'd like to modify the charter to reflect our current progress of work, 
and ass some new things to it. Comments welcome before I send it off to 
the IESG. The one possibly new item that I'd like some thought on is if 
there's a place for this one:

Mar 06 Submit initial document discussing requirements for peering
relationship authorization and authentication mechanisms.

:-)

Russ

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

The lack of a common set of security requirements and methods for
routing protocols has resulted in a wide variety of security
mechanisms for individual routing protocols. Ongoing work on
requirements for the next generation routing system and future work on
the actual mechanisms for it will require well documented routing
security requirements.

The products of this working group will be used by routing protocol
designers to ensure adequate coverage of security in the future,
including well known and possible threats.

The scope of work is limited to router-to-router protocols for unicast
and multicast systems, and does NOT include host-to-router protocol
such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to
produce new or change the current security mechanisms in the existing
routing protocols.

The RPSEC working group is charged with the following tasks:

- Document threat models for routing systems

- Document security requirements for routing systems

- Document security analysis and requirements for specific routing
  protocols (e.g., OSPF, BGP)

- Provide a common area for discussion between security and routing
  experts on the topic of securing the routing system

Goals and Milestones:

Mar 06 Submit initial document discussing requirements for peering
relationship authorization and authentication mechanisms.

Mar 06 Submit BGP Attack-Tree analysis for publication as
Informational RFC.

Mar 06 Submit OSPF vulnerability analysis for publication as
Informational RFC.

Mar 06 Submit BGP security requirements for publication as
Informational RFC.

July 06 Submit initial document discussing security requirements in an
OSPFv3 mobile ad hoc environment

Oct 06 Evaluate progress, recharter with new goals or shutdown.
12,16c12,16
< The scope of work is limited to router-to-router protocols for unicast
< and multicast systems, and does NOT include host-to-router protocol
< such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to
< produce new or change the current security mechanisms in the existing
< routing protocols.
---
> The scope of work is limited to router-to-router protocols only for
> both unicast and multicast systems, and does NOT include
> host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a
> non-goal at this point to produce new or change the current security
> mechanisms in the existing routing protocols.
25c25
<   protocols (e.g., OSPF, BGP)
---
>     protocols (e.g., OSPF, BGP)
28c28
<   experts on the topic of securing the routing system
---
>     experts on the topic of securing the routing system
30c30
< Goals and Milestones:
---
> Possible Future Work
32,33c32,33
< Mar 06 Submit initial document discussing requirements for peering
< relationship authorization and authentication mechanisms.
---
> - Evaluate and document existing and proposed routing security
>     mechanisms with respect to established RPSEC requirements
35,47c35
< Mar 06 Submit BGP Attack-Tree analysis for publication as
< Informational RFC.
< 
< Mar 06 Submit OSPF vulnerability analysis for publication as
< Informational RFC.
< 
< Mar 06 Submit BGP security requirements for publication as
< Informational RFC.
< 
< July 06 Submit initial document discussing security requirements in an
< OSPFv3 mobile ad hoc environment
< 
< Oct 06 Evaluate progress, recharter with new goals or shutdown.
---
> - Recommend mechanism(s)
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Dec 2005 17:21:09 -0500

Russ,

I think the charter text looks OK, although the introductory sentence 
of you message had an amusing "s" -> "d: typo :-).

One comment about your suggestion for an additional work item:

"Mar 06 Submit initial document discussing requirements for peering
relationship authorization and authentication mechanisms."

I think it would be appropriate to focus on the authentication and 
integrity requirements here, rather than authorization. Presumably 
any authorization concerns can be addressed by using the 
authentication data for lookup in a local database, the exact nature 
of which might not require standardization.  But, if other folks 
think the authorization aspects of these peering relationships should 
be in scope, I'm OK with that too.

Steve