Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document

From: "Larry J. Blunk" <[email-masked]>
Date: Mon, 2 Nov 2009 15:59:47 -0500 (EST)

----- "Sandra Murphy" <[email-masked]> wrote:

> On Mon, 2 Nov 2009, Larry Blunk wrote:
> 
> > Sriram, Kotikalapudi wrote:
> >> At the end of Section 4, you may consider adding a sentence to the
> effect: 
> >> It is expected that the AGGREGATOR AS will have a ROA registered
> that 
> >> permits the AGGREGATOR AS to originate the aggregate prefix. 
> >> The following comments are similar to what I have observed for 
> >> draft-ietf-sidr-roa-validation-03:
> >> 
> >> There is substantial commonality in the problem space addressed as
> well as 
> >> the solution (algorithm) described between the two documents: 
> >> draft-pmohapat-sidr-pfx-validate-03 and
> draft-ietf-sidr-roa-validation-03.
> >> 
> >> The algorithm in this ID and also that in
> draft-ietf-sidr-roa-validation-03 
> >> do not cover another case of partial deployment where
> suballocations 
> >> legitimately originate from a different AS and while a parent
> prefix has a 
> >> ROA with ISP's AS origin, the suballocation (customer's) has no ROA
> 
> >> registered yet. Please see slide 4 in link below (I had emailed
> this to 
> >> SIDR list soon after the SIDR WG meeting in Stockholm):
> >> http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf I
> must 
> >> admit that I am a bit torn about how to cater to this type of
> partial 
> >> deployment condition. One way out is to have a deadline prior to
> which the 
> >> validation decisions would be soft ("not found") for this case and
> then the 
> >> hard decision ("invalid") kicks in after the deadline (again see my
> slides; 
> >> use of BOA or ROA with AS0 may be helpful but not essential as
> discussed in 
> >> my slides 5 and 6). 
> >> Sriram
> >> K. Sriram
> >> +1 301 975 3793
> >> http://www.antd.nist.gov/~ksriram/ 
> >> _______________________________________________
> >> 
> >
> >     I don't find the partial deployment scenario to be
> > particularly compelling.       I'm having difficulty
> > seeing many providers issuing EE Cert's to customers for
> > sub-allocations from the provider's address space.   The
> > common case will likely be providers creating ROA's themselves
> > for their sub-allocated multi-homing customer space.   If you are
> > creating a ROA for the aggregate, why would you not also
> > create ROA's for the more specifics at the same time?
> 
> I don't understand your comment.
> 
> The architecture talks about providers issuing CA-certs for its customers, 
> not EE-certs.  Is the EE-cert vs CA-cert distinction important to your 
> point?
> 
> I ask, because depending on your view, one might say that a provider would 
> *never* issue an EE-cert to its customer.  If the customer is capable of 
> doing RPKI things, the provider would issue the CA-cert to the customer 
> then the customer would issue the EE-cert and sign the ROA.  If the 
> customer was not capable, then the provider is the one that would both 
> issue the EE-cert and sign the ROA.

  Sorry, got my cert's mixed up.  I meant that I suspect most
providers will not issue CA-cert's to customers.

> 
> If a customer is multi-homed, then then there is a route through another 
> provider.  That route may appear with the customer's AS as the origin or 
> with another provider's AS listed as the origin.

    Yes, multi-origin multi-homing happens, but the general
case is single origin multi-homing.   So the common case will be signing a
ROA for that single origin which is unlikely to change.

> 
> Are you suggesting that the clueless customer's provider would sign a ROA 
> for just its own AS to originate the more specific prefix?  For the 
> customer's AS to originate the more specific prefix?  For the other 
> provider to originate the more specific prefix?

    If you are using PA space to multihome,
then you are going to have to play by the provider's rules.
If the provider does not allow multihoming using their
space, that's their right.  You can either get PI
space or get another provider.   Do you think clueless
customers will want to deal with signing ROA's?   In
most cases, I suspect not.  If a provider allows customers
to multi-home from the provider's address space, it seems eminently
reasonable that they would also be willing to sign ROA's
for that space with the customer's AS.  Why wouldn't they?

  In the case of multi-origin multi-homing using PA
space, you are talking about a very small subset.
For the providers who allow such configurations, yes
I fully expect them to sign the ROA's.   Be aware that
many providers will simply tell customers to go get
their own AS and/or their own PI space.

 -Larry

