Return-Path: 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 C787F120165; Tue, 9 Jul 2019 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=muada.com header.b=LaQmPAwg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VhM8fv5n 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 6JXcjHIoxW-k; Tue, 9 Jul 2019 08:14:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4382212023C; Tue, 9 Jul 2019 08:14:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 47F04218BB; Tue, 9 Jul 2019 11:14:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 09 Jul 2019 11:14:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:date:references:to :in-reply-to:message-id; s=fm3; bh=jrAmQzX5UfMDGLwfc6x+6fCvSMuI6 lvplfiPjuUC2HI=; b=LaQmPAwgdwzdw3NeaC4l25XRYcQTjtQBLnUSzsUEEYTFd cyRZ9UJtLGqBkJZtHmR2xJL1XaHfnVbacwvaPYXCkT7Y5O30hD7K9d0gnDFMehdI 5ae9euJJRPafl5mkEFivLH5mDuQBPKPiJrceAq7yJnTqqsnLnQ7yRSUmH2sXCOQO 2P6IXNvQ0aNJfKKLGzZf5ep7Rj7oTuedF0kLdgZEnV8DJXpKO5j+OCL2kw26VW/i 1JNLTadspztjEkwlixRiLNONyhI3enTr9hT68vC0W+Bq4CA5lQtRjqpbspgN+jxE IXCTJkLmsTRcWjSyUmLBKtknwNFDyC8PpAjszyJBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jrAmQz X5UfMDGLwfc6x+6fCvSMuI6lvplfiPjuUC2HI=; b=VhM8fv5nvTEAT/ZpWii0f9 TwDAOPkc2DdW2LccfuvGs2MUcL6q4MqqfyllVo0tZv8BLtZOcgu+jTX0cmMlykY/ EbOvI9ADYGzYp2XTW2uF4SyBo951/Je9v+bbKgbNhRFTPP12ZrlUPvEaoDS//KSE 0Tg9bgd5DsUd30Rp10aWKyHn39XtVDfJK8NaMhwlhYqhHxOX5nHnprPtjGqo/ibu BtDRP55vA0jme8Rpf2uXzOhblpoiMxC6wcq1li57yFEiEf3sUZx6XimFgOatg7dK epNvd/G1OKG8Rss1Kf0Wlo/Ep8Yw+jtAKwMaesBhaZaAPPTpNXKMXho7Aay47vHw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfuffhfvfgjkffosegrtdhmre hhtddvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhj ihhtshgthhesmhhurggurgdrtghomheqnecukfhppeekfedrkeehrdejuddrleehnecurf grrhgrmhepmhgrihhlfhhrohhmpehilhhjihhtshgthhesmhhurggurgdrtghomhenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.178.17] (83-85-71-95.cable.dynamic.v4.ziggo.nl [83.85.71.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 4589C380076; Tue, 9 Jul 2019 11:14:52 -0400 (EDT) From: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary="Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 9 Jul 2019 17:14:49 +0200 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> To: sidrops@ietf.org, grow@ietf.org In-Reply-To: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Sidrops] Different path validation options X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:14:59 -0000 --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There are now four drafts about AS path validation to remedy routing = leaks that I'm aware of: LDM: draft-ietf-grow-route-leak-detection-mitigation ASPA: draft-ietf-sidrops-aspa-verification ASCones: draft-ietf-grow-rpki-as-cones PathRPKI: draft-van-beijnum-sidrops-pathrpki The TL;DR on the four: LDM Add in-band information to BGP that signals that a peer-peer hop has = been traversed to avoid having two peer-peer hops. The idea is to do = this without new code, at first at least. As the checks must thus be = implemented with existing policy options, those will probably be easy to = implement in code on the routers later. ASPA Register customer-to-provider (C2P) relationships with extensions to = RPKI. Based on this, check the upstream and downstream parts of the AS = path, making sure there are no valleyfreeness violations and that if the = customer in the relationship between two ASes has registered a set of = provider ASes, the upstream AS is indeed one of the registered = providers. If not, then the path is considered invalid. The hop between the upstream and downstream parts of the path may be an = unregistered hop; peer relationships are not registered and in this part = of the path any relationship is a valid one anyway. If there are = additional unregistered relationships in the path, validation is not = possible and the path is considered valid. ASCones Register provider-to-customer (P2C) relationships with extensions to = RPKI. Recursively collect this information to resolve all ASes that may = be visible behind a given AS. Then do a reverse lookup in the ROA = database to obtain all the prefixes that are authorized to be advertised = by these ASes and generate a prefix filter that can be applied to a BGP = neighbor. Unclear what happens to prefixes that aren't included in the filter = because of a missing AS-Cone (P2C record) or ROA. PathRPKI The RPKI ROA format is extended to include a set of authorized transit = ASes in the upstream part of the path. Authorized ASes in the downstream = part of the path are known through local configuration. For each prefix, = the two halves of the path are combined into a list of ASes that may = appear in the AS path. These paths are sent to routers using an extended version of the RPKI to = router protocol. Routers mark a prefix as invalid if the origin AS = doesn't match as usual, and if an extended list of ASes is present, if = there are ASes in the BGP AS path that are not in the filter list (or = appear in the wrong order). So let's compare. In-band vs out-of-band LDM is the only mechanism that works in-band. In-band is inherently less = effective because the same issues that create a route leak in the first = place may also send incorrect in-band information. Deployment LDM: although it was supposed to be easy to deploy, discussion has been = going on for four years, and in my opinion, as per my earlier email = about the draft, deployment issues haven't been solved at this time. ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and = backends and the RPKI relying party software implementations. ASPA: requires unspecified changes to the RPKI to router protocol to = convey C2P records, and for routers to implement the validation logic. = (Maybe this is not necessary, but this is my best guess at this time.) = If so, that may take considerable time and subsequent updates to the = filtering logic will be difficult because of the slow update cycle in = routers. Lack of an "unknown" validation state with partial deployment = may be problematic. ASCone: generating router filters to be included in configurations is = easy to deploy, but very clumsy. Not clear how reusing the RPKI to = router protocol would work. Unclear what partial deployment would look = like. PathRPKI: changes to RPKI to router protocol necessary. However, the = scope of these changes is small. Good partial deployment as each = combination of origin AS and destination AS is immediately protected = agains route leaks even if ASes in the middle don't implement PathRPKI. Who is involved LDM: transit ASes. Leaf ASes that don't peer have no actions. ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of = their own register C2P records. All other ASes filter based on this, = most notably ASes that peer. ASCone: Transit ASes register P2C records, ASes that peer filter based = on this. Leaf ASes that don't peer have no actions. PathRPKI: origin AS registers authorized transit ASes. No specific = actions for transit ASes. ASes in the downstream part of the path filter = based on this. Security LDM: relatively low, as a malicious AS could modify the in-band = information. ASCone: middle, as ASes can incorrectly claim a P2C relationship with no = obvious recourse for the AS that is incorrectly labeled as a customer. ASPA: high, as only customers claim the customer-provider relationship. PathRPKI: a little higher, as the upstream part of the path is solely = determined by the origin AS (however, at the cost of flexibility as = transit relationship changes further upstream now require work by all = the ASes downstream of the change) What now? There are some good ideas here, but it sure looks like we haven't = figured out the best way to attack this problem. Publish four RFCs, = throw them to the wall, see what sticks? Hopefully we can come up with a = better process than that. Iljitsch= --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There = are now four drafts about AS path validation to remedy routing leaks = that I'm aware of:

