Subject: [sidr] Prefix-Origin Validation Use Cases

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 18 Mar 2010 07:23:12 -0400

The uses cases listed below pertain to {Prefix, Orgin} validation,
and are not yet included in draft-manderson-sidr-usecases-01
http://tools.ietf.org/html/draft-manderson-sidr-usecases-01
We plan to include them in the next updated revision (as a SIDR WG draft) which we 
(Terry, myself, Russ) expect to submit soon. 
Your comments are requested.

These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-origin information in the update. We systematically enumerate the situations or scenarios but do not make a final recommendation on any RPKI interpretation at this point. We have included some comments on plausible RPKI recommendations. However, it is fully acknowledged that these recommended RPKI interpretations can be overridden by ISP’s local policy. It would generally be up to an ISP to make choices regarding the interpretation or decision, based on various considerations, including their view of “Partial Deployment”, “Full Deployment” of RPKI, etc. 

Taxonomy:
Update prefix: Prefix seen in an update
ROA prefix: Prefix contained in a ROA 
Covering Prefix: When we say that a ROA prefix is a covering prefix for an update prefix, what is meant is that the ROA prefix in an exact match or a less specific when compared to the update prefix.
No relevant ROA: It means that there is no ROA that has a covering prefix for the update prefix.
No other relevant ROA: It means that there is no other ROA (besides any that is(are) already cited) that has a covering prefix for the update prefix 

1.  Covering ROA Prefix, Maxlength Satisfied, and AS Match:
ROA: {10.1.0.0/16, maxlength = 20, AS64496}
Update has {10.1.0.0/17, Origin = AS64496}
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: This is a straight forward prefix-origin validation use case; it follows from the primary intention of creation of ROA by a resource owner. Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Valid.

2.  Covering ROA Prefix, Maxlength Exceeded, and AS Match:
ROA: {10.1.0.0/16, maxlength = 20, AS64496}
Update has {10.1.0.0/22, Origin = AS64496}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case the maxlength specified in the ROA is exceeded by the update prefix. Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Invalid.

3.  Covering ROA Prefix, Maxlength Satisfied, and AS Mismatch:
ROA: {10.1.0.0/16, maxlength = 24, AS64496}
Update has {10.1.88.0/24, Origin = AS65551}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case an AS other than the one specified in the ROA is originating an update. This may be a prefix or subprefix hijack situation.  Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Invalid.

4.  Covering ROA Prefix, Maxlength Exceeded, and AS Mismatch:
ROA: {10.1.0.0/16, maxlength = 22, AS64496}
Update has {10.1.88.0/24, Origin = AS65551}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case the maxlength specified in the ROA is exceeded by the update prefix, and also an AS other than the one specified in the ROA is originating the update. This may be a subprefix hijack situation.  Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Invalid.

5.  Covering ROA Prefix Not Found:
Update has {240.1.1.0/24, Origin = AS65551}
No relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case there is no relevant ROA that has a covering prefix for the update prefix. It could be a case of prefix or subprefix hijack situation, but this announcement does not contradict any existing ROA. During partial deployment, there would be some legitimate prefix-origin announcements for which ROAs may not have been issued yet. Recommended RPKI validation interpretation could be: Announced prefix-origin pair has ‘no ROA’.

6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More Specifics:
ROA: {10.1.0.0/18, maxlength = 20, AS64496}
ROA: {10.1.64.0/18, maxlength = 20, AS64496}
ROA: {10.1.128.0/18, maxlength = 20, AS64496}
ROA: {10.1.192.0/18, maxlength = 20, AS64496}
Update has {10.1.0.0/16, Origin = AS64496}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case the update prefix is an aggregate, and it turns out that there exit ROAs for more specifics which, if combined, can help support validation of the announced prefix-origin pair. But it is not recommended that we apply any leniency in this situation. The announced aggregate prefix should be required to have a ROA which can be directly used for validation. Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Invalid.
 
7. Update has an AS Set as Origin and ROAs Exist for a Covering Set of More Specifics:
ROA: {10.1.0.0/18, maxlength = 20, AS64496}
ROA: {10.1.64.0/18, maxlength = 20, AS64497}
ROA: {10.1.128.0/18, maxlength = 20, AS64498}
ROA: {10.1.192.0/18, maxlength = 20, AS64499}
Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498, AS64497]}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: TBC

Comment: In this case the aggregate of the prefixes in the ROAs is a covering prefix for the update prefix. The ASs in each of the contributing ROAs together form a set that matches the AS set in the update. An extremely small percentage (~0.1%) of eBGP updates are seen to have AS set in them as origin; this is known as proxy aggregation. It is recommended that announcements with an AS set as origin should be discouraged. Recommended RPKI validation interpretation could be: The announced prefix-origin pair is Invalid.

---

