Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

Daniel Kopp <daniel.kopp@de-cix.net> Fri, 24 August 2018 14:33 UTC

Return-Path: <daniel.kopp@de-cix.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C342612D7EA for <sidrops@ietfa.amsl.com>; Fri, 24 Aug 2018 07:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhKKtja4xfNE for <sidrops@ietfa.amsl.com>; Fri, 24 Aug 2018 07:33:05 -0700 (PDT)
Received: from de-cix.net (relay4.de-cix.net [46.31.121.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E035128CB7 for <sidrops@ietf.org>; Fri, 24 Aug 2018 07:33:04 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.53,281,1531778400"; d="p7s'?scan'208"; a="2279731"
Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 24 Aug 2018 16:33:03 +0200
Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id CEC18B00B8 for <sidrops@ietf.org>; Fri, 24 Aug 2018 16:33:02 +0200 (CEST)
Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 24 Aug 2018 16:33:02 +0200
Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1367.000; Fri, 24 Aug 2018 16:33:02 +0200
From: Daniel Kopp <daniel.kopp@de-cix.net>
To: SIDR Operations WG <sidrops@ietf.org>
Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
Thread-Index: AQHUOie94b+qhBJXv0aVQvhLDzuGmaTL0PCAgAMH8YA=
Date: Fri, 24 Aug 2018 14:33:02 +0000
Message-ID: <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net>
References: <CAL9jLaYqGt1+f3GaccNwjPOHxM34ifWDu5bhRx24PMYHpqV4XQ@mail.gmail.com> <20180822161549.GA1021@hanna.meerval.net>
In-Reply-To: <20180822161549.GA1021@hanna.meerval.net>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.6.18)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.141.121]
Content-Type: multipart/signed; boundary="Apple-Mail=_1EA96B0F-55C8-4FA3-82A8-EA59FD1E9B94"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YkJGZmQgBDFYxhoYm0c9DBfxfBE>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 14:33:09 -0000

I would like to give some feedback from the draft side.

The draft was initialised from a meeting of a group of network operators at an IXP around three years ago.
As I remember, they told us that their routers are not capable of performing RPKI validation, 
a mechanism to tag routes from the route server would help them using RPKI. 
From this, a group people from AMS-IX, DE-CIX and France-IX joined to build this draft to find a unified way to do this at IXPs.
I feel like this idea got lost on its way.

By no means the draft is there to weaken or make people to replace stronger security mechanisms. 
It's should be there for those who can't perform RPKI origin validation at an IXP by themselves.

To give an answer to the latest arguments that Job brought up:

1/ & 2/ 
The idea was to use this mechanism in a "trusted” environment at an IXP from a route server. 
We don't want the validation results to propagate beyond the IXP domain. 
From the technical discussions we had to generalize the draft to fit the EBGP world. 
There was a discussion with RFC 8097 to incorporate our needs, but the decision was made to build an separate draft. 

3/ 
Around 20 network operators met at DE-CIX on 12/2015. 
They asked for what we are trying to accomplish here with this draft.

Here are some of the comments from the operators when the idea was born:

   - The AS does not have to be in the BGP community
   - Well-known community should be defined
   - Extended community should be used in combination with a non-transitive flag
   - It is expressed that DE-CIX is getting involved in standardisation

4/ 
Having new transitive communities was implemented from the discussion on the mailing list. 
But it's true, if routes don't support it, it doesn't help anybody in addition to RFC 6810/8210. 
So if this is the case, we should change this again.

5/ 
We describe different modes of operation to provide more opportunities for the implementation at different IXPs (companies).
Most important for the draft was, that we have a common mechanism on the signaling. 
With the modes, the idea was that different IXPs can decide on how strict they wan't the "filtering" to be. 
This might help in the adoption for IXP networks.

6/ 
Yes, we don't have an explanation why we don't use locally significant BGP communities, thats true. 
In technical aspects we already discussed and then included some of the ideas, 
but if other technical implementations are a better fit, we are open to change them. 
So you would propose local communities?

7/ 
The idea of the draft was to signal RPKI at an IXP from the route server, not to be implemented globally on "all" routers. 
We should discuss any tangible consideration and add them or rework the security consideration section.

8/
"AS operators SHOULD provide
out-of-band means for peers to ensure that the ROA validation process
has not been compromised or corrupted."

It's not the aim of the draft to provide cryptographic soundness over BGP. 
The message of that section should be that IXP operators have to ensure that the validation process on their side is not compromised, 
and provide an out-of-band indicator to the peers that the validation process is not corrupted at the IXP side.  

9/ 
Network operators often announce /32 prefixes when they use blackholing for DDoS mitigation... this is just something to consider when using RPKI and blackholing at IXPs. 

10/ 
As said before, we wanted to have different modes of operation at different IXPs. 
Dropping invalids by default at the route server is an option, 
if IXP operators and their networks a ready for it they are more then welcome to do it.


The initial idea for the draft came from network operators at IXPs.
The idea of the draft is to help with the adoption of RPKI in the domain of IXPs.
The idea draft is not a replacement for RPKI validation or a global distribution of RPKI validation results.
The draft is there to help at IXPs till we all drop invalids by default :)


Best regards,
Daniel


> On 22. Aug 2018, at 18:15, Job Snijders <job@ntt.net> wrote:
> 
> I have reviewed the document (and also have reviewed draft-ietf-sidrops-route-server-rpki-light,
> and before that draft-ietf-sidr-route-server-rpki-light). I see a number
> of issues. In summary I'd rather see IETF focus its energy on promotion
> of "invalid == reject" at EBGP boundaries at both IXPs and ISPs rather
> than spend time on standardising this method.
> 
> 1/ I think it is counter productive to propagate RPKI Invalid routes
> from one BGP domain to another BGP domain (aka across EBGP boundaries)
> under the premise "but we clearly labeled the route hijack with a
> transitive extended community!". The approach does nothing to dampen the
> negative effects of BGP hijacks or misconfigurations.
> 
> 2/ Within the context of signaling within a single BGP domain there
> already is RFC 8097. I can't really see a justification to standardise
> the behavior and code-points described in draft-ietf-sidrops-validating-bgp-speaker.
> RFC 8097's design property so that the state communities cannot
> propagate outside the BGP domain are considered a characteristic of
> robustness and were a conscious decision as far as I understand.
> 
> 3/ The first sentence of the document is opiniated and doesn't seen
> anchored in reality: "RPKI-based prefix origin validation [RFC6480] can
> be a significant operational burden for BGP peers to implement and
> adopt."
> 
> Some anecdata: I have experience enabling RPKI origin validation in
> quite some ISPs and IXPs, and either the deployment is easy (thus
> draft-ietf-sidrops-validating-bgp-speaker is not needed), or the
> deployment is a burden by factors unrelated to what is described in
> draft-ietf-sidrops-validating-bgp-speaker. I've not encountered any
> situation where draft-ietf-sidrops-validating-bgp-speaker would make
> RPKI adoption any easier.
> 
> 4/ Section 2 "EBGP Prefix Origin Validation Extended Community"
> describes new transitive extended communities, but not all BGP
> implementations support defining & matching arbitrary new extended
> communities. If the argument is that using new extended communities can
> help deploy origin validation on BGP speakers that don't have support
> for RFC 6810/8210; I don't believe that can be the case. By the time
> such implementations have been updated to support
> draft-ietf-sidrops-validating-bgp-speaker, chances are the platform will
> support actual Origin Validation and this kludge won't add value.
> 
> 5/ As is well known in the operational community, "Simple Tagging" and
> "Prioritizing and Tagging" as described in section 3 do nothing for
> Internet's routing security posture. Fiddling with LOCAL_PREF is useless
> in the context of more-specific announcements. "Simply Tagging" is
> useless because the 'validating bgp speaker' is shifting the
> responsiblity of rejecting RPKI Invalid routes to the EBGP peer, who may
> or may not be able to act on this information.
> 
> 6/ No explaination is offered why using locally significant BGP
> communities is not adequate. When locally significant communities are
> used, at least the operator of the 'validating bgp speaker' that is
> proapgating RPKI invalid routes knows the receipient took the effort to
> read and try to understand the implications of this insecure approach.
> The authors have already confirmed that they use locally significant
> communities today at their IXPs, and it appears this works fine.
> 
> 7/ Section 7 'security considerations' is full of holes. The sentence
> "Therefore, a validating BGP speaker could be misused to spread
> malicious prefix origin validation results." should be rewritten to
> 
>    "Therefore, all BGP speakers can be misused to spread adversarial
>    origin validation results. Peers have no method to reliably
>    establish whether it was a validating BGP speaker that attached the
>    EBGP Prefix Origin Validation Extended Community, or an adversery."
> 
> 8/ Furthermore in section 7, it is stated: "AS operators SHOULD provide
> out-of-band means for peers to ensure that the ROA validation process
> has not been compromised or corrupted." but the document provides no
> guidance on how such an external ROA validation process can be used.
> There is no verifyable untainted end-to-end chain of custody. Amongst
> other issues related to CoC, BGP communities are not cryptographically
> signed or verifiable, so there is no way anyone, ever, can trust the
> validation results from a so called 'validating speaker'.
> 
> 9/ The "While being under DDoS attacks" paragraph is entirely out of
> scope for this document.
> 
> 10/ Since the document promotes propagating RPKI Invalid routes instead
> of rejecting those invalid announcements, (section 3 "A validating BGP
> speaker MUST support the Simple Tagging operation mode. Other modes of
> operation are OPTIONAL.").
> 
> I think this approach is a disservice to the global community. Our
> organisation (NTT) is creating RPKI ROAs for its IP resources with the
> understanding that the RPKI is a method to globally publish what BGP
> Origin ASNs NTT authorised and what prefix lengths can be expected. We
> did not publish ROAs with the understanding that RPKI Invalid
> announcements (hijacks, misconfigurations) will merely be tagged with a
> BGP community and propagated.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops