Hi Pradosh,

(skiping)

>> Section 2:
>>   "An AS can originate more than one
>>   prefix set.  Thus, multiple prefix sets in the database can contain
>>   the same origin AS(es)."
>> 
>> I believe you also need to mention that in the table there may be 
>> "multi-origin prefixes". Geoff report identifies 2400 but you may find more 
>> in local/regional environments (http://bgp.potaroo.net/as6447/report.txt).
> 
> I looked at the document again and I see many places where we say there can 
> be multiple origin ASes for the prefix. E.g.:
> 
> we define terms "UPDATE prefix" and "UPDATE origin
> AS number" to denote the values derived from the received UPDATE message, and
> "database prefix set" and "database origin AS number set" to mean the values
> derived from the database lookup.
> 
> where it's defined as "database origin AS number set" instead of just an AS 
> number.
> 

Ok. I got it now.


>> 
>> Section 5:
>> p5: 
>> I believe you should reference draft-ietf-sidr-origin-validation-signaling-00
> 
> Ack
> 
>> Security Consideration:
>> I think you need to consider what you already mentioned in section 4, if the 
>> connectivity to the local-caches is lost, invalid routes will be classified 
>> as "not-found", which could have a different set of local policies.
> 
> Is this different from current behavior?

Not sure what do you refer for "current behavior". My point was that in the 
security considerations you should point to the analysis in Section 4 on 
loosing connectivity to the cache servers.

Example:
        Router set loc-pref 100 for "valid" and loc-pref 50 for "not-found".
        If the router looses connectivity with caches, either by operational 
issues or by malicious event (on the cache/ the router or the network between 
the two), the set of prefixes that should be "valid" based on RPKI will be 
classified as "not found" and loc-pref set to 50.

Roque

> 
> - Pradosh

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to