> 
> 
> 
> >
> >   In the few cases where a provider may issue an EE Cert to
> > the customer, it seems unlikely they would issue
> > one before a customer is ready to create ROA's.   This
> > is not like DNSSEC where there are existing delegation
> > chains to deal with -- it's greenfield.    Given the whole
> > point of EE Cert's is to create ROA's, why would you request
> > one if you were not prepared to create ROA's.
> >
> 
> Again, if the customer is ready to create ROAs, then I'm not sure why
> you 
> are saying that the provider would issue an EE-cert to the customer. 
> Are 
> you suggesting that the customer would be ready to sign ROAs but not
> issue 
> its own EE-cert from a CA-cert issued by its provider?
> 
> If you mean CA-cert, then I agree that a provider may not issue a
> CA-cert 
> for the more specific when the customer is not ready to sign ROAs. 
> The 
> provider can issue an EE-cert for the more specific under its own
> CA-cert. 
> And if the customer is ready to sign ROAs then the provider will (if 
> willing) issue a CA-cert for the customer.
> 
> Of course, the partial deployment issue is what we are going to do
> with 
> the customer is not ready for RPKI activity.
> 
> Looking at this a couple of times, I'm still not sure what you mean
> here.
> 
> 
> 
> >
> > -Larry
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > sidr mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sidr
> >

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 2 Nov 2009 17:09:21 -0400 (Eastern Daylight Time)

>>> Sriram, Kotikalapudi wrote:

<snip>

> their own AS and/or their own PI space.

This fits my model and what several others have suggested as well.

What is your opinion of a level down from there - clueless customers 
multihomed clueless customers?  I've heard that while a relationship 
exists between provider and customer, that's not likely between provider 
and customer's customers through which the ROAs could be requested or 
automatically created on certain events.

(Not expressing an opinion here, just exploring the wg's opinion.)

--Sandy

> -Larry

<snip>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 2 Nov 2009 22:10:57 -0500

Larry:

I appreciate the information/thoughts you have shared. 
It would be fine if it (the ROA registrations) plays out the way you envision it should.

As Sandy mentioned, there are instances of sub-suballocations and sub-sub-suballocations etc. 
as can be gleaned from examples at this link:
http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.html
http://stats.research.icann.org/bgp/

Sriram
________________________________________
From: Sandra Murphy [[email-masked]]
Sent: Monday, November 02, 2009 4:09 PM
To: Larry J. Blunk
Cc: Sriram, Kotikalapudi; [email-masked]
Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document

<snip>

--Sandy

<snip>

---

From: George Michaelson <[email-masked]>
Date: Wed, 4 Nov 2009 08:08:14 +1000

Sriram, I have discussed this by email with my co-author who is in  
transit. Please find out reply interpolated below, with apologies for  
delay.

-George

> From: "Sriram, Kotikalapudi" <[email-masked]>
> Date: 3 November 2009 4:00:14 AM AEDT
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation
>
> Comments on the -03 version:
>
> Section 4.1 is a bit confusing because it does not seem to take ROA  
> prefix maxlength into consideration or fails to make any mention of  
> it.

Yes, you are right - it could be clearer that "More Specific than ROA"  
in the table and the text that says "more specific than the ROA" means  
a prefix length that is greater than the ROA's maxLength value. That  
is clear in section 2, step 3, but not specifically reiterated in  
section 4.1

> Several of the statements in this section do not make it clear what  
> implication maxlength has on prefix matching.  For example, does  
> definition of "covering aggregate" include the case when the update  
> (route) prefix length is longer than maxlength?

"Covering aggregate" is used twice in the draft - once in section 2 to  
describe the set of ROAs that are potential candidates to validate a  
route object, and again in section 4 to describe the validation of a  
single route object.  The context of use in the two sections is  
different, and we (the authors) had felt that the text was sufficitly  
clear, but evidently that was not a good assumption.

> In my understanding, ROA prefix is not a _covering_ aggregate if the  
> update prefix length exceeds maxlength, unless purposefully defined  
> otherwise.

It would help if you gave an example here. We are lost in  
understanding your question.

> "Covering Aggregate" should be clearly defined in Section 2,  
> explicitly stating what role maxlength plays, before getting into  
> any description of algorithms.

The role of maxlength is clearly described in step 3 of section 2, but  
your point about "covering aggregate" not being well defined is a good  
point.

Perhaps an example would help with the text.

>
> In my opinion, Section 2 already provides coverage for partial  
> deployment for the case of prefixes that are not included in any  
> ROA. Steps 1 and 2 of the algorithm on page 4 take care of this case  
> of partial deployment. So having a modified algorithm in Section 4  
> seems redundant. The discussion part of Section 4 is relevant and  
> can be suitably edited and moved to Section 2.

Section 4 does not present a modified algorithm. Section 4 explains  
the derivation of the "unknown" outcome of step 2 of section 2.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 4 Nov 2009 15:46:34 -0500

> -----Original Message-----
> From: George Michaelson [mailto:[email-masked]]
> Sent: Tuesday, November 03, 2009 5:06 PM
> 
<snip>
<snip>

Thanks, George, for your responses to my previous email.
In the following, I elaborate on my thinking while stepping through several 
validation use cases / examples,
and I have a new question as well towards the end.
(Later I will discuss with Terry Manderson about incorporating 
these use cases also into our draft-manderson-sidr-usecases-01.txt; 
these are not included there yet.)

Examples (Validation use cases):
Use case 1:
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.0.0/17, Origin = AS49}
Here the ROA prefix is a covering prefix for the update prefix -- this is obvious.

