Subject: [sidr] Comment on draft-ietf-sidr-roa-validation-05

From: "John G. Scudder" <[email-masked]>
Date: Sat, 3 Apr 2010 20:39:31 -0400

Geoff and George,

I noticed the following in Section 2 of draft-ietf-sidr-roa-validation-05:

   A route's "origin AS" is the final element of the route object's
   AS_PATH attribute.  If the final AS_PATH element is an AS Set,
   indicating that the route is an aggregate, then the origin AS is
   taken as the AS component of the AGGREGATOR attribute [RFC4271].  In
   the case where there is an AS Set as the final AS_PATH element and no
   AGGREGATOR attribute is present then the origin AS is the AS
   immediately preceding the AS Set in the AS_PATH, and if there is no
   such AS then the route's origin AS cannot be determined.

Granted this is a corner case, but nonetheless I can't see what the reason would be for considering an intermediate AS (albeit the first one contained in an AS_SEQUENCE) to be the origin.  I suggest revising as follows: Consider the origin AS to be the contents of the AS_SET if it's a singleton set.  Otherwise the origin cannot be determined.

Given that it's a corner case, you could also cut right to the chase and just call it undetermined if the path starts (or ends, in your parlance) with an AS_SET, period.

--John

---

From: Randy Bush <[email-masked]>
Date: Sun, 04 Apr 2010 10:12:31 +0900

> Given that it's a corner case, you could also cut right to the chase
> and just call it undetermined if the path starts (or ends, in your
> parlance) with an AS_SET, period.

if the originating asn is a set, the prefix is 'matched' by a roa, yet
there is no aggregator, i might consider it invalid.  

if the originating asn is a set, the orgin asn has an is an aggregator,
but it is not for a 'matching' roa's asn, i might consider it invalid.

randy

---

From: Geoff Huston <[email-masked]>
Date: Sun, 4 Apr 2010 19:24:31 +1000

> Given that it's a corner case, you could also cut right to the chase and just call it undetermined if the path starts (or ends, in your parlance) with an AS_SET, period.

Thanks for this comment John. As a background here I had performed a brief
search through what I though was the obvious RFCs and related drafts to
find a definition of the "Origin AS" and came up with nothing I could
readily reference in this draft, so I found that I had to provide a
workable definition of an "origin AS".

The definition as stated in the draft is an uncomfortable hybrid in so far
as it conflates an originator with an aggregator, and in the light of
your comments, thats probably a step too far.

So how about I take your advice and cut to the chase with:

 "A route's "origin AS" is the final element of the route object's
  AS_PATH attribute.  If the final AS_PATH element is an AS Set,
  indicating that the route is an aggregate, then the origin AS
  cannot be determined."

Does that work?

kind regards,

  Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 4 Apr 2010 23:22:46 -0400

Geoff:
George:

Are you leaning towards an "Invalid" or "Unknown" for the decision
when an AS set is found for the origin AS in an update?
I think when we had a discussion on this topic long time ago,
the thinking was that we should try to discourage the usage
of AS sets. I am trying to figure if that meant calling the 
update "Invaid" in this situation?

Sriram 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Geoff Huston [[email-masked]]
Sent: Sunday, April 04, 2010 5:24 AM
To: John G. Scudder
Cc: [email-masked]; [email-masked]
Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05

Does that work?

kind regards,

  Geoff

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

---

From: Danny McPherson <[email-masked]>
Date: Sun, 4 Apr 2010 22:47:21 -0600

> update "Invaid" in this situation?

Of ~344k prefixes in the current routing system:

Today:
 o 61 prefixes with AS_SETS
 o 50 only include a single AS in the set
 o only 48 different sets appear
 o 1 includes only 4 occurrences of the same AS 
 o 1 includes 4 occurrences of the same AS and an IANA DSU AS
 o 5 of those have an origin code of incomplete

In 2005: 
 o 45 prefixes with AS_SETS
 o 31 only include a single AS in the set
 o only 39 different sets appear
 o 1 includes a unique AS and an IANA DSU AS 
 o 4 with incomplete origin code

So, one couple make an assumption that only 9 of these have any
chance of being an problem today, and it might well not be an issue 
-- unless you're one of those folks, of course.

As long as the spec supports it and people use it, we 
need to, methinks...

-danny

---

From: Randy Bush <[email-masked]>
Date: Mon, 05 Apr 2010 14:40:53 +0900

>  o 4 with incomplete origin code

what do you mean incomplete origin code?  AGGREGATOR or igp flag?

how many in the originating position, i.e. the first on the as-path?
i think that is the issue here.

but 33% growth in five years is a major market!  :)

randy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 5 Apr 2010 17:34:05 +1000

> update "Invaid" in this situation?

Hi,

Given that I am assuming that in the case of a route with an 
AS Set the origin AS is unable to be determined, then if a 
valid ROA exists where the address prefix in the route object 
"matches" the prefix in the ROA, then outcome of the validation 
operation would be "invalid" within the scope of the semantics 
of route object validation as specified in section 2 of the 
roa-validation  draft(*). And IF no valid ROA exists where the 
address prefix in the route object "matches" the prefix in the 
ROA, then outcome of the validation operation would be "unknown", 
again by application of the same pseudo-algorithm specified in 
that draft (*).

regards,

   Geoff

* to quote the draft:

    Route validation is defined by the following procedure:
      
      1.  Select all valid ROAs that include a ROAIPAddress value that
          either matches, or is a covering aggregate of, the address
          prefix in the route.

      2.  If the set of candidate ROAs is empty then the validation
          procedure stops with an outcome of "unknown".

      3.  If any of the selected ROAs has an asID value that matches the
          origin AS in the route, and the route object's address prefix
          matches a ROAIPAddress in the ROA (where "match" is defined as
          where the route object's address precisely matches the
          ROAIPAddress, or where the ROAIPAddress includes a maxLength
          element, and the route's address prefix is a more specific
          prefix of the ROAIPAddress, and the route's address prefix
          length value is less than or equal to the ROAIPAddress
          maxLength value) then the validation procedure stops with an
          outcome of "valid".

      4.  Otherwise, the validation procedure stops with an outcome of
          "invalid".

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 05 Apr 2010 10:01:06 +0200

> Of ~344k prefixes in the current routing system:
[...]
> As long as the spec supports it and people use it, we

I disagree with this. I think that spending hours and hours on specifying, 
debating, coding, testing, etc. a feature that is used in 0.02% (or 0.003%, 
depending on how you count) of the cases is not a good investment, imo.

Such an underused feature will not have a well tested codebase, with all 
possible bugs ironed out, which is a recipe for security problems.

Robert

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 Apr 2010 06:42:04 -0600

> what do you mean incomplete origin code?  AGGREGATOR or igp flag?

I mean the ORIGIN attribute (i.e., INCOMPLETE v. EGP v. IGP).

> but 33% growth in five years is a major market!  :)

So, actually, if you were to exclude the ones that have only a 
single AS in the AS_SET, there were 14 in 2005 and are only 11 now, 
so it's actually a decrease in the last 5 years.

As for the ones that have a single AS in the AS_SET, I'd venture 
a guess that they're not necessarily intentional, but instead are
simply an artifact *OS configuration mechanics (e.g., 
'aggregate-address ... ... as-set').

-danny

---
as-sets.txt (20100404)

 <count,set,origin>

   1 {14083} i
   1 {14707} i
   1 {16678} i
   1 {17348} i
   1 {17378} i
   1 {18669} i
   1 {19636} i
   1 {20251} i
   1 {209,25729} i
   1 {21135,49476} i
   1 {22620} i
   1 {23468} i
   1 {23491} i
   1 {25019,41426} ?
   1 {25576} i
   1 {2561} ?
   1 {2561} i
   1 {25784} ?
   1 {25846} ?
   1 {25912} i
   1 {26262} i
   1 {2732} i
   1 {2764} ?
   1 {2764} i
   1 {28571} i
   1 {32941} i
   1 {33395} i
   1 {34037} i
   1 {3491,15412,19710} i
   1 {35821,35821,35821,35821} i
   1 {35970} i
   1 {36647} i
   1 {40986} i
   1 {45514,45514,45514,45514,65081} i
   1 {4558,30994,33770} i
   1 {46124,46136} i
   1 {47798} i
   1 {6127} i
   1 {6556} i
   1 {8002,15412} i
   2 {11060,12262} i
   2 {25784} i
   2 {32734} i
   2 {32885} i
   2 {40616} i
   2 {6877} i
   3 {20148} i
   6 {4237} i

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 Apr 2010 06:52:23 -0600

