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

["Montgomery, Douglas C. (Fed)" <[e-mail]>]

For what it is worth, I have long thought the ability to indicate, in a globally accessible system, that BGPSec is being used on a given logical peering between two ASes is the only way address the down-grade attack on BGPsec as currently specified and would increase the utility of BGPsec over multi hop paths.

I agree with Tim’s point, as I understood it, that this information can’t just be local to a peering session, as I need to know if I received an unsigned (BGP4 PATH) that appears to come from a sequence of ASes that all stated that they were doing BGPsec with each other.

I get Job’s (I think) point that a simple mechanism at the AS level can’t deal with the scenario where I do BGPsec on some peering’s with my neighbor but not on others with the same neighbor.  Given that distinct peering sessions between the same peers are not visible in BGP downstream of the ASes in question, there is not much to do about this other than wait until all peering sessions between a given pair of ASes enable BGPsec.

The utility of any optional security mechanism is significantly increased by having secure out of band mechanism to signal that it is operationally enabled for use.   Actually, in my mind DMARC is a useful general model because you can both signal you are using a security mechanism, suggest how receivers should treat failures, and provide a notification channel to send back info on failures.  The latter two allowing you to pilot the security mechanism (policy=monitor) before you signal policy=reject.

We seem to create many security mechanisms (e.g., BGPsec, ROAs, MUD profiles, etc) that don’t have a safe means for individual users to globally test/pilot them before going into production mode.  That increases the risk/barrier to entry to those who wish to enable the technologies.

dougm
--
DougM @ NIST


From: Sidrops <[e-mail]> on behalf of Tim Bruijnzeels <[e-mail]>
Date: Thursday, February 24, 2022 at 4:19 AM
To: Job Snijders <job=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV
Hello Job, others

> On 24 Feb 2022, at 09:31, Job Snijders <job=[e-mail]> 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8205%23section-2.2&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1BEYOsez4uQzGJ8gu0rkKKHrBS%2BXYtvGWwLEU0V7VFU%3D&amp;reserved=0
>
> 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.nanog.org%2Fpipermail%2Fnanog%2F2021-April%2F213346.html&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Tom4cL9nHEw9PVbNGH21p2RkeTdcvo6xdxj57F2sjOQ%3D&amp;reserved=0
>
> 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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8205&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6ruh6AJPkmReg%2BEt5Yh9A7G6KrQJvlpzqXZ%2B%2B%2B9xLvw%3D&amp;reserved=0
>
> BGPsec Considerations for Autonomous System (AS) Migration
>        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8206&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=c0Kh9YdXBICdNgVhka9zVtRMTWgyfjDnwXduHcR6c%2Bc%3D&amp;reserved=0
>
> BGPsec Operational Considerations
>        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8207&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2F2AQrHIqzvReQ0spKjNnMmRNFvmFpfSJayFvDrWDA5c%3D&amp;reserved=0
>
> BGPsec Algorithms, Key Formats, and Signature Formats
>        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8208&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=RH8GcLnRFf3CafW8%2FTFkaH936M3nE3%2BFlnZVY0IPo7c%3D&amp;reserved=0
>
> BGPsec Design Choices and Summary of Supporting Discussions
>        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8374&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=amNinyrayWu0Skqw5TFepEpjS0mKQT6WAiDWuzawuVA%3D&amp;reserved=0
>
> Router Keying for BGPsec
>        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8635&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=AQfk6fmJvWo1lQPeFjqU61n8n0MWw%2BRjM%2Fun5R9UOpA%3D&amp;reserved=0

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
> [e-mail]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Gx6OU7d8kL0qGcOyNcap%2FMppIWDaq82xlIKdwiDiGsE%3D&amp;reserved=0

_______________________________________________
Sidrops mailing list
[e-mail]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Gx6OU7d8kL0qGcOyNcap%2FMppIWDaq82xlIKdwiDiGsE%3D&amp;reserved=0