SIDR Charter

[Geoff Huston <gih@apnic.net>]

Hi,

please ignore my last posting - my mailbook and I are suffering from mutual 
confusion and I misdirected this note!!

:-)

  Geoff

-----------
Hi,

Alex and Bill have reported back on the IESG's consideration of the
proposed SIDR Charter.

They've asked us to see if we can submit a revised charter early next
week that addresses the following comments:

1. Para that says:


>  Both strict hierarchical and distributed non-
>  hierarchical trust systems are intended to be supported within
>  this framework.


   should also say that the reason for this is that they are both needed,
   each for a different deployment model.


2. The charter speaks about authentication, but not about authorization,
   and it should.

For reference the proposed charter is attached to this note

The next note will detail suggested changes to the proposed charter to
address these comments, for your consideration.

Regards,

    Geoff

===========================================================================

Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28 (V4)


Chair(s):
  TBD

Routing Area Director(s):
  Bill Fenner <fenner at research.att.com>
  Alex Zinin <zinin at psg.com>

Routing Area Advisor:
  TBD

Other Advisors:
  ? Security: TBD
  ? Routing: TBD

Mailing Lists:
  General Discussion: sidr at ietf.org
  To Subscribe: sidr-request at ietf.org
  In Body: (un)subscribe
  Archive: http://www.ietf.org/mail-archive/web/sidr/index.html

Description of Working Group:

  One of the areas of vulnerability for large scale Internet
  environments lies in the area of inter-domain routing. The basic
  security questions that can be posed regarding routing information
  is that of the validity of the address prefix being advertised, the
  validity of the originating Autonomous System Number, and the
  existence of an explicit permission from the address prefix holder
  to allow the prefix to be advertised from this origin. A related
  question concerns the level of trust than can be ascribed to
  attributes of a route object in terms of their authenticity,
  including consideration of the AS Path attribute..

  The Routing Protocol Security Group (RPSEC) has been chartered to
  document the security requirements for routing systems, and, in
  particular, to produce a document on BGP security requirements.

  The scope of work in the SIDR working group is to formulate an
  extensible architecture for an interdomain routing security
  framework. This framework must be capable of supporting incremental
  additions of functional components. As and when interdomain routing
  security requirements are completed within the RPSEC Working Group,
  these requirements will be defined within the SIDR framework as
  functional components of a secure interdomain routing system.

  The scope of work will include describing the use of certification
  objects for supporting the distribution of authentication
  information. Both strict hierarchical and distributed non-
  hierarchical trust systems are intended to be supported within
  this framework.

  The scope of work is limited to inter-domain router-to-router
  protocols only, for both unicast and multicast systems.

  The SIDR working group is charged with the following tasks:

  - Document an extensible interdomain routing security architecture

  - Document the use of certification objects within this secure
    routing architecture

  - Document specific routing functionality modules within this
    architecture that are designed to address specific secure routing
    requirements as they are determined by the RPSEC Working Group

Goals and Milestones:

April-06  Submit initial draft on inter-domain routing security
          architecture

May-06    Submit  initial draft on certificate objects to be used
          within this architecture

May-06    Submit initial draft on securing origination of routing
          information

Sept-06   Submit routing security architecture for publication as an
          Informational RFC

Nov-06    Submit description of use certificate objects by this
          architecture as an Informational RFC

Dec-06    Submit secure origination mechanism as a Proposed Standard

Jan-07    Evaluate progress, recharter with new goals or shutdown.