LDM: = draft-ietf-grow-route-leak-detection-mitigation
ASPA: = draft-ietf-sidrops-aspa-verification
ASCones: = draft-ietf-grow-rpki-as-cones
PathRPKI: draft-van-beijnum-sidrops-pathrpki
The TL;DR on the four:

LDM

Add in-band information = to BGP that signals that a peer-peer hop has been traversed to avoid = having two peer-peer hops. The idea is to do this without new code, at = first at least. As the checks must thus be implemented with existing = policy options, those will probably be easy to implement in code on the = routers later.

ASPA

Register customer-to-provider (C2P) relationships with = extensions to RPKI. Based on this, check the upstream and downstream = parts of the AS path, making sure there are no valleyfreeness violations = and that if the customer in the relationship between two ASes has = registered a set of provider ASes, the upstream AS is indeed one of the = registered providers. If not, then the path is considered = invalid.

The = hop between the upstream and downstream parts of the path may be an = unregistered hop; peer relationships are not registered and in this part = of the path any relationship is a valid one anyway. If there are = additional unregistered relationships in the path, validation is not = possible and the path is considered valid.

ASCones

Register provider-to-customer (P2C) = relationships with extensions to RPKI. Recursively collect this = information to resolve all ASes that may be visible behind a given AS. = Then do a reverse lookup in the ROA database to obtain all the prefixes = that are authorized to be advertised by these ASes and generate a prefix = filter that can be applied to a BGP neighbor.

