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

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 2 Nov 2009 12:11:44 -0500

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/

---

From: Larry Blunk <[email-masked]>
Date: Mon, 02 Nov 2009 13:41:12 -0500

Sriram, Kotikalapudi wrote:
> _______________________________________________
>   

      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?

    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.

 -Larry

---

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

On Mon, 2 Nov 2009, Larry Blunk 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. 
>> 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

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?

> 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.

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

---

From: Terry Manderson <[email-masked]>
Date: Sun, 8 Nov 2009 22:42:32 -0800

I've been thinking this over and spoken to some people who understand this
position better than I, and my position has shifted as I don't feel that an
IPR statement _changes_ the content of the ID, although it _may_ affect the
content of other drafts and IDs when the IPR is publically visible. At some
stage there may be a discussion of like documents but that shouldn't, in my
opinion, hinder the review of draft-pmohapat-sidr-pfx-validate and I feel it
is within charter as so I support its adoption as a WG item and am willing
to review even though the discussion and WG status request was hijacked and
the due date for the topic has expired.

That said, can I ask - for future use and reference - the WG-chairs to seek
a WG consensus on how it deals with IPR?

Cheers
Terry

On 31/10/09 1:36 AM, "Joel M. Halpern" <[email-masked]> wrote:

> General comment:
> The US Patent office procedures are such that there is a delay between
> filing and public disclosure of applications.  That may be applicable here.
> 
> the IETF procedures specifically ask folks to tell us about such patent
> applications, if they think they apply.  However, we understand that we
> can not get details at that point.
> 
> If we treat such disclosure as a priori blocked of WG consideration of a
> document, we invite denial of service attacks on our work.  If this
> document were being last called, then the question would be
> significantly more complicated.  But we are only at WG adoption, as a
> starting point for work on a topic.
> 
> (This is separate from the additional, relevant, question that Robert asks.)
> 
> Yours,
> Joel M. Halpern
> 
> Robert Loomans wrote:
>> Terry Manderson wrote:
>>> I feel unable to say either way at present.
>>> 
>> ...
>>> A direct link to the Patent Application would be appreciated!
>> 
>> Ditto. I'm reluctant to take any stance on this draft without more
>> information on what the patent claims.
>> 
>> Additionally, I'd like to see a clear statement as to what this draft
>> says for which the existing draft-ietf-sidr-roa-validation is insufficient.
>> 
>> Rob
>>