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.
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.
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?
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 protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
