Subject: [sidr] Last Draft: ReCharter text

From: Christopher Morrow <[email-masked]>
Date: Thu, 3 Mar 2011 22:39:24 -0500

Ok, so a lot (102 messages on-list) was said about the recharter text here:

= = = = = = = = =

Description of Working Group:

The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:

  * Is an Autonomous System (AS) authorized to originate an IP prefix
  * Is the AS-Path represented in the route the same as the path
       through which the route update traveled

The SIDR working group will take practical deployability into consideration.

Building upon the already completed and implemented framework:

  * Resource Public Key Infrastructure (RPKI)
  * Distribution of RPKI data to routing devices and its use in
       operational networks
  * Document the use of certification objects within the secure
       routing architecture

This working group will specify security enhancements for inter-domain
routing protocols.

The SIDR working group is charged with the following goals and
milestones:
ID Date      Pub Date
Mar 2011   Jan 2012  An overview of the RPKI and BGP Protocol changes
required for origin and path validation
Mar 2011   Jun 2012  A document describing threats to the routing system
Mar 2011   Jun 2012  A requirements document that  addresses these threats
Mar2011    Jan 2012  Document the BGP protocol enhancements that meet
the security requirements
Nov 2010    Jul 2011   draft-ietf-sidr-origin-ops
Mar 2011   Jul 2012   Operational deployment guidance for network operators
Jun 2011    Dec 2011 System and architecture design choices made in
the protocol and RPKI
Mar 2010    Mar 2012   draft-ietf-sidr-cps-irs
Mar 2010    Mar 2012   draft-ietf-sidr-cps-isp
Nov 2010    Jan 2012   draft-ietf-sidr-pfx-validate
Jan 2010    Jun 2011    draft-ietf-sidr-publication
Nov 2010    Jun 2011   draft-ietf-sidr-repos-struct
Nov 2010    Jun 2011   draft-ietf-sidr-roa-format
Feb 2011    Jun 2011    draft-ietf-sidr-rpki-rtr
Nov 2010    Nov 2011   draft-ietf-sidr-ltamgmt
Dec 2010    Oct 2011   draft-rgaglian-sidr-algorithm-agility
Jan 2011    Oct 2011   draft-ietf-sidr-ghostbusters
Jan 2010    Dec 2011   draft-ietf-sidr-keyroll
Jan 2010    May 2011  draft-ietf-sidr-arch
Jan 2010    May 2011  draft-ietf-sidr-cp
Jan 2010    May 2011  draft-ietf-sidr-res-certs
Jan 2010    Jun 2011  draft-ietf-sidr-roa-validation
Jan 2010    Jun 2011  draft-ietf-sidr-signed-object
Jan 2010    Jun 2011  draft-ietf-sidr-rpki-manifests
Jan 2010    Jul 2011  draft-ietf-sidr-rpki-algs
Jan 2010    Jul 2011  draft-ietf-sidr-rescerts-provisioning
Jan 2010    Aug 2011  draft-ietf-sidr-ta

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

o Of that text, I noticed no argument about the
dates/drafts/work-items, I noticed at least some
   discussion about the second vulnerability to address: (let's call
it a goal for now)

----------------------------------------------------------
 * Is the AS-Path represented in the route the same as the path
       through which the route update traveled
----------------------------------------------------------

A few folks noted that perhaps 'route' was not the right word here,
perhaps NLRI is. Using a wikipedia definition:
"Once a BGP session is running, the BGP speakers exchange UPDATE
messages about destinations to which the speaker offers connectivity.
In the protocol, the basic CIDR route description is called Network
Layer Reachability Information (NLRI). NLRI includes the expected
destination prefix, prefix length, path of autonomous systems to the
destination and next hop in attributes, which can carry a wide range
of additional information that affects the acceptance policy of the
receiving router. BGP speakers incrementally announce new NLRI to
which they offer reachability, but also announce withdrawals of
prefixes to which the speaker no longer offers connectivity."

This seems mostly correct, we don't actually want to secure something
that changes per router-hop (potentially) - next-hop, but we do care
about prefix/length/as-path. Taking that into account changes the goal
to:

----------------------------------------------------------
* Is the AS-Path represented in the NLRI the same as the path through
which the NLRI traveled
----------------------------------------------------------

o At least one respondent noted that some/all of the work here, as it
affects the
   BGP specification will have to be seen/etc by IDR, I don't think the charter
   changes as proposed preclude that. I believe the intent was to pass
along all
   changes to IDR to make sure they don't see issues with the changes. It's
   probably fair to also point out that the current IDR chair acks th
two goals listed,
   but still the material relevant to IDR should go there for
checkbox/changes/etc.

--------------------------------------------------------------------------------------------------------------------
Given the above the new charter reads:

= = = = = = = = =

Description of Working Group:

The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:

  * Is an Autonomous System (AS) authorized to originate an IP prefix
  * Is the AS-Path represented in the NLRI the same as the path
     through which the NLRI traveled

The SIDR working group will take practical deployability into consideration.

Building upon the already completed and implemented framework:

  * Resource Public Key Infrastructure (RPKI)
  * Distribution of RPKI data to routing devices and its use in
       operational networks
  * Document the use of certification objects within the secure
       routing architecture

This working group will specify security enhancements for inter-domain
routing protocols.

The SIDR working group is charged with the following goals and
milestones:
ID Date      Pub Date
Mar 2011   Jan 2012  An overview of the RPKI and BGP Protocol changes
required for origin and path validation
Mar 2011   Jun 2012  A document describing threats to the routing system
Mar 2011   Jun 2012  A requirements document that  addresses these threats
Mar2011    Jan 2012  Document the BGP protocol enhancements that meet
the security requirements
Nov 2010    Jul 2011   draft-ietf-sidr-origin-ops
Mar 2011   Jul 2012   Operational deployment guidance for network operators
Jun 2011    Dec 2011 System and architecture design choices made in
the protocol and RPKI
Mar 2010    Mar 2012   draft-ietf-sidr-cps-irs
Mar 2010    Mar 2012   draft-ietf-sidr-cps-isp
Nov 2010    Jan 2012   draft-ietf-sidr-pfx-validate
Jan 2010    Jun 2011    draft-ietf-sidr-publication
Nov 2010    Jun 2011   draft-ietf-sidr-repos-struct
Nov 2010    Jun 2011   draft-ietf-sidr-roa-format
Feb 2011    Jun 2011    draft-ietf-sidr-rpki-rtr
Nov 2010    Nov 2011   draft-ietf-sidr-ltamgmt
Dec 2010    Oct 2011   draft-rgaglian-sidr-algorithm-agility
Jan 2011    Oct 2011   draft-ietf-sidr-ghostbusters
Jan 2010    Dec 2011   draft-ietf-sidr-keyroll
Jan 2010    May 2011  draft-ietf-sidr-arch
Jan 2010    May 2011  draft-ietf-sidr-cp
Jan 2010    May 2011  draft-ietf-sidr-res-certs
Jan 2010    Jun 2011  draft-ietf-sidr-roa-validation
Jan 2010    Jun 2011  draft-ietf-sidr-signed-object
Jan 2010    Jun 2011  draft-ietf-sidr-rpki-manifests
Jan 2010    Jul 2011  draft-ietf-sidr-rpki-algs
Jan 2010    Jul 2011  draft-ietf-sidr-rescerts-provisioning
Jan 2010    Aug 2011  draft-ietf-sidr-ta

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

This I'll send along to the IESG shortly.

-Chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Mar 2011 14:49:33 +0900

> perhaps NLRI is. Using a wikipedia definition:

apologies, but i just don't have the copious free time to descend to
this level of nit picking.

i say ship it.

randy

---

From: Russ White <[email-masked]>
Date: Sat, 05 Mar 2011 10:39:53 -0500

>        through which the route update traveled

I'm a bit confused --what happened with the discussion around Joels'
wording? Is this supposed to be the final taking into account that
discussion? I would suggest that trying to prove how an update came to
be where it currently is isn't the underlying problem to be solved.
Perhaps something like:

* Is the AS-Path represented in the route a correct representation of
the path to reach the destination, and does the AS Path correctly
represent the intentions of the autonomous systems listed?

