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

From: Keyur Patel <[email-masked]>
Date: Mon, 7 Dec 2020 18:58:16 +0000

Folks,

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.

Regards,
Keyur

From: Keyur Patel <[email-masked]>
Date: Wednesday, September 30, 2020 at 7:35 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - ends 7/October/2020

Hi Folks,

The update version of the draft incorporating all the previous comments was published today and can be found at: https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05. The wg chairs extended the call for a week. The WGLC will now end on October 7, 2020.

Best Regards,
Keyur

From: Sidrops <[email-masked]> on behalf of Keyur Patel <[email-masked]>
Date: Thursday, September 10, 2020 at 10:27 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

Hi Folks,

The wg chairs extended the call for a week in hopes that we would have a consensus. Seems like more discussion is needed and so we plan extend the call for 1 more week. The WGLC will now end on September 17, 2020

Best Regards,
Keyur

From: Keyur Patel <[email-masked]>
Date: Tuesday, August 11, 2020 at 11:45 AM
To: "[email-masked]" <[email-masked]>
Subject: [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020

Hi Folks:

A working group last call has been requested for draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State Signaling”. Please reply to the list with your comments. The WGLC will end on August 25, 2020.

The draft can be found at:  https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-03.  Authors, please reply indicating whether you're aware of any relevant IPR that hasn't been disclosed.

Regards,
Keyur

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 Dec 2020 20:54:03 +0000

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

---

From: Keyur Patel <[email-masked]>
Date: Fri, 11 Dec 2020 20:09:04 +0000

Dear Job,

Thanks for the comments and the detail review of the draft. Couple points to note:

- The working group charter does not require us to have multiple implementations as of now. I do see your email suggesting to improve/modify charter on this topic.

- The chairs closed the WGLC for the draft on December 7th 2020. This WGLC was supposed to be closed on October 7th. The authors of the draft believes your comments were addressed. Your email suggests otherwise.  The chairs had a quick chat and we believe we can re-open the last call with hopes that you and other working group members can have their comments/concerns addressed.

Best Regards,
Keyur

On 12/7/20, 12:54 PM, "Job Snijders" <[email-masked]> wrote:

    Dear Keyur,

    Kind regards,

    Job