[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
Secure Inter-Domain Routing (sidr)
Last Modified: 2005-11-28 (V4)
Routing Area Director(s):
Bill Fenner <fenner at research.att.com>
Alex Zinin <zinin at psg.com>
Routing Area Advisor:
? Security: TBD
? Routing: TBD
General Discussion: sidr at ietf.org
To Subscribe: sidr-request at ietf.org
In Body: (un)subscribe
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
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
- 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
May-06 Submit initial draft on certificate objects to be used
within this architecture
May-06 Submit initial draft on securing origination of routing
Sept-06 Submit routing security architecture for publication as an
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.