Use case 2:
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.5.0/24, Origin = AS49}
(A) Do we still consider the ROA prefix a covering prefix for the update prefix?
Or,  (B) Do we consider it not a covering ROA prefix because the update prefix
length is longer than the maxlength allowed in the ROA?  

I think the answer is (A) for the following reasons (in a moment we will 
enumerate additional use cases):
In use case 2, we want the validation result to be Invalid.
The algorithm will determine that the ROA prefix is a covering prefix 
for the update prefix. But it will also determine that the ROA maxlength 
is exceeded by the update prefix length; so the validation result is "Invalid."

In all use cases below, let us assume that we use definition (A) - 
that is, ROA prefix is considered a covering match or covering aggregate 
if the update prefix matches or is a more specific; the maxlength consideration
is deferred at this stage and will be applied separately as part of the validation process.  

Use case 3: HERE IS WHERE THE DISTINCTION IN "COVERING PREFIX or AGGREGATE" DEFINITIONS BEGINS TO MATTER
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.5.0/24, Origin = AS42}
(Note: Different origin)
In use case 3, we want the validation result to be Invalid.
The algorithm will determine that the ROA prefix is a covering prefix 
for the update prefix. But it will also determine that the ROA maxlength 
is exceeded by the update prefix length,
and also determine that the origin is mismatched. So the result is "Invalid."
(Here, clearly, the suspicion is that of a subprefix hijack situation.)  

Use case 4:  Giving an AS the benefit of doubt (partial deployment)
ROA: {129.6.0.0/16, maxlength = 18, AS49}  - not directly relevant for this use case. 
Update has {74.63.16.0/24, Origin = AS42}
(Note: Completely different prefix and origin - ROA listed is not 
directly relevant anyway)
(Note: There is no ROA in the entire repository that validates or invalidates 
this update. We give the AS42 the benefit of doubt during 
partial deployment; probably it has not yet upgraded to RPKI capability!)

In use case 4, we want the validation result to be "Unknown".
The algorithm determines that a ROA with a covering prefix for the 
update prefix DOES NOT exist.
So it concludes that possibly a ROA has not been registered yet.
The result of validation: "Unknown"

Use case 5:  Here it is doubtful if "AS should be given the benefit of doubt"
ROA: {70.40.0.0/21, maxlength = 24, AS42}
Update has {74.63.16.0/24, Origin = AS42}
This use case is still a logical progression from previous use cases, but here 
I have a NEW QUESTION that we have not considered so far (IMHO). 
(Note: Completely different prefix, but origin is the same as in another ROA)
(Note: There is no ROA in the repository that has a covering prefix 
or aggregate for the update prefix.  So there is no ROA that 
validates or invalidates this update. However, here we hesitate to give 
the AS42 the benefit of doubt; because we have evidence by observing 
another ROA that AS42 or its ISP has RPKI capability!)

I think your algorithm as well as that of draft-pmohapat-sidr-pfx-validate-03.txt
will treat this update softly and the validation results will be 
"Unknown" or "Not Found", respectively.
But I think we may want the validation result in this case to be "Invalid".
Question is: AS42 or its ISP evidently has RPKI capability; 
so why did it register a ROA for one prefix (namely, 70.40.0.0/21) 
that it originates but not for another prefix 74.63.16.0/24 
which it is also trying to originate?  
Caveat: AS42 might have been suballocated the prefix 74.63.16.0/24 
from a different ISP who is clueless about RPKI. Is there a reasonable
case here for validation result to be "Unknown" or should the result be "Invalid"? 
I would like to request some discussion from the WG members on this question.