From: Larry Blunk <[email-masked]>
Date: Thu, 18 Mar 2010 11:33:07 -0400

> These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-o…

   I'd like to see some mention of scenarios involving customer
sessions/small scale peering  vs. large-scale peering.
Providers may likely wish to have more stringent
enforcement on customer sessions where the lack of covering ROA
for a prefix is treated as an invalid announcment.   Much as
those providers who use IRR based filtering do today.   I believe
this will also help improve deployment.

  I've also mentioned in the past that I consider the use of
maxlength to be potentially dangerous (where the full set
of most specifics are not announced) in that I believe it
makes hijacking via path manipulation easier.   Don't know
if that bears mention in this document or perhaps a new one.
I'd be willing to write something up if it would be helpful.

 -Larry Blunk
  Merit Network

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 18 Mar 2010 11:45:15 -0400 (Eastern Daylight Time)

On Thu, 18 Mar 2010, Larry Blunk wrote:

>> We plan to include them in the next updated revision (as a SIDR WG draft) 
>> which we (Terry, myself, Russ) expect to submit soon. Your comments are 
>> requested.
>> 
>> These use cases try to systematically enumerate the situations a relying 
>> party may encounter while receiving a BGP update and making use of ROA 
>> information to interpret the validity of the prefix-origin information in 
>> the update. We systematically enumerate the situations or scenarios but do 
>> not make a final recommendation on any RPKI interpretation at this point. 
>> We have included some comments on plausible RPKI recommendations. However, 
>> it is fully acknowledged that these recommended RPKI interpretations can be 
>> overridden by ISP’s local policy. It would generally be up to an ISP to 
>> make choices regarding the interpretation or decision, based on various 
>> considerations, including their view of “Partial Deployment”, “Full 
>> Deployment” of RPKI, etc.
>> 
>

That's an interesting statement.  If you can substantiate security 
concerns arising from having a maxlength in the ROA, please do document it 
as quickly as possible.  Please.  ASAP.

Do you really mean "hijacking via path manipulation" not "hijacking via 
origin manipulation"?  The sidr wg is not working on path validation at 
this time, we are working on origin authorization only.  So such a comment 
might not require a fix to the current documents.

But if you can see that a ROA with a maxlength might make it easier for 
someone to manipulate the remainder of the path somehow, I for one would 
be interested to hear, anyway.

--Sandy

>
>
> -Larry Blunk
> Merit Network
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Larry Blunk <[email-masked]>
Date: Thu, 18 Mar 2010 15:22:19 -0400

Sandra Murphy wrote:
>>> We plan to include them in the next updated revision (as a SIDR WG 
>>> draft) which we (Terry, myself, Russ) expect to submit soon. Your 
>>> comments are requested.
>>>
>>> These use cases try to systematically enumerate the situations a 
>>> relying party may encounter while receiving a BGP update and making 
>>> use of ROA information to interpret the validity of the 
>>> prefix-origin information in the update. We systematically enumerate 
>>> the situations or scenarios but do not make a final recommendation 
>>> on any RPKI interpretation at this point. We have included some 
>>> comments on plausible RPKI recommendations. However, it is fully 
>>> acknowledged that these recommended RPKI interpretations can be 
>>> overridden by ISP�s local policy. It would generally be up to an ISP 
>>> to make choices regarding the interpretation or decision, based on 
>>> various considerations, including their view of �Partial 
>>> Deployment�, �Full Deployment� of RPKI, etc.
>>>
>>
> concerns arising from having a maxlength in the ROA, please do 
> document it as quickly as possible. Please. ASAP.
>
> Do you really mean "hijacking via path manipulation" not "hijacking 
> via origin manipulation"? The sidr wg is not working on path 
> validation at this time, we are working on origin authorization only. 
> So such a comment might not require a fix to the current documents.

Yes, specifically origin manipulation (which would be covered
by path manipulation)
>
> But if you can see that a ROA with a maxlength might make it easier 
> for someone to manipulate the remainder of the path somehow, I for one 
> would be interested to hear, anyway.

Not easier to manipulate the origin, just better results
from such techniques. If maxlength is used, but not
all the most specifics are actually announced, an attacker could
announce a more specific from the block that will
pass validation with a manipulated origin. Without a
maxlength, they can still manipulate the origin to validate, but
they are limited to announcing a prefix of the same length
as an existing announcement. Such attacks will likely be
considerably more limited in scope of impact than a more
specific of an existing announcement.

-Larry

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 18 Mar 2010 22:02:22 +0100

Larry,

> pass validation with a manipulated origin.
>

Could you please explain what do you mean by "manipulate the origin"?
As Sandy mentioned I see cases that you could manipulate the ASN Path
and validate.

Thanks,

Roque.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 19 Mar 2010 13:19:13 -0400

