Re: [Sidrops] [routing-wg] misconceptions about ROV

Hello Job, others

> On 24 Feb 2022, at 09:31, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Hello Tim, others,
> 
>> What I meant here by "accept... on islands" is that the operator would
>> have to know - somehow - where to enable BGPSec validation.
>> 
>> I believe that the idea was that this would be done on a BGP session
>> basis. E.g. providers would insist on BGPSec from customers, or peers
>> between each other etc.
> 
> "In order to indicate that a BGP speaker is willing to send BGPsec
> UPDATE messages (for a particular address family), a BGP speaker
> sends the BGPsec capability"
> source: https://datatracker.ietf.org/doc/html/rfc8205#section-2.2
> 
> Indeed, it is an operator choice whether to enable BGPsec or not, and it
> is choosen per-session. Luckily most large operators have automated the
> provisioning of BGP sessions.
> 
>> I wondered if (new) signed statements in the RPKI could be used to
>> conclude that ASNs have pledged to use BGP Sec when possible. I.e.
>> such ASNs would sign a path if they are the origin / or if the receive
>> a signed path.
>> 
>> The receiving router could then conclude that IFF all ASNs in a path
>> had made these signed statements - BGPSec validation on *that* path
>> could be performed. It would be an error if signatures were missing or
>> invalid.
>> 
>> This way operators would not have to enable this manually on a per
>> session basis, and because it would be based on signed validated
>> statements they could trust that it would be safe to apply for ASNs
>> who issued those statements - without the need to know these ASNs
>> first hand - e.g. across transit.
>> 
>> It would still allow for path spoofing and signature removal by
>> injecting an ASN that did not sign a statement that they would do
>> BGPSec. However, the options would become more limited as more ASNs
>> participate - and ASPA validation would further limit the available
>> choices.
>> 
>> As for how an ASN could sign such a statement.. one could overload
>> existing router certificates but I think that is probably a bad idea -
>> it could very well lead to timing issues when adopting. An alternative
>> could be to have a new separate signed object for this, which would
>> allow that BGPSec is tested first, before letting the world know.
>> 
>> Just an idea.. hoping it might help.
> 
> I am not sure it is helpful at this stage.
> 
> It seems you overlook some deployment aspects, for example: within a
> given Autonomous System (during the incremental deployment of BGPsec -
> which may take years) there will be ASBRs that support BGPsec and ASBRs
> that are unable to negotiate support for BGPsec. For example, it is
> entirely possible that at a given moment in time only half the
> adjacencies for 206238_15562$ are BGPsec capable, and half are not (yet).

Not at all - any adjacencies that are not BGPSec capable would not issue
any statement that they are capable. So stripping the signatures there
would be entirely expected.

I am talking about something else: signalling deployment beyond direct
sessions in order to enable detection of downgrade attacks. If router
can detect that the *entire* path is not only capable but also committed
to do BGPSec then removal of signatures can be flagged as an attack.

> See this posting for a similar story on RPKI ROV invalids:
> https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html
> 
> Frankly speaking, wouldn't it make far more sense to implement the
> specifications AS SPECIFIED AND PEER-REVIEWED BY MANY PEOPLE,
> *before* advocating new object profiles?
> 
> Especially since the CA side of BGPsec is so straight-forward and
> simple to implement ... ?

There is no need to shout Job..

I was trying to have a discussion about a possible way to help
operational future deployment. This is in no way preventing the
development and deployment of current standards. And should the
idea be useful and accepted then of course it would be handled
as a WG document, be peer-reviewed etc.

I know - it's naive to think that that would be what the IETF
is for. Fine. I will stop here. Discussion once again seems
entirely pointless.

> 
> Regards,
> 
> Job
> 
> ps. Since you asked, here are required reading materials:
> 
> BGPsec Protocol Specification
> 	https://datatracker.ietf.org/doc/html/rfc8205
> 
> BGPsec Considerations for Autonomous System (AS) Migration
> 	https://datatracker.ietf.org/doc/html/rfc8206
> 
> BGPsec Operational Considerations
> 	https://datatracker.ietf.org/doc/html/rfc8207
> 
> BGPsec Algorithms, Key Formats, and Signature Formats
> 	https://datatracker.ietf.org/doc/html/rfc8208
> 
> BGPsec Design Choices and Summary of Supporting Discussions
> 	https://datatracker.ietf.org/doc/html/rfc8374
> 
> Router Keying for BGPsec
> 	https://datatracker.ietf.org/doc/html/rfc8635

Thank you Job - somehow I managed to find these documents myself.

I did not ask about these. I asked about the downgrade issue.
Randy was kind enough to answer.

Tim

> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops