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 protected]>
> 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 protected]>" 
> <[email protected]>
> Cc: [email protected], ietf <[email protected]>
> 
> On Sep 8, 2014, at 11:42 AM, The IESG <[email protected]> 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 protected] 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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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

Reply via email to