IETF Logo Mail Archive

Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Nick Hilliard <nick@foobar.org> Sat, 14 January 2017 15:06 UTC

Return-Path: <nick@foobar.org>
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 46C9012957C; Sat, 14 Jan 2017 07:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9XkBOMg5hCeE; Sat, 14 Jan 2017 07:06:23 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE68812007C; Sat, 14 Jan 2017 07:06:22 -0800 (PST)
X-Envelope-To: grow@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v0EF6HFd025708 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 15:06:18 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <587A3E68.9040805@foobar.org>
Date: Sat, 14 Jan 2017 15:06:16 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.9 (Macintosh/20161202)
MIME-Version: 1.0
To: Marco Marzetti <marco@lamehost.it>
References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <c55845cc-ca06-45c8-9b2e-075421d0447c@Spark> <m2lgueejxr.wl-randy@psg.com> <CAO367rX1jjOdenqgouzbTRBfeaWz+TFoUjGFJVtUr9tifwAw3g@mail.gmail.com> <CAL9jLaZYtS9788WOYVgh3zHRRj_BhJ1vTxSqpoC_MP7kWpxxuA@mail.gmail.com> <CAO367rX=a1dbr=hWCZk=L1jDCOzbfB5dhTGxM4COSxyLKO1iSg@mail.gmail.com> <CAL9jLabEHUYcxk2bkkGub-8ps99xptf2Joy2=V5mvatNJOEkvQ@mail.gmail.com> <CAO367rUfnefFEueh-6MbC3FAahvdpJpY4ke3ugpKQwVjLwy69w@mail.gmail.com>
In-Reply-To: <CAO367rUfnefFEueh-6MbC3FAahvdpJpY4ke3ugpKQwVjLwy69w@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/S8dIpcneluu2Yu79NhigJO8FnMA>
Cc: Christopher Morrow <christopher.morrow@gmail.com>, GMO Crops <grow@ietf.org>, sidrops@ietf.org, Job Snijders <job@ntt.net>
Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <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: Sat, 14 Jan 2017 15:06:25 -0000

Marco Marzetti wrote:
> Why RPKI can't be part of that?

tl;dr: route servers and rpki are an uncomfortable fit.

rpki can be part of that, but it's problematic because the route server
is running the routing decision engine on the part of the client.  RPKI
is a relatively fine-grained tool in the list of things that are taken
into account for the best path calculation, which means that there is a
genuine difficulty in providing enough fine-grained levers so that the
route server can handle this in a way that works well for clients.

As others have pointed out, the control mechanisms that rpki allows are
much easier to handle on bilateral bgp sessions than multilateral.

These problems mostly disappear if the route server and client use
add-path, because that shifts the burden of handling the policy
application fully to the client.  Where add-path is used, there is no
requirement to mark routes with communities firstly because no routing
policy action has been taken by the route server and secondly because
the client can check the ROA themselves.  The usual caveats about
add-path apply.

Stepping back a bit, most organisations who use route servers are
sufficiently small that they don't need anything more than highly
simplistic exterior routing policies, where almost everything is handled
by the default bgp decision process documented in rfc4271, and final
tweaks are handled by applying a single med or localpref for all peers
or all transits or whatever.  This is the category of ASNs that route
servers work best for. Once an organisation grows beyond a certain size,
it's quite usual to move away from using route servers - and at a later
stage still, to move away from using IXPs in favour of PNIs.

If an organisation's routing policies are more complicated than most,
then route servers are generally unsuitable anyway.  RPKI will reduce
that boundary of suitability, but not by much.  I'd hazard a guess that
if an IXP were to provide a primitive facility in their provisioning
system to allow clients to specify whether they wanted rpki-invalid or
rpki-notfound dropped or used in the decision engine, that would satisfy
most route server client organisations' policy requirements.  Obviously
this is not going to work for all organisations, but adding in more
fine-grained controls runs into diminishing returns very quickly indeed,
as has been implicitly noted in the ixp industry by the scarcity of
generally accepted policy controls outside the usual "redistribute or
don't redistribute my prefixes to ASN X" community tags.

If AS path validation ever happens, then this probably not work with
route servers at all, but that's a different thing, outside the scope of
this conversation.

Nick

v2.23.0 | Report a Bug | By Email