Re: [Sidrops] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05

[Job Snijders <[e-mail]>]

Dear Keyur,

On Mon, Dec 07, 2020 at 06:58:16PM +0000, Keyur Patel wrote:
> This working group last call is closed. Authors have already
> incorporated relevant feedback received during the last call and at
> this point the draft is ready to progress further. Accordingly we will
> prepare a report and forward it to IESG.

I really think this is a draft where it will proof to be useful to ask
for an implementation report from *at least two* implementations,
demonstrating interopability between the two implementations.

In this (lengthy, sorry!) email https://mailarchive.ietf.org/arch/msg/sidrops/5-sFl3RCzn7xQ0YFOD31C56Ko4o/
I tried to outline various problems I perceive with the draft in its
current form, Oliver replied to all text, but zero changes were made to
the document as he disagreed on all points of substance.

Oliver claims to have an open source implementation, (which I am happy
to believe!), and perhaps there is another implementation written by
someone else? Has it been tested how they interact with each other in
various configurations?

If there is a second implementation, the working group can confirm
whether the proposed Internet-Draft text, Oliver's implementation, and
the second different implementation are aligned with each other and
behave in exactly the way outlined in the document. An implementation
report can be as simple as listing all IETF normative terms contained
in draft, the line number, and a short comment whether the
implementation is compliant (MUST), or an implementation specific choice
was made (MAY), or anything else of note.

Specifically in this draft, I really see potential for a repeat of the
'IOS XE / origin validated extended communities'-problem that many
operators suffered from when they tried to deploy RPKI Origin Validation
in the BGP default-free zone, and I do not wish a similar repeat of
events upon the BGPSec technology stack!

Here is one of many references to the 'standardized' extended rpki
origin validation communities causing issues in networks build using
multiple BGP implementations, here is one mail thread. This was/is a
multi-year problem because of the slow upgrade cycle of field-deployed
routers: https://www.mail-archive.com/[e-mail]/msg67710.html

I think there is some kind of technology stack layering problem when the
state of a route can be manipulated through multiple channels. In this
case (1) signaled via BGP community and (2) via signalled via
RPKI-To-Router protocol, it can lead to problems for resource holders
who are trying to use BGPSec, because there can be situations where
their wishes are not expressed in the state of the network because of
interference of an unauthenticated BGP communitiy. 

So far I think some of us (perhaps myself included) have been too
focussed mostly on the security aspect (and of course everyone knowns 
extended BGP communities are not authenticated), but perhaps the
*security* aspect of it is not the real problem, the real problem might
be how an accidental misimplementation of draft-sidrops-bgpsec-validation-signaling-05
can lead to operators having to turn the feature off in the entire fleet
of devices, or roll back the software (be forced to keep running some
unwanted version).

If you ask anyone in the field about RFC 8097, virtually no operator
will tell you that RFC 8097 in any way helped them deploy RPKI Origin
Validation at scale (where scale is 100s of routers, multi-country
network, multiple vendors). What you *will* hear is that there were
interopability issues caused by the very existence of the RFC that
caused many people extra work. It also means that everybody now has to
test each and every new BGP software version they receive from their
vendor on what exactly the behavior is of the proposed bgpsec origin
validation signaling draft communities.

If this draft is published as RFC, IANA will assign 3 codepoints to be
used in some fashion in a generally unauthenticated protocol (BGP), and
from that moment all operators doing QA will need to blackbox test the
behavior of every BGP implementation they consider, to see if the
implementation does not accidentally cause deviation from 'local policy'
in any way under any circumstances.

Standardizing codepoints to signal cryptographic validation states
through unauthenticated channels really causes Internet operators down
the road deployment problems, for multiple reasons.

Kind regards,

Job

ps. I once was young and wet behind the ears and endlessly argued how
great RFC 7999 was a *great* idea. At the time it really did seem great
because DDoS attacks were a big problem, also lots of network operators
with a 32-bit had difficulty picking suitable inter-domain BGP values.

But in retrospect what I should have advocated for is a 'BLACKHOLE'
PKIX-RPKI profile, now realizing that the RPKI via RRDP/RSYNC/RRDPv2
might make for global near real-time public 'routing intention'
distribution, really rivaling with the speed at which BGP updates
propagate through the Default-Free zone.