2.6.14 Secure Inter-Domain Routing (sidr)

NOTE: This charter is a snapshot of the 73rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2007-06-15

Chair(s):

Sandra Murphy <sandy@tislabs.com>
Geoff Huston <gih@apnic.net>

Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David Ward <dward@cisco.com>

Routing Area Advisor:

David Ward <dward@cisco.com>

Technical Advisor(s):

Steven Bellovin <smb@cs.columbia.edu>

Mailing Lists:

General Discussion: sidr@ietf.org
To Subscribe: sidr-request@ietf.org
In Body: 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
are whether the originating Autonomous System is authorized to
advertise an address prefix by the holder of that prefix, whether
the originating AS is accurately identified by the originating
Autonomous System Number in the advertisement, and the validity of
both the address prefix and the Autonomous System Number. 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. The SIDR working group will
develop security mechanisms which fulfill those requirements which
have been agreed on by the RPSEC working group. In developing these
mechanisms, the SIDR working group will take practical deployability
into consideration.

The scope of work will include describing the use of certification
objects for supporting the distribution of authorization and
authentication information. Both hierarchic and distributed non-
hierarchic trust systems are intended to be supported within this
framework. The intended support of both forms of trust models is to
allow for the use of this framework for routing security in diverse
routing environments that have different underlying trust
characteristics.

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:

Done  Submit initial draft on inter-domain routing security within this architecture
Done  Submit initial draft on certificate objects to be used within this architecture
Done  Submit initial draft on securing origination of routing information
Mar 2007  Submit routing security architecture for publication as an Informational RFC
May 2007  Submit description of use certificate objects by this architecture as an Informational RFC
Jun 2007  Submit secure origination mechanism as a Proposed Standard
Aug 2007  Evaluate progress, recharter with new goals or shutdown

Internet-Drafts:

  • draft-ietf-sidr-res-certs-09.txt
  • draft-ietf-sidr-cp-03.txt
  • draft-ietf-sidr-cps-irs-03.txt
  • draft-ietf-sidr-cps-isp-02.txt
  • draft-ietf-sidr-roa-format-02.txt
  • draft-ietf-sidr-arch-03.txt
  • draft-ietf-sidr-rescerts-provisioning-00.txt
  • draft-ietf-sidr-rpki-manifests-00.txt

    No Request For Comments

    Meeting Minutes


    Slides

    SIDR WG
    Matt Lepinski - Architecture and ROA format drafts
    Steve Kent - Updates to the RPKI Certificate Policy
    John Scudder BGP Prefix Origin Validation
    Robert Kistetleki - RPSL and RPKI