Re: [sidr] revision to draft-ietf-sidr-roa-validation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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. 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? In my understanding, ROA prefix is not a _covering_ aggregate if the update prefix length exceeds maxlength, unless purposefully defined otherwise. "Covering Aggregate" should be clearly defined in Section 2, explicitly stating what role maxlength plays, before getting into any description of algorithms. 

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. 

The algorithm in this ID and also that in draft-pmohapat-sidr-pfx-validate-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 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 ("unknown") for this case and then the hard decision ("invalid") kicks in after the deadline (again see my slides; use of BOA may be helpful but not essential as discussed in my slide #6). 

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.

Sriram
K. Sriram
+1 301 975 3793
http://www.antd.nist.gov/~ksriram/

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.