Though I know some folks are going to say, "you can't prove intentions,"
when you get down to it, when you say, "prove the path the update took,"
you are, in reality, saying, "prove that everyone in the AS path
intended to send the update," so these are the same thing.

I'm also not certain I agree with Randy that it's a "nit" to use NLRI
instead of "the update." The one is a bit of information, the other
seems to imply a packet --and there is no end to end "update packet" in
BGP --at least not that I know of. An update only exists point to point
between two speakers, I think (?).

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 5 Mar 2011 12:37:22 -0500

> be where it currently is isn't the underlying problem to be solved.

It seemed that discussion, while in the thread about the recharter was
actually about the reqs doc.

> between two speakers, I think (?).

that was why NLRI was used. (no end-to-end packet)

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 6 Mar 2011 17:02:51 -0500

Chris,

There is also this WG document which is missing in your list:
"Use cases and interpretation of RPKI objects for issuers and relying parties"
http://tools.ietf.org/html/draft-ietf-sidr-usecases-01

Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christopher Morrow [[email-masked]]
Sent: Thursday, March 03, 2011 10:39 PM
To: [email-masked]; [email-masked]; Adrian Farrel; Stewart Bryant
Subject: [sidr] Last Draft: ReCharter text

= = = = = = = = =

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

= = = = = = = = =

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

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

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 6 Mar 2011 22:24:47 -0500

> http://tools.ietf.org/html/draft-ietf-sidr-usecases-01

easy enough to add. thanks! (notethat I hadn't heard back from either
of the ADs yet, I expect they'll say something in the next few days)

-Chris

___________________________________

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 7 Mar 2011 15:58:23 +0200

On Mar 4, 2011, at 5:39 AM, Christopher Morrow wrote:
...
> perhaps NLRI is. Using a wikipedia definition:

I love Wikipedia, but the quoted definition is wrong, at least with respect to the definitions given in RFC 4271:

1.1.  Definition of Commonly Used Terms

...

   NLRI
      Network Layer Reachability Information.

   Route
      A unit of information that pairs a set of destinations with the
      attributes of a path to those destinations.  The set of
      destinations are systems whose IP addresses are contained in one
      IP address prefix carried in the Network Layer Reachability
      Information (NLRI) field of an UPDATE message.  The path is the
      information reported in the path attributes field of the same
      UPDATE message.

Given that what we're talking about securing is BGP, it would seem sensible to use BGP's terminology.  Given that, the text as written seems right to me:

or if you insist perhaps

----------------------------------------------------------
* Is the AS-Path represented in the route the same as the path through
which the NLRI traveled
----------------------------------------------------------

But if this is the biggest nit we have to pick then I'll agree with "ship it".

By the way, which Wikipedia article were you quoting, so I can think about fixing it in my CFT?

...
>   but still the material relevant to IDR should go there for checkbox/changes/etc.

Yes.  Speaking for myself I don't have a problem with progressing this work in SIDR for the time being given that there is energy and expertise to do it here.  We can reshuffle deck chairs in the future as seems warranted, and in any case should have review by both groups no matter which WG the work is done in.

--John

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Mar 2011 07:46:42 +0900

> I love Wikipedia, but the quoted definition is wrong, at least with
> respect to the definitions given in RFC 4271:

so edit it

randy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 7 Mar 2011 21:14:00 -0500

> I love Wikipedia, but the quoted definition is wrong, at least with respect to the definitions given in RFC 4271:

I looked for the best rfc definition, missed 4271 :(  In the end I was
looking for the set of terms closest to what would be expected in the
IDR/SIDR/routing-protocols-implementors world.

> Given that what we're talking about securing is BGP, it would seem sensible to use BGP's terminology.  Given that, the text as written seems right to me:

The original poster's note was an attempt, I think, to convey the fact
that a 'route' (prefix + path + attributes) was not actually whole
across all of the path. each bgp speaker it hopped through made some
judgment and added or subtracted bits to the 'route'.

NLRI seemed to capture just the prefix+path part of the 'route', which
ideally should not change at each hop (aside from having an AS added
to the path). The second form you have seems to keep that idea in
tact.

> But if this is the biggest nit we have to pick then I'll agree with "ship it".

yes... going to the AD's + list + housely now.

thanks!
-chris