Unclear what happens to prefixes that = aren't included in the filter because of a missing AS-Cone (P2C record) = or ROA.

PathRPKI

The RPKI ROA format is extended to include a set of = authorized transit ASes in the upstream part of the path. Authorized = ASes in the downstream part of the path are known through local = configuration. For each prefix, the two halves of the path are combined = into a list of ASes that may appear in the AS path.

These paths are sent to = routers using an extended version of the RPKI to router protocol. = Routers mark a prefix as invalid if the origin AS doesn't match as = usual, and if an extended list of ASes is present, if there are ASes in = the BGP AS path that are not in the filter list (or appear in the wrong = order).

So = let's compare.

In-band vs out-of-band

LDM is the only mechanism that works = in-band. In-band is inherently less effective because the same issues = that create a route leak in the first place may also send incorrect = in-band information.

Deployment

LDM: although it was supposed to be easy to deploy, = discussion has been going on for four years, and in my opinion, as per = my earlier email about the draft, deployment issues haven't been solved = at this time.

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI = front- and backends and the RPKI relying party software = implementations.

ASPA: requires unspecified changes to the RPKI to router = protocol to convey C2P records, and for routers to implement the = validation logic. (Maybe this is not necessary, but this is my best = guess at this time.) If so, that may take considerable time and = subsequent updates to the filtering logic will be difficult because of = the slow update cycle in routers. Lack of an "unknown" validation state = with partial deployment may be problematic.

ASCone: generating router filters to be = included in configurations is easy to deploy, but very clumsy. Not clear = how reusing the RPKI to router protocol would work. Unclear what partial = deployment would look like.

PathRPKI: changes to RPKI to router protocol necessary. = However, the scope of these changes is small. Good partial deployment as = each combination of origin AS and destination AS is immediately = protected agains route leaks even if ASes in the middle don't implement = PathRPKI.

Who = is involved

LDM:= transit ASes. Leaf ASes that don't peer have no actions.

ASPA: All ASes. Origin = ASes and transit ASes that have transit ASes of their own register C2P = records. All other ASes filter based on this, most notably ASes that = peer.

ASCone: = Transit ASes register P2C records, ASes that peer filter based on this. = Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers = authorized transit ASes. No specific actions for transit ASes. ASes in = the downstream part of the path filter based on this.

Security

LDM: relatively low, as = a malicious AS could modify the in-band information.

ASCone: middle, as ASes = can incorrectly claim a P2C relationship with no obvious recourse for = the AS that is incorrectly labeled as a customer.
ASPA: high, as only customers claim = the customer-provider relationship.

PathRPKI: a little higher, as the = upstream part of the path is solely determined by the origin AS = (however, at the cost of flexibility as transit relationship changes = further upstream now require work by all the ASes downstream of the = change)

What = now?

There are = some good ideas here, but it sure looks like we haven't figured out the = best way to attack this problem. Publish four RFCs, throw them to the = wall, see what sticks? Hopefully we can come up with a better process = than that.

Iljitsch
= --Apple-Mail=_2EBB6D47-F9BA-4C4B-88ED-E91D42B03DB4--