Subject: [Sidr] Re: SIDR Charter

From: Geoff Huston <[email-masked]>
Date: Fri, 03 Feb 2006 10:46:44 +1100

Hi,

Here are the proposed edits to the SIDR Charter in response to the
IESG 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.

Proposed to add:

  The intended support of both forms of trust models
  is to allow for the use of this form of routing security 
  in diverse routing environments that have different underlying 
  trust characteristics.

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

Proposed to alter the charter description at 3 points:

1.  is that of the <authority and> validity of the address prefix being
    advertised
  
2.  and the existence <of authorization in the form> of an
    
3.  objects for supporting the distribution of authorization <and authentication>
    information  
  
The proposed revisied charter (with revision of the milestones also) is attached.

regards,

   Geoff
   
===========================================================================

Secure Inter-Domain Routing (sidr)
Last Modified: 2006-02-03 (V5)

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 authority and validity of the address prefix being
  advertised, the validity of the originating Autonomous System 
| Number, and the existence of authorization in the form 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 authorization and authentication 
  information. Both strict hierarchical and distributed non-
  hierarchical 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 form of 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:

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

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

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

Jan-07    Submit routing security architecture for publication as an
          Informational RFC

Mar-07    Submit description of use certificate objects by this 
          architecture as an Informational RFC

Apr-07    Submit secure origination mechanism as a Proposed Standard

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

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Feb 2006 19:44:45 -0500

Geoff,

I don't think we should  say "the authority and validity of the 
address prefix being advertised, ..."  because a prefix does not have 
authority per se. Similarly, the phrase "the validity of the 
originating Autonomous System Number..." sounds a bit odd, e.g., are 
any allocated AS numbers not "valid?"

How about:

"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, and whether the originating AS is accurately identified by 
the Autonomous System Number in the advertisement."

The use of the term "strict hierarchical" sounds a bit pejorative. 
How about just "hierarchic" and "non-hierarchic" when discussing 
trust models later in the charter?

Steve

---

From: Geoff Huston <[email-masked]>
Date: Fri, 03 Feb 2006 13:00:36 +1100

At 11:44 AM 3/02/2006, Stephen Kent wrote:
>Geoff,
>
>I don't think we should  say "the authority and validity of the address 
>prefix being advertised, ..."  because a prefix does not have authority 
>per se.

I was intending the sentence to parse with "authority" relating to "advertised"

>Similarly, the phrase "the validity of the originating Autonomous System 
>Number..." sounds a bit odd, e.g., are any allocated AS numbers not "valid?"

I'll defend those words - using unallocated AS numbers in are indeed 
invalid in the context of the public network, and the validity of the 
originating AS number is indeed an issue in this respect. i.e. while any 
allocated AS number is "valid",  any unallocated AS number is "invalid".

>information are  whether the originating Autonomous System is authorized 
>to advertise an address prefix by the holder of that prefix, and whether 
>the originating AS is accurately identified by the Autonomous System 
>Number in the advertisement."

I still think there is a residual issue of validity of the originating AS 
and the address prefix here. i.e. you'd like to know if the prefix or the 
AS are bogons irrespective of the authorities. Using your formulation, I'd 
add a a second clause to the statement, as below

"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, and 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.

Would this work for you?

>The use of the term "strict hierarchical" sounds a bit pejorative. How 
>about just "hierarchic" and "non-hierarchic" when discussing trust models 
>later in the charter?

sure

thanks Steve

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Feb 2006 11:53:15 -0500

At 1:00 PM +1100 2/3/06, Geoff Huston wrote:
>>address prefix being advertised, ..."  because a prefix does not 
>>have authority per se.
>

Oh, I didn't parse it the same way,

>>Similarly, the phrase "the validity of the originating Autonomous 
>>System Number..." sounds a bit odd, e.g., are any allocated AS 
>>numbers not "valid?"
>
>invalid in the context of the public network, and the validity of 
>the originating AS number is indeed an issue in this respect. i.e. 
>while any allocated AS number is "valid",  any unallocated AS number 
>is "invalid".

OK, good point.

>I still think there is a residual issue of validity of the 
>originating AS and the address prefix here. i.e. you'd like to know 
>if the prefix or the AS are bogons irrespective of the authorities. 
>Using your formulation, I'd add a a second clause to the statement, 
>as below
>
>  the originating Autonomous System Number in the advertisement, and 
>the validity of both the address prefix and the Autonomous System 
>Number.
>
>
>Would this work for you?

yes.

Steve