If some people preferred to see a pdf version of my long first (initial) 
posting on this topic, here is a link for that:
http://www.antd.nist.gov/~ksriram/Prefix_Origin_UseCases.pdf

Now to Larry's question:

Thanks, Larry, for your comments.
I will think about you suggestion about use cases for differentiating
small scale peering  vs. large-scale peering,
and also discuss it with my co-authors.
We will report if we can come up with something.
I would also like to speak to you about this at the IETF if you plan to attend.

Regarding the maxlength issue,
> I consider the use of
> of most specifics are not announced)
I have question for you.
When YouTube prefix was hijacked, 
it had to announce /24s and then /25s out of its 
aggregate /22 in order to recover the traffic.
If YouTube registers a ROA with only the /22 and no maxlength,
then even its own updates with the more-specifics for recovering 
the traffic (under hijack) would be dropped.
If maxlength is not specified, how do you envision
a solution for this?

Sriram

> -----Original Message-----
> From: Larry Blunk [mailto:[email-masked]]
> Sent: Thursday, March 18, 2010 11:33 AM
> To: Sriram, Kotikalapudi
> Cc: [email-masked]
> Subject: Re: [sidr] Prefix-Origin Validation Use Cases
> 
> > These use cases try to systematically enumerate the situations a relying party may
> encounter while receiving a BGP update and making use of ROA information to interpret
> the validity of the prefix-origin information in the update. We systematically enumerate the
> situations or scenarios but do not make a final recommendation on any RPKI interpretation
> at this point. We have included some comments on plausible RPKI recommendations.
> However, it is fully acknowledged that these recommended RPKI interpretations can be
> overridden by ISP's local policy. It would generally be up to an ISP to make choices
> regarding the interpretation or decision, based on various considerations, including their
> view of "Partial Deployment", "Full Deployment" of RPKI, etc.
> >
> >
>

---

From: Larry Blunk <[email-masked]>
Date: Fri, 19 Mar 2010 15:31:46 -0400

> I would also like to speak to you about this at the IETF if you plan to attend.

  Yes, I will be there.

> If maxlength is not specified, how do you envision

   Yes, I've considered this as a possible argument to using
maxlength.   And I do see some validity to it in limited or
partial deployment scenarios of ROA's.   However, you failed to point
out that Pakistan Telecom was announcing a /24 more specific out of
the /22 aggregate.    And this is the main reason why it was
so successful.   The reason for the /25's being announced by
Youtube was to combat Pakistan Telecom's /24.

   I think the case study helps prove my point if you think about
the reverse situation.   Namely, that if Pakistan Telecom had been
limited to announcing a /22 by a ROA with maxlength 22, they
would have likely had more limited success since they would
have been competing against the existing /22 from Youtube.
Just as Youtube had problems overcoming Pakistan Telecom's
/24 with it's own /24 announcement (and ended up using /25's), you can
imagine that Pakistan Telecom would have had limited
effect if it had been limited to announcing a /22 against
Youtube's existing /22 announcement.

 -Larry

---

From: Danny McPherson <[email-masked]>
Date: Fri, 19 Mar 2010 16:23:14 -0600

> Youtube's existing /22 announcement. 
Indeed.  The only place the argument Sriram is making holds is when
you've got limited or partial deployment - -that's Terry's big concern
as well, IIRC.  I still very much prefer the explicit length model that
mirrors prefix filters employed today and 15 years ago.  It encourages
people to aggregate effectively and mitigates deaggregation incidents.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Fri, 19 Mar 2010 16:28:38 -0600

> specific of an existing announcement.

It might also be worth noting here that while you're referring to origin
*AS*, origin code manipulation in many cases will garner much more
diverted traffic, even if prefixes are of equal length.  E.g., some
large ISPs have been known to reset "incomplete" to "internal" and have
dramatic impacts on transited traffic rates..

-danny

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Mar 2010 17:12:11 -0700

max-len is at the choice of the issuer of the roa.  it is a macro so
they do not have to issue all the smaller roas.  if they don't want the
longer prefixes announced, then they should not issue the roas, whether
as individual roas or in the equivalent max-len macro.

and the pakistan telkom accident is not a useful analogy.  the
announcement did not come from the owning asn.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 22 Mar 2010 00:57:23 -0400

> as individual roas or in the equivalent max-len macro.

note that in a transitional world there will either be:
1) a chance to put a more specific in un-validated and cause an outage
while the signer runs around getting rpki updates flushed thorugh
2) lots of max-len=24 roas

Once utopia arrives folks could back off to their prefix-len +1
max-len (or something not 'every to the /24'...

-chris

> announcement did not come from the owning asn.

you say tomato, I say tool of the regime to get a recalcitrants
attention...  (I really don't know, but the point is likely only the
implementor of the change does)

-chris