Subject: [Sidrops] Fwd: [routing-wg] misconceptions about ROV

From: Randy Bush <[email-masked]>
Date: Mon, 21 Feb 2022 13:35:54 -0800

i should not have to say this, but ...

From: Randy Bush <[email-masked]>
Subject: [routing-wg] misconceptions about ROV
To: RIPE Routing WG <[email-masked]>
Date: Mon, 21 Feb 2022 13:13:00 -0800

lately, i am getting flak about ROV not providing protection from
this or that malicious attack.  indeed it does not.

in the ROV design, we DELIBERATELY did NOT try to cover malicious
attacks.  we also did not try to solve world hunger.

repeat 20 times: "ROV is not a security mechanism.  it is only meant
to ameliorate accidental misconfigurations."

yes, a screwdriver sucks as a hammer.

we do seem to see that route mis-originations are propagating less
widely; and presume this is due to ROV, especially in top tier
providers.  this is good.

and once more for good luck: "ROV is not a security mechanism.  it
is only meant to ameliorate accidental misconfigurations."

randy

---

From: Di Ma <[email-masked]>
Date: Tue, 22 Feb 2022 08:43:26 +0800

Randy,

I don’t care the way we/they see ROV but the way we use it.

ROV is good as long as it can remedy accidental misconfigurations that bring about routing security problem/catastrophe.

If someone doesn't  think ROV is not a security mechanism from cryptography perspective, I settle for that.

Di

> 2022年2月22日 05:35，Randy Bush <[email-masked]> 写道：
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 Feb 2022 17:19:41 -0800

di:

> ROV is good as long as it can remedy accidental misconfigurations that
> bring about routing security problem/catastrophe.
> 
> If someone doesn't think ROV is not a security mechanism from
> cryptography perspective, I settle for that.

operationally, it is trivial to subvert/attack ROV; and that has
nothing to do with the cryptography.  it's simple net ops.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 22 Feb 2022 09:41:36 +0100

Hi,

> On 22 Feb 2022, at 02:19, Randy Bush <[email-masked]> wrote:
> 
> di:
> 

Which is why I think it would be very good to re-double the WG efforts
on moving ASPA forward.

It was also suggested in the past few months that BGPSec should get
a new impulse by supporting it in the RIPE NCC hosted RPKI:
https://www.ripe.net/ripe/mail/archives/routing-wg/2021-September/004410.html

My responses in that thread were a bit skeptical to the point of being
misunderstood as obstruction to the idea. I am not against BGPSec itself.
Far from it. I just want to believe that it can work.

My issue was about how BGPSec can be implemented incrementally and 
scale *automatically*. I know of the idea that operators turn it on (and off?)
because they somehow know (out-of-band?) that it's safe to do so. But,
(1) I don't see this scale, (2) this can result in outages if operators get
it wrong (path invalid), and (3) I don't see this work cross-transit - 
which is probably where the problem of spoofed origin attacks is worse.

In my view, this comes from the property that BGPSec validated paths can
only be valid or invalid. There is no 'unknown' - because in a nutshell
then adversaries could do a simple downgrade attack.

All that said, if we could have a constructive discussion about solving
the BGPSec deployment challenges then I would welcome it very much. Perhaps,
it would be possible to signal (with signed objects in the RPKI) when
BGPSec is applicable - and when a downgrade has happened.. somehow? No, I
don't have the answer but we may want to put our minds together.

Tim

---

From: Di Ma <[email-masked]>
Date: Tue, 22 Feb 2022 16:51:36 +0800

Tim,

It seems to be a good idea to do signaling and have a sort of signed object for policy indicator :-)

Di

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 22 Feb 2022 10:19:23 +0100

> On 22 Feb 2022, at 09:51, Di Ma <[email-masked]> wrote:
> 
> Tim,
> 

I think we need a model where we can have valid/invalid/not-found (or equivalent) for paths.

Then we people can turn validation on with much less risk, and people can start implementing
BGPSec on their routers independently with more immediate (albeit initially small) benefit.

If and how we can get there is another matter. Perhaps a signed policy indicator (presence of
router certs?) will help, but it may not be enough.

Note that all this is orthogonal to ASPA. ASPA essentially says whether paths are plausible,
and BGPSec (valid path) says what actually happened. Though if ASPA informs that an adjacency
is invalid then this could perhaps be valuable input to BGPSec path validation with regards
to downgrade detection.