Sriram

---

From: Larry Blunk <[email-masked]>
Date: Fri, 06 Nov 2009 15:54:52 -0500

Sriram,
     I think you are missing my point.   I'm aware of these
sub-allocations, but I don't agree that providers SHOULD
or MUST issue CA-Certs for these suballocations, which seems
to be the assumption of some.   Rather, it is my feeling
that we can only assume the provider MAY issue a CA-Cert for
the sub-allocations.

   If they choose not to issue a CA-Cert to a customer, I believe it is
reasonable to assume they will still issue ROA's for the routes
that are being announced by the customers at the time the ROA
for the aggregate announcement is issued.   I'm not fond
of partial deployment scenarios where the more specifics
are not registered until some unspecified later date.   It will be
difficult to go back and get all the more specifics registered
later if there are significant numbers of them.   It should be
relatively straightforward to construct tools to assist providers
with issuing ROA's for the more specifics at the time the ROA
for the aggregate announcement is being issued.

    It's my understanding (please correct me if I'm wrong)
that by issuing a CA-Cert a provider is
not only giving the customer authority to register their own
ROA's, but to also issue ROA's or CA-Cert's for
customers of the customer (and so on).   I suspect many providers would
be reluctant to grant this level of authority over the PA space
they have assigned.

 -Larry

---

From: Jared Mauch <[email-masked]>
Date: Sat, 7 Nov 2009 07:21:11 +0900

I share the comments and concerns of Larry but want to take it a step  
further. There will not be anything but partial deployment for years  
to come. Trying to transfer costs to ISPs that are unwilling or unable  
to issue certs is going to be an ongoing challenge.

See everyone soon!

Jared Mauch

On Nov 7, 2009, at 5:54 AM, Larry Blunk <[email-masked]> wrote:

>> I appreciate the information/thoughts you have shared. It would be  
>> fine if it (the ROA registrations) plays out the way you envision  
>> it should.
>>
>> As Sandy mentioned, there are instances of sub-suballocations and  
>> sub-sub-suballocations etc. as can be gleaned from examples at this  
>> link:

---

From: "Larry J. Blunk" <[email-masked]>
Date: Fri, 6 Nov 2009 20:06:56 -0500 (EST)

Sorry, should have provided more context.  I was referring to
the particular "Partial Adoption" scenario presented in
http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf.
Where more specifics of a registered ROA (that do not not have
a matching ROA) are not invalidated for a certain grace period.
This dramatically limits the value of ROA's and it will be
difficult to end the grace period if there are significant
numbers of more specifics of ROA's that are unregistered.

    It seems to me if you are unprepared to register ROA's for
all the more specifics of an aggregate ROA, it would be better
to hold off on registering the ROA for the aggregate until all
the more specific ROA's are in place.

 -Larry

a certain grace period.  

----- "Jared Mauch" <[email-masked]> wrote:

> >> Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR
>  
> >> WG document
> >>

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Nov 2009 20:57:17 -0600

> the more specific ROA's are in place.

of course.  which is why i will issue roas for those of my children too
occupied with other things to do it for themselves.  because i certainly
want to roa the aggregate to prevent hijacking of static customers, my
own infrastructure, and unused space without having to issue 42 stupid
little roas.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Sat, 7 Nov 2009 12:26:19 -0400 (Eastern Daylight Time)

> the more specific ROA's are in place.

I haven't figured out yet what you mean about registering ROAs for the 
more specifics.

If you have sub-allocated to a customer and you want to register a ROA for 
that more specific, would you register the ROA with your AS or your 
customer's AS (or your customer's backup upstream).

--Sandy

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 07 Nov 2009 15:19:18 -0500

> be reluctant to grant this level of authority over the PA space

And the CA-Cert is not revokable?

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Sat, 7 Nov 2009 19:10:25 -0500

>And the CA-Cert is not revokable?

Yes, the CA cert can be revoked.

Also, if we wanted to provide the ISP with additional controls, there 
is a cert path length as part of the basic constraints extension that 
is in the RPKI profile (although the path length field  is currently 
deprecated). This field allows an issuer to restrict the issuance of 
CA certs below the CA certs that it issued.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Nov 2009 19:03:54 +0900

> If you have sub-allocated to a customer and you want to register a ROA
> for that more specific, would you register the ROA with your AS or your

would it not be most useful to issue the roa for the AS which will
announce the prefix?  what am i missing here?

randy