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