Tim

---

From: Job Snijders <[email-masked]>
Date: Tue, 22 Feb 2022 11:47:53 +0100

> I think we need a model where we can have valid/invalid/not-found (or

Do we really? Slide 10 "BGPsec is protocol, not policy":
https://archive.nanog.org/meetings/nanog52/presentations/Tuesday/Bush-bgpsec.pdf

> Then we people can turn validation on with much less risk, and people
> can start implementing BGPSec on their routers independently with more
> immediate (albeit initially small) benefit.

I am not so sure about the above, it seems the reasoning stems from a
desire to seek compromise without regard for the consequences of such
settlement. The notion of "less risk" needs to be quantified more
precisely to have meaning.

I understand the goal of BGPsec deployment to be to reject
BGPsec-invalid paths, that's all. If the signatures are trash: don't
accept it, I don't see 'middleground'.

Are there any scenarios in which one would want to accept BGPsec invalid
paths? Similarly, RP implementations discard malformed ROAs, network
operators reject RPKI ROV-invalid BGP updates.

If people perceive risk: don't enable BGPsec, let others be the early
adaptors. It is early days, lots of software still has to be written,
lots of testing is required.

> Note that all this is orthogonal to ASPA. ASPA essentially says
> whether paths are plausible, and BGPSec (valid path) says what
> actually happened.

Yes, the above is an accurate summary.

> Though if ASPA informs that an adjacency is invalid then this could
> perhaps be valuable input to BGPSec path validation with regards to
> downgrade detection.

Only time and research can tell whether it is a useful signal to
transfer from one plane to another plane.

Regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 22 Feb 2022 12:38:59 +0100

Hi,

> On 22 Feb 2022, at 11:47, Job Snijders <job=[email-masked]> wrote:
> 

I did not say it's policy. I don't know what would be needed. But it
would help if people had an automated way to know that BGPSec validation
can be applied or not for a given path / session etc.

> operators reject RPKI ROV-invalid BGP updates.

Currently you need to accept BGPSec invalid path on any path where
at least one ASN does NOT participate in BGPSec. Applying BGPSec path
validation is only safe when you know that ALL ASNs on the path
participate.

> lots of testing is required.

What I am hoping for, essentially, is that a partial deployment model
would be more feasible where people are not expected to form islands,
which merge, without specifying how those islands form or merge.

If there would be a 'not-found' like state for the *path* validation,
and reliable way to clearly detect an *invalid* path as opposed to
a path with non BGPSec capable ASNs, then a simple reject *invalid*
policy could be applied.

I understand this is not trivial. If it were, it most likely would
have been solved before 2011. Still, it may be useful to think about
this again.

Reject invalid && partial deployment has worked well for ROV. And,
time will tell, but I strongly believe it will work well for ASPA.
I would like something like this to work for BGPSec.

Alternatively - rather than having a 'not-found' it may be an option
to automate a safe decision on accepting only 'valid'. See below.

> transfer from one plane to another plane.

The two are orthogonal, but may complement each other very well.

Suppose, for the sake of argument, that routers would know (through
validation) that all ASNs on a path are certain to participate in
BGPSec then they could also 'safely' reject any such BGP invalid
paths. If this decision can be automated then operators don't need
to create or destroy the islands manually.

Adversaries could still spoof paths, but if the ASPA 'AS_PATH' is
then invalid - they would presumably be rejected on that basis.

If the ASPA 'AS_PATH' would be valid and accepted, then the addition
of BGPSec validation on that path (provided the ASNs are known to
participate) would give additional security.

As I said I don't know.. I am just trying to look at it from another
angle.

---

From: Job Snijders <[email-masked]>
Date: Tue, 22 Feb 2022 12:43:54 +0100

On Tue, Feb 22, 2022 at 12:38:59PM +0100, Tim Bruijnzeels wrote:
> Currently you need to accept BGPSec invalid path on any path where at
> least one ASN does NOT participate in BGPSec. Applying BGPSec path

Are you perhaps confusing 'unsigned' and 'invalid' paths?

Regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 22 Feb 2022 12:51:26 +0100

> On 22 Feb 2022, at 12:43, Job Snijders <[email-masked]> wrote:
> 

Perhaps. It was my understanding that an 'unsigned' path should be
considered 'invalid' because otherwise one can simply strip signatures
on an 'invalid' path to do a downgrade attack.

It would help a lot of that were detectable.

My RFC-searching-fu is abandoning me at the moment but any pointers
would be welcome.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 22 Feb 2022 19:13:53 +0000

> validation is only safe when you know that ALL ASNs on the path

I can’t parse these two sentences Tim. They seem to contradict each other
when I read em. The AS signing chain is stripped as soon as an update leaves the
original BGPSEC “island”. I thought that an AS can’t just restart the signing chain
subsequently.

> which merge, without specifying how those islands form or merge.

This desire seems rather inexplicable to me, in that if one allows routes where
the AS signing chain is broken then it could be broken becuase of
tampering or other malicious acts as much as they are broken for more
benign reasons. How would the BGP speaker receiving the route tell the 
difference? And if it can’t, then it seems to me that there is no point in
adding this additional workload to update processing if in fact it is
incapable of detecting tampered AS Paths.

Geoff

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 22 Feb 2022 22:37:43 +0100

> On 22 Feb 2022, at 20:13, Geoff Huston <[email-masked]> wrote:
> 
> 
>>> 

Let me try to be more clear then. I am not trying to suggest the signing
chain is restarted.

BGPSec path validation procedure results in one of two states: 'Valid' and
'Not Valid'. (section 5.1 of 8205).

A BGPSec path as a whole can only be 'Valid' if all signatures are present,
and they are all valid.

The absence of any signature, whether it's because the update left a
capable island, or an adversary removed signatures, results in 'Not Valid'.

Rejecting 'Not Valid' is therefore only safe on known islands.

Outside of these islands all paths are BGPSec 'Not Valid'. Therefore
validation cannot be enabled outside of known islands. You would accept
'Not Valid' outside of islands, even though you are not checking that state
in that context. Sorry if that was cryptic.

> incapable of detecting tampered AS Paths.

Although I used the terms 'not found' and 'unknown' somewhat loosely
elsewhere I did not mean to say that broken chains should be acceptable.

One take on this could be that routers can know whether a path consists
of only "participating" ASNs and then treat it as an "island" automatically
without the need to be manually enabled. Such automation could allow
operators to opt-in to validation for parties that they don't have a direct
relationship with - e.g. cross transit.

If the "island" decision can be automated then stripping of signatures
on them could be interpreted as malicious.

This limits path spoofing option to non-participating ASNs. This will
be harder to do as more ASNs participate in BGPSec *and* ASPA validation
(if deployed) will further limit the adjacency options. This also enables
ASNs to protect themselves in two (orthogonal) ways - giving them
immediate benefits to deploy.

Of course the above could only ever work if the router can know that
an ASN "participates". The presence of a router certificate for the
ASN could give a clue - but I am not sure that it is enough. Is creating
such a router certificate a valid pledge? If it is, then that means
much less standards work would be needed.

If it isn't then a separate signed statement by the ASN that they
will do BGPSec whenever they get a signed path could help. This could
be done using a new RPKI signed object type, or by way of an extension
in the existing BGPSec router certificate perhaps. But this would also
require a new RPKI-RTR version as well.

Tim

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Feb 2022 16:25:12 -0800

> BGPSec path validation procedure results in one of two states: 'Valid'
> and 'Not Valid'. (section 5.1 of 8205).
> 
> A BGPSec path as a whole can only be 'Valid' if all signatures are
> present, and they are all valid.
> 

almost.  there is also NotSigned aka BGP4.

as it leaves an island, it becomes Unsigned.  it can not become signed
at any further hop.

> Outside of these islands all paths are BGPSec 'Not Valid'.

not exactly, they are Unsigned

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 23 Feb 2022 09:13:02 +0100

> On 23 Feb 2022, at 01:25, Randy Bush <[email-masked]> wrote:
> 

I know they cannot become signed again.

I was talking about 'Valid' and 'Not Valid' paths, not signatures.

> not exactly, they are Unsigned

Am I correct though that if BGPSec *Path* validation were to be applied to
unsigned paths they would be considered 'Not Valid'?

And isn't this what the downgrade issue (for which I cannot find a ref now)
is about? Rather than violating signatures, the signatures can just be
stripped.

Meaning that even if you would call such a path 'not signed', rather than
'not valid' accepting those paths would mean that 'not valid' can be
easily avoided by adversaries.

Hence, I believe, the idea to only accept BGPSec *path* 'Valid' on BGPSec
"islands".

Is there a way that these "islands" can be recognised automatically, and
cross transit (i.e. include unknown parties)? See the second part of the
email I sent earlier.

Tim

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Feb 2022 04:27:20 -0800

> Am I correct though that if BGPSec *Path* validation were to be
> applied to unsigned paths they would be considered 'Not Valid'?

no.  not validatable, if you wish.  not valid is a result of
validating the signature chain.  as one can not do that with
a non-bgpsec path, it can be neither valid or not valid.

> And isn't this what the downgrade issue (for which I cannot
> find a ref now) is about? Rather than violating signatures, the
> signatures can just be stripped.

the downgrade attack is a router accepting a bgpsec path and
producing a bgp4 path toward the 'victim'.  in a more likely
operational scenario, the router simply refuses bgpsec from its
incoming peer, so that peer sends it bgp4 which it then sends on
to the 'victim'.  though that make a louder signal of the attack.

> Meaning that even if you would call such a path 'not signed',
> rather than 'not valid' accepting those paths would mean that
> 'not valid' can be easily avoided by adversaries.

yes

> Hence, I believe, the idea to only accept BGPSec *path* 'Valid'
> on BGPSec "islands".

no.  routers on those islands still need to reach non-bgpsec
destinations and even bgpsec speaking destinations on other
islands.  this means they must also accept unsigned paths.

> Is there a way that these "islands" can be recognised
> automatically, and cross transit (i.e. include unknown
> parties)?

you could tunnel between islands; but that is operationally
unlikely.  i remember uucp :)

and you can not take an unsigned path and start signing.  to what
are you attesting?

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 23 Feb 2022 14:43:04 +0100

> On 23 Feb 2022, at 13:27, Randy Bush <[email-masked]> wrote:
> 

Yes, of course.

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.

> and you can not take an unsigned path and start signing.  to what

That is not what I was trying to suggest.

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.

Tim

---

From: Job Snijders <[email-masked]>
Date: Thu, 24 Feb 2022 09:31:30 +0100

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.

