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

From: Sandra Murphy <[email-masked]>
Date: Mon, 8 Sep 2014 19:15:32 -0400

Speaking as regular ol' member:

The opsec bgp security draft is in IETF last call.

John Scudder made an interesting observation, which looks of interest to this group.

--Sandy, regulär ol' member

Begin forwarded message:

> From: "John G. Scudder" <[email-masked]>
> Subject: Re: Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations and security) to Best Current Practice
> Date: September 8, 2014 5:05:53 PM EDT
> To: "<[email-masked]>" <[email-masked]>
> Cc: [email-masked], ietf <[email-masked]>
> 
> On Sep 8, 2014, at 11:42 AM, The IESG <[email-masked]> wrote:
> 
>> 
>> The IESG has received a request from the Operational Security
>> Capabilities for IP Network Infrastructure WG (opsec) to consider the
>> following document:
>> - 'BGP operations and security'
>> <draft-ietf-opsec-bgp-security-05.txt> as Best Current Practice
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2014-09-22. 
> ...
> 
> I happened to notice, in S. 6.1.2.4 (SIDR):
> 
>   o  If an ROA is not found then the prefix SHOULD be accepted but
>      corresponding route SHOULD be given a low preference.
> 
> The draft isn't precise about what's meant by "ROA is not found", but probably it's the same as NotFound in RFC 7115 and 6811. Assuming that's right, I'm curious what the rationale is for giving not-found routes a low preference? By definition, they don't compete with a route that is in any other state -- NotFound basically means there is no ROA that has anything to say about this prefix at all, so all routes for this prefix will be NotFound. 
> 
> The net result is according to the draft's recommendation all routes for the prefix in question will be "accepted but ... given a low preference". The recommendation ends up being mostly harmless, but also not useful. 
> 
> (I say only *mostly* harmless since I guess some operator could be confused into thinking they're more secure than they actually are.)
> 
> Sorry for the late comment.
> 
> Regards,
> 
> --John
> 
> P.S.: This shouldn't be construed as a full review of the document, which I haven't done.

---

From: Randy Bush <[email-masked]>
Date: Tue, 09 Sep 2014 11:21:11 +0900

> John Scudder made an interesting observation, which looks of interest

it has to happen occasionally, but jgs was not completely correct, as
the author pointed out.

From: Randy Bush <[email-masked]>
Subject: Re: Last Call: <draft-ietf-opsec-bgp-security-05.txt> (BGP operations and security) to Best Current Practice
To: Jerome Durand <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>,
    <[email-masked]>,
    opsec <[email-masked]>, 
    ietf <[email-masked]>
Date: Tue, 09 Sep 2014 11:14:47 +0900

>> Assuming that's right, I'm curious what the rationale is for giving
>> not-found routes a low preference?

it was intended more as prefer valid.  but i take your point.  do remind
me when we have gained enough experience to rev 7115

>> By definition, they don't compete with a route that is in any other
>> state -- NotFound basically means there is no ROA that has anything
>> to say about this prefix at all, so all routes for this prefix will
>> be NotFound.

true, if they are notfound, then they can not be either valid or invalid
as there is no covering roa.

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

randy