Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations and security) to Best Current Practice

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 9 Sep 2014 13:55:06 +0000

>> Actually I think the "lower preference" thing still makes some sense. 
>> I still see the case where you receive the routes from different 
>> peerings, for which you either check or do not check the received 
>> prefix against the ROA. I can give the below example:

> you have a sick mind.:)  yes, this is possible.  so perhaps qualify the recommendation.

>   in a configuration when some announcements may be checked and others
>   not, it is possible that a prefix may be marked both notfound,
>   because of not being checked, and [in]valid, because it is checked.
>   in this configuration, we recommend that the operator prefer valid
>   over notfound.

 The situation of having in(valid) and notfound routes simultaneous for a prefix
 also arises when a router is not doing its own origin-AS check but is
 relying on neighboring IBGP speakers (all within the same AS): 

https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 

 One IBGP peer may signal "Valid" (or "Invalid") and 
 another may signal "NotFound" for the same prefix. 
 Also, it is possible one IBGP peer may signal "Valid" and another may signal "Invalid"
 even when the origin AS is the same in the two updates.
 Two IBGP peers apparently not in sync w.r.t. their RPKI state.   

 The sidr-origin-validation-signaling I-D and RFC 7115 have not gone into
 discussing these situations. There are some subtleties involved. 
 For example, it is possible the IBGP peer signaling "Invalid" is actually correct 
 and another IBGP peer signaling "NotFound" is actually wrong
 (relative to true global RPKI state).

 Sriram

---

From: Randy Bush <[email-masked]>
Date: Tue, 09 Sep 2014 22:56:16 +0900

>  relying on neighboring IBGP speakers (all within the same AS): 

don't do that

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 9 Sep 2014 15:12:43 +0000

>>  The situation of having in(valid) and notfound routes simultaneous 
>> for a prefix  also arises when a router is not doing its own origin-AS 
>> check but is  relying on neighboring IBGP speakers (all within the same AS):

>don't do that

I was not proposing it. I was merely referring to the following from
draft-ietf-sidr-origin-validation-signaling-04:
  
  If the router is configured to support the extensions defined in this
   draft, it SHOULD attach the origin validation state extended
   community to BGP UPDATE messages sent to IBGP peers by mapping the
   computed validation state in the last octet of the extended
   community.  Similarly on the receiving IBGP speakers, the validation
   state of an IBGP route SHOULD be derived directly from the last octet
   of the extended community, if present.

It appears the origin-validation-signaling draft expired as of August 18.
I am not aware if it is being pursued still or put aside.

Sriram