> could be performed. It would be an error if signatures were missing or
> invalid.
> 
> 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.
> 
> 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.
> 
> 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.
> 

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

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

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Feb 2022 10:16:39 +0100

Hello Job, others

> On 24 Feb 2022, at 09:31, Job Snijders <job=[email-masked]> wrote:
> 
> Hello Tim, others,
> 

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.

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

> 	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

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 24 Feb 2022 11:50:52 +0100

This will be very off-topic, but is likely also founded into a misconception:

> On 20220224, at 10:16, Tim Bruijnzeels <[email-masked]> wrote:

[..]

> operational future deployment. [...]
> 

Do you want to have a discussion, or do you want to just tell people to stop discussing because you are disagreeing with the arguments they are providing?

> 
> [..] was kind enough to answer.

Are you implying that other people are being unkind?

Calling people naive, is not being very kind in my book...

Greets,
 Jeroen

   (who is not technically capable of adding anything to the technical discussion because I have not read up properly;
    hence letting the people talk who did read up and have broad experience in running actual infrastructure --- running code et al --
    but I hate seeing such comments in a thread.... and actually, we should not focus on those and just likely ignore those kind
    of comments completely, but ... hard

    please gentlemen and other ladies, keep things civil and technical instead of attacking eachother between lines,
    it does not cause a worthy environment to contribute to.

    Please have a good chill, reconsider why people contribute to the IETF, write code and contribute, then come back with arguments.

    I will be adding technical comments when I have actually fully read up, likely coded a few things and deployed things though
    but that requires time that is not available at the moment... I will be back, and am reading along.

---

From: Job Snijders <[email-masked]>
Date: Thu, 24 Feb 2022 11:54:44 +0100

On Thu, Feb 24, 2022 at 10:16:39AM +0100, Tim Bruijnzeels wrote:
> 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.

At the risk of repeating myself: signalling at AS-level granularity
seems too coarse for deployment reality. An AS might be able to do
BGPsec in one part of their network, but not in other parts of their
network. Another consideration: not all Autonomous Systems operate with
a coherent backbone, some AS are "islands".

Imagine AS 65000, 65001, and 65002, who all have half their ASBR
footprint BGPsec enabled; neither of those 3 AS can 'commit' to BGPsec;
other than through per-BGP-session negotation. BGPsec islands connect to
each other by virtue of unbroken valid signature chains.

> operational future deployment.

I appreciate all the help you are willing to provide, but I question the
soundness of initiating discussion about 'future deployment' while the
first steps have yet to be set on the path towards deployment. How can
anyone meaningfully comment on future operational deployment challenges
without any operational experience with BGPsec "as is"?

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

At times it seems you look to this WG for help, other times you purport
opinion on what the future direction of RPKI / Secure Routing should be,
and then other times you appear to engage in research/brainstorm
activities. It is hard to tell which is which at times.

The current discussion might appear challenging because your positions
appear inconsistent: first you expressed heavy skepticism to the point
that it might even discourage others to consider BGPsec ("it doesnt
scale"), then you pivot to suggesting new object profiles, all the while
writing messages which contain imprecise terminology.

Here you ask for pointers:
https://mailarchive.ietf.org/arch/msg/sidrops/shD2HMkgDrXSf7dLI6GAkOuaoKg/
Here you reply you could find the documents yourself:
https://mailarchive.ietf.org/arch/msg/sidrops/DcbDU25miO0Rcc9Hbd85kaDvDx0/

Here you ask whether there is 'operator demand':
https://mailarchive.ietf.org/arch/msg/sidrops/XOHyvcRKH6VOG310jAUppzRXliA/
But already back in October 2021, you yourself noted: "Wrt BGPSec.. I am
actually very happy to see that so many people are in favor of supporting
it.":
https://www.ripe.net/ripe/mail/archives/routing-wg/2021-October/004454.html

It seems to me that one could extrapolate appetite for BGPsec in managed
CA environments to mean that people also would like BGPsec support in
all other CA implementations.

Let's make BGPsec a reality! It all starts by actually making BGPsec
available to operators.

Regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Feb 2022 13:12:38 +0100

Job,

Thank you for your reply.

I understand your concern about getting the 'basics' deployed first.
I am also willing to implement basic support in krill after 0.10.

I interpreted your use of capitals to mean that you wanted me to stop
the discussion beyond the current set of standards. I feel that you
interpreted my desire to discuss these things as unwillingness to
implement - but I don't see how these things conflict.

With regards to "looking for help".. not the most respectful way
of phrasing it.. but let's move on.. I asked questions about the
downgrade specifically. I don't think that I am the only one who was
unclear on this specific issue - and I felt that clarity would help me
and others.

With regards to "inconsistent positions".. This is not a bug, but a
feature of discussions involving listening and learning.

The source of this communication style is that I was trying to have
an open face-to-face-like exchange over email.

Since you and I are both going to the IETF meeting - how about having
a chat there and clearing things up?

Tim

> On 24 Feb 2022, at 11:54, Job Snijders <[email-masked]> wrote:
> 
> Here you ask for pointers: https://mailarchive.ietf.org/arch/msg/sidrops/shD2HMkgDrXSf7dLI6GAkOuaoKg/
> Here you reply you could find the documents yourself: https://mailarchive.ietf.org/arch/msg/sidrops/DcbDU25miO0Rcc9Hbd85kaDvDx0/
> 
> Here you ask whether there is 'operator demand': https://mailarchive.ietf.org/arch/msg/sidrops/XOHyvcRKH6VOG310jAUppzRXliA/
> But already back in October 2021, you yourself noted: "Wrt BGPSec.. I am actually very happy to see that so many people are in favor of supporting it.":

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 24 Feb 2022 13:34:27 +0100

Dear Tim,

> On 20220224, at 13:12, Tim Bruijnzeels <[email-masked]> wrote:
[..]
> of phrasing it.. but let's move on..

Is such a sentence needed?

Greets,
 Jeroen

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Feb 2022 13:53:42 +0100

Dear Jeroen

> On 24 Feb 2022, at 13:34, Jeroen Massar <[email-masked]> wrote:
> 
> Dear Tim,
> 

Is it nice if someone's character is framed a "looking for help"?

Did you not just say: "...instead of attacking eachother between lines"?

Well I noticed the attack and I mentioned that I am letting it pass.
I even proposed to clear things up in person .. in the bit you did
not quote that is.

Tim

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 24 Feb 2022 14:09:13 +0100

> On 20220224, at 13:53, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Dear Jeroen
> 
> not quote that is

You mean the section in a different paragraph.

Please realise, that many people who read a sentence like the one I quoted above, people stop reading.

Hence, do please avoid those kind of sentences, or the one you use above again (not removing them, so that people see context) where you effectively blame me for not properly quoting you.

Please, as in my previous, longer message, keep it technical.

I am not part of the discussion, as clearly, there is some kind of hostility or other unknown factor that is not part of what should be on an IETF list.

As per my previous, longer and ignored mail:

----
----

Greets,
 Jeroen

---

From: "Montgomery, Douglas C. (Fed)" <[email-masked]>
Date: Thu, 24 Feb 2022 23:53:25 +0000

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 <[email-masked]> on behalf of Tim Bruijnzeels <[email-masked]>
Date: Thursday, February 24, 2022 at 4:19 AM
To: Job Snijders <job=[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV
Hello Job, others

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

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

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

Tim

> 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
[email-masked]
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

---

From: Job Snijders <[email-masked]>
Date: Fri, 25 Feb 2022 14:17:41 +0100

Hi Doug, others,

On Thu, Feb 24, 2022 at 11:53:25PM +0000, Montgomery, Douglas C. (Fed) wrote:
> 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.

I think the cake should be sliced up differently: the concept of "pilot
testing" shouldn't be in the protocol specs, but in the approach to
deployment.

In my experience operators are happy to request additional ASNs &
arrange separate IPv4/IPv6 space for pilot studies. Both AS and IPv6
INRs are extremely affordable, a fraction of the overall cost of
studying a new Internet technology. At least, this was my experience
with IPv6 a decade+ ago, and with RPKI ROV in recent years. I fully
expect that early adoptors of BGPsec are able to construct appropriate
pilot setups too. From that perspective I don't see the need to add new
object profiles to facilitate BGPsec, because doing so would set the
clock back.

> That increases the risk/barrier to entry to those who wish to enable
> the technologies.

At some point the conceptual "are you sure?" confirmation dialogue boxes
have to transform into something that is real. Cryptographic
attestations only have meaning when Relying Parties actually honor the
attestations: indeed, RPs have to exhibit willpower to discard invalid
objects or routes, otherwise the attestations become worthless (or
worse! read on below).

I think one of the unforeseen and accidental obstacles towards global
deployment of RPKI ROV was the following awkward dynamic:

(1) the propaganda machine was thundering on all cylinders to promote
    ROA creation
(2) many folks misconfigured their ROAs, resulting in the *crazy
    situation* that in its peak there were between 5,000 ~ 6,000
    invalids BGP routes in the DFZ [0]
(3) many folks didn't notice their ROA misconfigurations, because nobody
    was performing ROV invalid==reject. Also, there was no incentive to
    fix broken ROAs, because nobody was validating.
(4) people became afraid to enable ROV on ingress EBGP, because there
    were so many invalids "I can't just reject 5K routes!".

It is not hard to imagine how steps 1 -> 2 -> 3 -> 4 in an alternative
universe could've resulted in complete disaster and dismissal of RPKI
ROV.

It took significant community effort to overcome the above downward
spiral: people had to be taught what CA Intent is, that 'harsh'
rejection of invalid information is exactly what makes the security
mechanism work, and that the 5K invalids did not pose a risk to business
[1] [2].

As for the misconfigured ROA creators: many learned the surprisingly
positive consequences of making bad decisions. Sometimes operators have
to touch the hot stove. :-)

How the above observations potentially apply to BGPsec isn't certain
yet, but all of us definitely have to consider what we can learn from
the ROV experience when we collectively plan and labor the next phase of
routing security.

Kind regards,

Job

[0]: https://www.denog.de/media/DENOG11/day1_1_rpki-one-year-later_yPfR6rl.pdf
[1]: https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html
[2]: https://storage.googleapis.com/site-media-prod/meetings/NANOG84/2488/20220214_Madory_Measuring_Rpki_Rov_v1.pdf