On Apr 5, 2010, at 2:01 AM, Robert Kisteleki wrote:

> 
> I disagree with this. I think that spending hours and hours on specifying, debating, coding, testing, etc. a feature that is used in 0.02% (or 0.003%, depending on how you count) of the cases is not a good investment, imo.
> 
> Such an underused feature will not have a well tested codebase, with all possible bugs ironed out, which is a recipe for security problems.

My point was, it's all about perspective.  Whether you like it or not, 
not accommodating those networks when adding new capabilities, when 
those routes are perfectly legitimate (i.e., within spec of a standards 
track document) and work just fine today, is inappropriate.  

As I've stated before, if we do things in SIDR that introduce new 
constraints on what and how people are doing something today that's
completely within the bounds of legitimacy, then we ought to have a 
darn good reason to do so.

That said, it might be less resource intensive to just contact those 
folks originating AS_SETs and convince them they don't need'm -
assuming they don't.

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 5 Apr 2010 14:28:57 -0400 (Eastern Daylight Time)

> track document) and work just fine today, is inappropriate.

There's also the point to be concerned about, which is defining the 
validation of BGP routes to handle an AS_SET origin, to avoid creating a 
way for an attacker to counter the validation check.

No matter how few times the feature is used in practice, the feature 
exists in BGP and in the implemented code.  Not used in practice does not 
mean it could not be used in malice.

So, for a wild example, suppose the validation check looked to see if one 
single AS in the origin AS_SET matched a valid ROA for the prefix, and 
passed the BGP route as valid.  That would give a malicious person a way 
to ensure that their bogus route would be accepted.  If on the other hand, 
the validation code looked to see if all ASs in the AS_SET matched a valid 
ROA, that might break legitimate uses.

We need a defined way to deal with AS_SETs that doesn't afford 
opportunities for the malicious source while still permitting either the 
accidental or the rare intentional use.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 Apr 2010 12:37:31 -0600

On Apr 5, 2010, at 12:28 PM, Sandra Murphy wrote:

> There's also the point to be concerned about, which is defining the validation of BGP routes to handle an AS_SET origin, to avoid creating a way for an attacker to counter the validation check.
> 
> No matter how few times the feature is used in practice, the feature exists in BGP and in the implemented code.  Not used in practice does not mean it could not be used in malice.
> 
> So, for a wild example, suppose the validation check looked to see if one single AS in the origin AS_SET matched a valid ROA for the prefix, and passed the BGP route as valid.  That would give a malicious person a way to ensure that their bogus route would be accepted.  If on the other hand, the validation code looked to see if all ASs in the AS_SET matched a valid ROA, that might break legitimate uses.
> 
> We need a defined way to deal with AS_SETs that doesn't afford opportunities for the malicious source while still permitting either the accidental or the rare intentional use.

I agree, and I think that reinforces my earlier statements.

One might say that to deal with the vast majority of the cases today, 
if an AS_SET contains only a single AS, and there's a valid ROA for 
that origin AS for the prefix in question, it should be considered 
valid.  

Additionally (more generically to capture the above as well), if 
AS_SETs are going to be employed by an AS then all ASes in the set 
must have a corresponding ROA for the prefix in question, else the
route is invalid.  Of course, a big disclaimer security consideration
statement there as well to outline your example above and state this 
is a dumb idea in practice; but that's a different issue...

-danny

---

From: Geoff Huston <[email-masked]>
Date: Tue, 6 Apr 2010 07:44:10 +1000

> I agree, and I think that reinforces my earlier statements.

The circularity of this has not escaped me - I recall about 3 (or was it 4) years ago arguing for the need for some form of signed credentials that would support proxy aggregation in BGP as the associated transformation of a number of discrete originations into a single origination with an associated AS Set. AS I recall the argument was tied up with the multiple signature debate, as essentially a proxy aggregation should reflect in some form or fashion the assent of those entities whose routes have been aggregated in this fashion At the time the opposition from working group participants to this concept was small in number but, from my perspective, typically vehement. I gave up. Others should not feel in any way constrained by my experiences in trying to push that particular barrow. 

Good luck.

regards,

   Geoff