From nobody Mon Jun 17 10:28:08 2019 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 ACB26120077 for ; Mon, 17 Jun 2019 10:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Tp6tq1MdsUx3 for ; Mon, 17 Jun 2019 10:28:04 -0700 (PDT) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB1E120159 for ; Mon, 17 Jun 2019 10:28:04 -0700 (PDT) Received: by mail-ed1-f54.google.com with SMTP id s49so17311892edb.1 for ; Mon, 17 Jun 2019 10:28:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=8/DEFmLUtm/YSUW5bZrvU+GKWNjUmjETDk2ux9TDWDM=; b=tVeivustKVQA2d1mUDZrzeUM2Zcb7B0f44vvoEIL2NQK0JoWlGb/kk/TRfirG0aHLK 4PGU19W00eKIL7EFFIQa/J2DVTqYqV1RQFmR1Uvp4d5Q8A3EiEMSUJk+NDxI8lypubUl fKc9dMNsyti2oW9uLH2Cw6v/5S/Qi5MB+j4PeMUYVaglg9qFqr11gqP4kk6qEVNWyvxO 0aqEHQhWD5Rvw8qq6npt0QhY5ayqx8TodTJl8ZMlZmXCWyZx5KFx9bV4iDpBQZ4SNPGL trUCNeS9jnAPDa7WPJPon8IaVGWfZp0h3V8LDExLVC2X56ba6WtaLE2pM8YZ6lQIHN60 pc7g== X-Gm-Message-State: APjAAAW/Ceth8OuwCiCKGFrURhpc+GPrziOeBuLWDfDGz3+xTv87P4Iv e2iX5IQsJyBQD3c/O4YGl3tQmfEtsePh/g== X-Google-Smtp-Source: APXvYqx/sVvqha7ukmUVgChNoQcjaU4kmqA58EbPcILciDLS1Fd+aWJZk/67xt00naFT306oSwPlnw== X-Received: by 2002:a50:a4ad:: with SMTP id w42mr36562356edb.230.1560792479998; Mon, 17 Jun 2019 10:27:59 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:89c7:dffa:76e7:5cf0]) by smtp.gmail.com with ESMTPSA id 15sm2276962ejz.24.2019.06.17.10.27.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 10:27:58 -0700 (PDT) Date: Mon, 17 Jun 2019 19:27:57 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: <20190617172757.GI92329@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: [Sidrops] New validator implementation: OpenBSD's rpki-client(8) 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: Mon, 17 Jun 2019 17:28:07 -0000 Dear working group, I'm pleased to announce the publication of the liberally licensed rpki-client! The software is usable and produces useful output, but is still in volatile state. The portable version (which can run on Linux and FreeBSD) is now available via github: https://github.com/kristapsdz/rpki-client The OpenBSD project has imported a copy of the source code into its main development tree. It is expected to simmer there for a bit, there will be some back and forth between the openbsd specific and -portable version (like with other projects such as ssh and bgpd). My hope is that we can now bring the code to sufficient high quality level so that it can be a standard tool in the 6.6 release of the OpenBSD operating system (November 2019)! At that point we hopefully can point at the first Network Operating System that has a built-in BGP daemon *and* RPKI validator. I hope is that the likes of Arrcus, Cisco, and Juniper will take note and copy! :-) What the software can do so far: - download all RPKI repositories (with openrsync) - validate the RPKI tree - output RPKI VRPs in OpenBGPD format This may not sound like much, but getting to this stage was quite some work. Rpki-client is a CLI tool meant to be run from something like cron, it is not a daemon and does not support RTR. You'd probably end up using rpki-client in combinatino with Cloudflare's GoRTR if you need RTR. What the future holds ===================== 1/ rpki-client depends on OpenSSL. This is fine for all non-OpenBSD systems, but not acceptable for an OpenBSD release. People are working to extend LibreSSL in such a way that it supports the CMS functions that rpki-client requires. Having multiple commonly used cryptographic libraries that can be used in context RPKI would a huge win for the Internet community. 2/ Adherance to coding convention & style clean up. Rpki-client has been handed over from its principal author Kristaps Dzonsons to the wider OpenBSD community. An inaugural step in this process always is to make the code pretty and shiny. 3/ More outputs, currently the code only supports OpenBGPD format, we want to add JSON (for easier integration with GoRTR) and perhaps some other useful formats. 4/ Porting to other operating systems. The code has been released, we now have to wait for package maintainers and porters to pick up the code and package for CentOS, Debian, FreeBSD, etc! 5/ Add support for RRDP. Rpki-client currently only supports the rsync protocol. In order to support the lowest common denominator across all RIRs, a new tool was developed as part of the rpki-client project, namely openrsync https://github.com/kristapsdz/openrsync/ developing a full GNU rsync alternative took away from the time available to develop RRDP support, so we'll have to add that in later. Let me know if you have any questions! Kind regards, Job From nobody Wed Jun 19 09:51:14 2019 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 7AD2C120316; Wed, 19 Jun 2019 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 NUSogyHt9lDg; Wed, 19 Jun 2019 09:50:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F311202E4; Wed, 19 Jun 2019 09:50:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B68FAB81286; Wed, 19 Jun 2019 09:50:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidrops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190619165034.B68FAB81286@rfc-editor.org> Date: Wed, 19 Jun 2019 09:50:34 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8608_on_BGPsec_Algorithms=2C_Key_Formats?= =?utf-8?q?=2C_and_Signature_Formats?= 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: Wed, 19 Jun 2019 16:51:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8608 Title: BGPsec Algorithms, Key Formats, and Signature Formats Author: S. Turner, O. Borchert Status: Standards Track Stream: IETF Date: June 2019 Mailbox: sean@sn3rd.com, oliver.borchert@nist.gov Pages: 21 Characters: 43153 Obsoletes: RFC 8208 Updates: RFC 7935 I-D Tag: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05.txt URL: https://www.rfc-editor.org/info/rfc8608 DOI: 10.17487/RFC8608 This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document is a product of the SIDR Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 20 03:36:47 2019 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 9DCA51200FA for ; Thu, 20 Jun 2019 03:36:45 -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=i381I1ns; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fwokiHe+ 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 9cNhxmTV0_Mj for ; Thu, 20 Jun 2019 03:36:43 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEB7120073 for ; Thu, 20 Jun 2019 03:36:42 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E0593315 for ; Thu, 20 Jun 2019 06:36:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 20 Jun 2019 06:36:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:message-id:date:to; s= fm3; bh=x92Z7gkGfZJe/Uf91iXXIIe5ZIMhTITYscQ2brSB5a8=; b=i381I1ns CO6PkY9j1AyIJhKjBjZ3UrjvssWTONjoNHrQ/+aJWV1cOruFZTKPHcfge2k2Q1Xa Bfjsus5vHudiMmxPYCNxl5vxKNP/JmKy2M78uV9TsnXjvYXyk1+ys/oKJ0EVsIol ZodQ7sv7DQpCqZDsmsrDSpMmh9AQPUtS7+YTexjXZUJkYMPzQxL+Fu48IEi6N2bu Q2hcexsMSrVDLN3pyebFSL+2oPZHv8zBgE2X2WG0Ak7Bu7QicpYLl1SXIXbLypCj 0du5qsxkW49UWx5DhZiawWeLyhbB5hhnCfelscpkECXncIIKELAYTmlQYXRdu//G zdqvIqsvR26L1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=x92Z7gkGfZJe/Uf91iXXIIe5ZIMhT ITYscQ2brSB5a8=; b=fwokiHe+mD73qjFXHnnx+z3goT/BHd8PfoRaslntEm2A9 BE0VBOxeDHTcomSY54S55c9ug6G2hvBXOVOvScLN6YHlohKyaVB39ZoikJWUyNQK vGlX7bCBkEz6T/85sUYu+rq6r/c/2Dm6rWoCoFvpB0TShfklhYynhQayBtJKTA2P b2b0NSk+xtQYQSckhAoOs+CYr8WdCo3OgCgh4M8A9A+q20X4BQYSSEAgALQyVYvp nvUKRXeJYMRd+tq+6Jgx2iNNb1DUcR36dWrO+N5lcYcbpNtFJOAszcGORLPyRpSm syF3qlkYNoUuns50LNP43zrex2AaIdX3IXgRd0Rrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmrehhtd dvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihht shgthhesmhhurggurgdrtghomheqnecuffhomhgrihhnpehmuhgruggrrdgtohhmpdgsgh hpvgigphgvrhhtrdgtohhmpdhivghtfhdrohhrghenucfkphepkeefrdekhedrjedurdel heenucfrrghrrghmpehmrghilhhfrhhomhepihhljhhithhstghhsehmuhgruggrrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptd 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 9F7D88005C for ; Thu, 20 Jun 2019 06:36:40 -0400 (EDT) From: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary="Apple-Mail=_89A4086C-D76E-4530-8882-1B3EC991AB43" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <98C70F11-2E01-4951-AECF-C7DE856841A5@muada.com> Date: Thu, 20 Jun 2019 12:36:37 +0200 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Sidrops] Path validation with RPKI 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: Thu, 20 Jun 2019 10:36:46 -0000 --Apple-Mail=_89A4086C-D76E-4530-8882-1B3EC991AB43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear secure interdomain routing operators, I've been away from the IETF for a while, and I'm new to this mailing = list, so I'm not up to date with what's been happening here. I'm not = going to let that stop me :-) but apologies if I retread worn out = paths. Also, I'm not sure if this work ultimately fits this wg, but I think = this is the right place for an initial discussion. I'm also starting = this discussion on the RIPE routing-wg list. A few weeks ago there was a significant route leak through Safe Host and = China Telecom. This keeps happening. I think we can stop these route = leaks with a relatively modest change to RPKI: by combining the ASes the = origin trusts and the ASes the operator of an RPKI relying party server = trusts, we have a list of all the ASes that may legitimately appear in = the AS path as seen from this particular vantage point. I believe deployment will be relatively easy, as it works for the two = ASes at both ends even if ASes in the middle don't participate. So this means a change to the ROA format, a change to the RPKI-router = protocol, and of course changes to the software involved. Here is the draft: https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-pathrpki/ = There is path filter example code in the appendix to show that this part = is easy. :-) In case you want to try this out but don't want to compile it yourself, = (mostly) the same code is also running here: http://bgpexpert.com/pathrpki/ Probably not too much new information for this group, but some = background: http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.html = Note that this is significantly different from the AS-Cones proposal. = AS-Cones is a way for transit ASes to filter their peers (and maybe = their customers). RPKI path validation is everyone filtering all = prefixes they see, regardless of whether these prefixes come in through = peering or transit. However, there is no reason the two can't be = deployed side by side. I've also read the ASPA draft, and although there are some overlap = between ASPA and RPKI path validation, I'm not entirely clear on the = details but they seem to be very different. Iljitsch= --Apple-Mail=_89A4086C-D76E-4530-8882-1B3EC991AB43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = secure interdomain routing operators,

I've been away from the IETF for a = while, and I'm new to this mailing list, so I'm not up to date with = what's been happening here. I'm not going to let that stop me  :-) =  but apologies if I retread worn out paths.

Also, I'm not sure if this work = ultimately fits this wg, but I think this is the right place for an = initial discussion. I'm also starting this discussion on the RIPE = routing-wg list.

A few weeks = ago there was a significant route leak through Safe Host and China = Telecom. This keeps happening. I think we can stop these route leaks = with a relatively modest change to RPKI: by combining the ASes the = origin trusts and the ASes the operator of an RPKI relying party server = trusts, we have a list of all the ASes that may legitimately appear in = the AS path as seen from this particular vantage point.
I believe deployment will be = relatively easy, as it works for the two ASes at both ends even if ASes = in the middle don't participate.

So this means a change to the ROA = format, a change to the RPKI-router protocol, and of course changes to = the software involved.

Here is the draft:

https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-path= rpki/

There = is path filter example code in the appendix to show that this part is = easy.  :-)

In case you want to try this out but don't want to compile it = yourself, (mostly) the same code is also running here:

http://bgpexpert.com/pathrpki/

Probably not too much new information = for this group, but some background:

http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.= html

Note = that this is significantly different from the AS-Cones proposal. = AS-Cones is a way for transit ASes to filter their peers (and maybe = their customers). RPKI path validation is everyone filtering all = prefixes they see, regardless of whether these prefixes come in through = peering or transit. However, there is no reason the two can't be = deployed side by side.

I've also read the ASPA draft, and although there are some = overlap between ASPA and RPKI path validation, I'm not entirely clear on = the details but they seem to be very different.

Iljitsch
= --Apple-Mail=_89A4086C-D76E-4530-8882-1B3EC991AB43-- From nobody Wed Jun 26 07:19:39 2019 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 68BD412000E; Wed, 26 Jun 2019 07:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6FHjUSnZwu8H; Wed, 26 Jun 2019 07:19:35 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534A512004D; Wed, 26 Jun 2019 07:19:35 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id x18so1730845qkn.13; Wed, 26 Jun 2019 07:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+21APlAOY+mvCzuRLKPCpMNF2fVXJli/n6sT45DO4ZA=; b=TDXGuO2hgyQDjp6WqU/hABmmgJ4qtgae6xF8RsmLQCWjGUzJ8v7bKuH99sapuOBDRL atVI/Stwew6B9X2e5hE/d2xZxm0gtASEQX1myb/3SUCsFthYT7cP+zGnn94V5xd/AWZd nbXhhfAmSJ8eIBhujn+GXrPQ2/pKvwCibevyC5tbBMBwS0/tHOnEEpre4gQFyaNsE8pK TPpJTHrCOTns8Yo58xWcqbE4YHnqP3C1zBddwFqQdJ1pLVCVjiqfuFGdSGKs67UeDQ3f oK4bdK7omGyKZ9+cFC0/a/D437Gcjx8gtFrYA8c66b2/ZIoKtoBIEvm8rVZk5ZF4KYKb zslA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+21APlAOY+mvCzuRLKPCpMNF2fVXJli/n6sT45DO4ZA=; b=Hh1Tx8D6Kqiecl/cJzJEoibbsR/XPodS+q4JrJIU56QHZx+z44xG25HlktpgbwVDhO G7GGBR8Z12CC296iQd2KVWlUbz8eBMs7pBHJj+S6Ok0OnYTOjB7q+Wuz74G+jjP/3k+3 zhGGMGfgawtdOR/Yd+5l59HB25Mu1c6H8yc2RpAsp+nJxWWZHexNbetdapRPynZU2Ngd C9YQ1MfQONy10pA4Hq3cLenMzJtrBzlYeX69usC60fH3++kiAVm/ub62Gkg6S+JAuHiI 7kPmn4Uyf2QV3I+2gJis1b2K1CN1v/g2wqYONHyVLx/MyTjIJGK7k/Qzotl918vQT/tV p/ng== X-Gm-Message-State: APjAAAWeTM3Mgcl6zrOmmcBgsmxRNbNr/WRIIimAQFkFAHujhZFkrg2e UtqDXXqkQheE0KbiXXWOmqg/Gu7EXZ86HvQrDdvOOlEr X-Google-Smtp-Source: APXvYqzf9sdJLjZFc9vap8ozkUpJEgX07nANJMvgDQsI/fA3eUg4b0VTp4yAGBys5GavYWYUfZ0pfUu6oK3OG9wlM9M= X-Received: by 2002:a37:4e0d:: with SMTP id c13mr4038726qkb.116.1561558773898; Wed, 26 Jun 2019 07:19:33 -0700 (PDT) MIME-Version: 1.0 From: Christopher Morrow Date: Wed, 26 Jun 2019 10:19:23 -0400 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] IETF 105 - Montreal - Call for Agenda Items 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: Wed, 26 Jun 2019 14:19:38 -0000 howdy IETF Folks! Today is the day to imagine what your best IETF SIDROPS meeting could consist of!! We have a meeting slot in Montreal, let's utilize it like your lowest priced internet link! Please send Agenda Items forth with! -chris Chair Personage From nobody Wed Jun 26 08:19:50 2019 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 606181201A3 for ; Wed, 26 Jun 2019 08:19:48 -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=PXJknEW/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j2ZCS6AG 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 5SLnpAg0Evw3 for ; Wed, 26 Jun 2019 08:19:45 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD0512006A for ; Wed, 26 Jun 2019 08:19:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id AD7FD53E for ; Wed, 26 Jun 2019 11:19:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 26 Jun 2019 11:19:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muada.com; h= from:content-type:mime-version:subject:message-id:date:to; s= fm3; bh=8V4DgxlfjncehJiKuSbe1gi6lUwdBC4kjOKAKozRZiw=; b=PXJknEW/ 2xXWEJWgzQ/vb9+VUmAya+bk12hUWbKD+DvACHchuNpMsVlY5PqV/OWnOYr/C4Pq sJ05LAF48g6OjbHQ4OCc27BGSyUL1wwyoA8yPPgEZG91Du+d2nUlg5T5BjKz5OrH jaHEhI0bPtYjAbq0h7L4Y0ikgG+YCzCM30isl08uZhUyzr32zAR6pqOsm9IuqKHH CG485QYRZJG1U0Q8lblSmfHPbQCpM4jGeg+Eve8aLGDMbZmiNsKXoY+Ek4ojt7Az b324kc1X24ZGgIQMMrcWWTHs09CrML5PwxKQ9Bk+cQs4HwONHF4h1j7lpFQbeKC1 g8Sq5H3D7bhlVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=8V4DgxlfjncehJiKuSbe1gi6lUwdB C4kjOKAKozRZiw=; b=j2ZCS6AGVnPGHPteDAbl5l1veQcY37cX+qsshR619Q4a8 IxIc1bjnC7E2gmg7RqyGdUFENadrRThNuMg7HGxtSsIOzt+B0DIZMTQx/uIwe6q8 pq2zPAcJB2xMQ5/75pjBeXAA+wJzeZxu4vmPq9h/ZNthmiNZZinuCh/Q24Qi8d6R 289m0urJCnsZjogEspZ+elSlBZUNdkYPpk7ln1bXQxjokwPrf6BdNYrOlL1RABaq K8tX0rXJgzzqea9NEeqqPjWpY/pyJGQoq2gjIrmBmSwF9F06zYiv8oSeDhKnKu/A bQUvZS/EcTIq1+2JJyaSR1jlS0CVJ4TqpuQT/TDXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeigdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmrehhtd dvnecuhfhrohhmpefklhhjihhtshgthhcuvhgrnhcuuegvihhjnhhumhcuoehilhhjihht shgthhesmhhurggurgdrtghomheqnecukfhppeekfedrkeehrdejuddrleehnecurfgrrh grmhepmhgrihhlfhhrohhmpehilhhjihhtshgthhesmhhurggurgdrtghomhenucevlhhu shhtvghrufhiiigvpedt 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 3F06E8005C for ; Wed, 26 Jun 2019 11:19:43 -0400 (EDT) From: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary="Apple-Mail=_B4CC6D92-D118-4A1B-B950-FEB3E2C0E138" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> Date: Wed, 26 Jun 2019 17:19:38 +0200 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Sidrops] On validating AS paths 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: Wed, 26 Jun 2019 15:19:48 -0000 --Apple-Mail=_B4CC6D92-D118-4A1B-B950-FEB3E2C0E138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (I hope the list retains my non-proportional font. Reformat if = necessary.) After an interesting discussion with Job Snijders the other day about = our respective drafts, I think it would be helpful to analyze the issue = of AS path validation further before discussion specific solutions. I'm interested to hear if my assumptions and conclusions are shared. I think we can agree that any AS path that doesn't conform to the = valley-free model. A quick refresher: the valley-free model assumes four = types of relationships between ASes: customer-provider: / provider-customer: \ peer-peer: ^ sibling-sibling: - I've invented the / \ ^ - characters to indicate relationships myself, = the idea being that they'll visually show valleys if a path isn't = valley-free. You can visualize valley-freeness as the customer ASes at the bottom = sending many up the hierarchy, and the money will only flow up, not = down. So if you have a "valley" in the relationships between the ASes in = a path, someone isn't getting paid and the whole thing doesn't work = economically. The model also allows for mutual backup arrangements, where basically = two ASes provide transit to each other (also called a sibling = relationship). How that works financially is a bit murky, but the = interesting thing here is that if nobody implements any policies or = filters, you have a network with only sibling relationships. So with these four relationships and the valley-free restriction we = should be able model any working real-world relationship between two or = more ASes. (We'll ignore the possibility that the relationships between ASes may be = different for different address families and/or prefixes for now.) For a formal definition of the valley-free model, read "On inferring = autonomous system relationships in the internet", Gao, 2001. I'll state it in the form of the following AS path validation procedure. In addition to / \ ^ - we'll also allow ? to indicate an unknown = relationship between two adjacent ASes in the path. And we'll assume the = sibling relationship between an AS and itself (i.e., if there is AS path = prepending). The steps: 1. Trim from the right (origin) side all \ and - relationships 2. Trim from the left side all / and - relationships 3. If the path is now empty or contains just one ^, the path is = valley-free and therefore valid 6. If the path still contains / or \ or contains multiple ^, the path is = invalid Here are a few valid paths: A: //\\=20 B: /^\ C: ^ D: ^\-\ So the steps produce: A B C D //\\ /^\ ^ ^\-\ Step 1 // /^ ^ ^ Step 2 ^ ^ ^ Step 3 valid valid valid valid If we look at RFC 7908, the first four types of route leaks are caused = by the following relationships: 1: \/ 2: ^^ 3: ^/ 4: \^ So the steps produce: Type 1 Type 2 Type 3 Type 4 \/ ^^ ^/ \^ Step 1 \/ ^^ ^/ \^ Step 2 \/ ^^ ^/ \^ Step 3 \/ ^^ ^/ \^ Step 5 invalid invalid invalid invalid Now what if we have unknown relationships in the path? /?^\ could be: //^\ /-^\ /^^\ /\^\ valid valid invalid invalid /?\ could be: //\ /-\ /^\ /\\ valid valid valid valid In other words: if steps 1 and 2 above just leave a ?, then regardless = of what the unknown relationship turns out to be, we know the path will = be valley-free and valid. So we can now extend the validation steps to consider unknown = relationships and see even if we assume a best case scenario, we still = end up with an invalid path: 1. Trim from the right (origin) side all \ and - relationships 2. Trim from the left side all / and - relationships 3. If the path is now empty or contains just one ^ or just one ?, the = path is valley-free and therefore valid 4. Trim from the right (origin) side all \, - and ? relationships 5. Trim from the left side all /, - and ? relationships 6. If the path still contains / or \ or contains multiple ^, the path is = invalid 7. Else the path validity is unknown Now all of the above assumes that the relationship between two ASes is = uncontested. But what if the two ASes claim to have different = relationships? One approach would be to just assume an unknown relationship ?, so the = path will only validate under worst case assumptions. In my opinion, a better approach would be just keep track of claims of a = customer-provider relationship from the customer side (where the sibling = relationship is simply a mutual customer-provider relationship claim). Overclaiming of the relationship by a customer is relatively = unproblematic, because the claimed provider will simply not provide the = service with no ill effect. Overclaiming by the provider, on the other = hand, could be harmful, the combination of the relationship overclaim = and incorrect BGP filters will now create a route leak that our path = validation system will declare to have a valid path. There is probably no reason to publish peer-to-peer relationships, as a = path with ? where there should be ^ will also validate. One interesting issue is route servers, as deployed by internet = exchanges. Typically (universally?) those don't add their AS to the AS = path, breaking the BGP specification in the process. In that case, the = route server is invisible, so validation will have the same result as = with a direct peering relationship. If this behavior is not universal, we should either assume a - = relationship for route servers, or define a new type of relationship = that will be removed from the valley-free validation process. With all of the above out of the way, we'll have to think about which = relationship claims to carry in-band and which out-of-band. --Apple-Mail=_B4CC6D92-D118-4A1B-B950-FEB3E2C0E138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(I hope the list = retains my non-proportional font. Reformat if = necessary.)

After an interesting discussion with Job = Snijders the other day about our respective drafts, I think it would be = helpful to analyze the issue of AS path validation further before = discussion specific solutions.

I'm interested = to hear if my assumptions and conclusions are shared.

I think we can agree that any AS path that doesn't conform to = the valley-free model. A quick refresher: the valley-free model = assumes four types of relationships between ASes:

customer-provider:  /
provider-customer: =  \
peer-peer:         =  ^
sibling-sibling:    -

I've invented the / \ ^ - characters to indicate = relationships myself, the idea being that they'll visually show valleys = if a path isn't valley-free.

You can = visualize valley-freeness as the customer ASes at the bottom sending = many up the hierarchy, and the money will only flow up, not down. So if = you have a "valley" in the relationships between the ASes in a path, = someone isn't getting paid and the whole thing doesn't work = economically.

The model also = allows for mutual backup arrangements, where basically two ASes provide = transit to each other (also called a sibling relationship). How that = works financially is a bit murky, but the interesting thing here is that = if nobody implements any policies or filters, you have a network with = only sibling relationships.

So with these = four relationships and the valley-free restriction we should be able = model any working real-world relationship between two or more = ASes.

(We'll ignore the possibility that the = relationships between ASes may be different for different address = families and/or prefixes for now.)

For a formal = definition of the valley-free model, read "On inferring autonomous = system relationships in the internet", Gao, 2001.

I'll state it in the form of the following AS path validation = procedure.

In addition to / \ ^ - we'll also allow ? to = indicate an unknown relationship between two adjacent ASes in the path. = And we'll assume the sibling relationship between an AS and itself = (i.e., if there is AS path prepending).

The = steps:

1. Trim = from the right (origin) side all \ and - relationships
2. Trim from the left side all / and - = relationships
3. If the path is now empty or = contains just one ^, the path is valley-free and therefore = valid
6. If the path still contains / or \ or contains multiple ^, = the path is invalid

Here are a few valid = paths:

A: //\\ 
B: = /^\
C: ^
D: ^\-\

So the steps = produce:

        =     A       B       C   =     D
        =     //\\    /^\     ^       = ^\-\
Step 1 =      //      /^      ^ =       ^
Step 2       =      =   ^       ^       = ^
Step 3      valid   valid   = valid   valid

If we look = at RFC 7908, the first four types of route leaks are caused by the = following relationships:

1: \/
2: ^^
3: ^/
4: \^

So= the steps produce:

        =     Type 1  Type 2  Type 3  Type = 4
          =   \/      ^^      ^/   =    \^
Step 1   =    \/      ^^     =  ^/      \^
Step 2      \/   =    ^^      ^/     =  \^
Step 3      \/   =    ^^      ^/     =  \^
Step 5      invalid invalid invalid = invalid

Now what if we have unknown relationships in the = path?

/?^\ could be:

//^\    /-^\    /^^\   =  /\^\
valid   valid   invalid invalid

/?\ could be:

//\   =   /-\     /^\     /\\
valid   = valid   valid   valid

In other words: = if steps 1 and 2 above just leave a ?, then regardless of what the = unknown relationship turns out to be, we know the path will be = valley-free and valid.

So we can now extend the = validation steps to consider unknown relationships and see even if we = assume a best case scenario, we still end up with an invalid = path:

1. Trim from the right (origin) side all \ and - = relationships
2. Trim from the left side all / = and - relationships
3. If the = path is now empty or contains just one ^ or just one ?, the path is = valley-free and therefore valid
4. Trim from the right (origin) side all \, - = and ? relationships
5. Trim from the left side all /, - and ? = relationships
6. If the path still contains / = or \ or contains multiple ^, the path is invalid
7. Else the path validity is unknown

Now all of the above assumes that the relationship between = two ASes is uncontested. But what if the two ASes claim to have = different relationships?

One approach = would be to just assume an unknown relationship ?, so the path will only = validate under worst case assumptions.

In my opinion, a = better approach would be just keep track of claims of a = customer-provider relationship from the customer side (where the sibling = relationship is simply a mutual customer-provider relationship = claim).

Overclaiming of the relationship = by a customer is relatively unproblematic, because the claimed provider = will simply not provide the service with no ill effect. Overclaiming by = the provider, on the other hand, could be harmful, the combination of = the relationship overclaim and incorrect BGP filters will now create a = route leak that our path validation system will declare to have a valid = path.

There is probably no reason to = publish peer-to-peer relationships, as a path with ? where there should = be ^ will also validate.

One interesting = issue is route servers, as deployed by internet exchanges. Typically = (universally?) those don't add their AS to the AS path, breaking the BGP = specification in the process. In that case, the route server is = invisible, so validation will have the same result as with a direct = peering relationship.

If this behavior is not = universal, we should either assume a - relationship for route servers, = or define a new type of relationship that will be removed from the = valley-free validation process.

With all of the = above out of the way, we'll have to think about which relationship = claims to carry in-band and which out-of-band.

= --Apple-Mail=_B4CC6D92-D118-4A1B-B950-FEB3E2C0E138-- From nobody Wed Jun 26 09:39:41 2019 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 0613B1203B0 for ; Wed, 26 Jun 2019 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VzWQNyfgiDF1 for ; Wed, 26 Jun 2019 09:39:36 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BF91203B8 for ; Wed, 26 Jun 2019 09:39:30 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id i8so3160213oth.10 for ; Wed, 26 Jun 2019 09:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6xB7pDVtlcGSbbPlZQKa4O6QxM3kP+3W8TzOpnCzRa8=; b=PHxHV0UEy81vBrH4Xp2JAkjwOxYPrwUwoMjKyTCX+bOXq0uhtSRCK2/hiubfcS5QoF /+qRoF+3dBBUwFsJF37UE0ueZ07gSVCrG4aFXiNl3265OLsIGz2q6O6QAk+YOwrDAN2G XDmG/Gq49fa4AP+kaA/P9Ec9LBfB3im6qtBSTTXWyF2vdk/gBwlEwvr6/VQd6SSrPZSS py4/NJzC4S5akRNOaT+/uGO7OnbCs2Z4FqbZeExv2WNxLEajeJmdtXDQwMjobQpdCdC3 oPSh/bT67fDgmmtN2xzaCYHO7vK1MiCINVJ2XmJmDLA/g7N2PEcppO2uAD8efq9/R3Ti ezyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6xB7pDVtlcGSbbPlZQKa4O6QxM3kP+3W8TzOpnCzRa8=; b=tb6JiIvc9iUj1Xs/E3ARCumvkb4sSOspwIviMdmtNTxqeuJqATJPpR5Zz9ZpJ92tbW 0kQT2Psh3rlJlPGPMwUdDyPXq6rVwWz7llTLMWHJ6JJvMAT0lAZVBmz0MicdlHBeZErD spTA/tkiK8fJ0OgwoLKWQqYd+AcgAQXtJIHoeyLsCQXxABNwHjBdhH+89w3qrm/qTN2C vYFa5XsFSjkU1yH0MYlDeBJhuxVtx1waQAbkVrpFI33SUo12i1866A1vHAbEZ6fxdYEO XI34aCg8Vj1n/3TlmVF0cci/J8fL8lAWocbnDvg2GbpP3a0t572UFPPcSwDtBun8WAaw usOg== X-Gm-Message-State: APjAAAX8VHyXMXCw/OT8utL2Y6KtxPjRIBL+Hms7jfwRNZokPQD+SSDO aDbENgKFUxTFIE2g2ip1AyxLKxFV9s8BoJj7ZuFmon5s X-Google-Smtp-Source: APXvYqyjga2uN8VloUA0FVEsPf5/ii4MwTFh141TBiAuLjxW4ZaHDoBzrD5qF0xh9R3UT3UgOyR1m115NwnCkpufgv8= X-Received: by 2002:a9d:6a81:: with SMTP id l1mr3938786otq.113.1561567169699; Wed, 26 Jun 2019 09:39:29 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> In-Reply-To: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> From: Alexander Azimov Date: Wed, 26 Jun 2019 19:39:17 +0300 Message-ID: To: Iljitsch van Beijnum Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000716349058c3cb061" Archived-At: Subject: Re: [Sidrops] On validating AS paths 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: Wed, 26 Jun 2019 16:39:40 -0000 --000000000000716349058c3cb061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Iljitsch, I assume that after talking with Job Snijders you are aware of ASPA drafts. They cover the detection of anomalies (invalid ASPATHs) that are received from customers and peers + specify RPKI object exactly for customer-to-provider pairs. It has a different specification for unknown relations - (a1, a2) is unknown if only there are no ASPA records for a1. And of course, a path //^\ (in your notation) received from customer or peer is invalid. But I assume that you also had this in mind. What I find curious in your proposal is the goal to extend the detection of invalid paths for prefixes that are received from providers. I was also considering this option, but it will not work with c2p database only. The problem occurs with siblings. Take a look at the next example: a1 *p2p* a2 *c2c *a3 *p2c *a4 (p2p for peering, c2c for sibling, a4 is checking ASPATH) If records for a1 exists (so we know that a2 isn't in the set of providers of a1), (a2, a3) records exist, but (a3, a2) doesn't, the outcome of verification procedure at a4 will be invalid. Maybe it can be fixed by adding a sibling flag to the c2p record, but at the moment I'm not sure about security consequences. =D1=81=D1=80, 26 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 18:19, Iljitsch va= n Beijnum : > (I hope the list retains my non-proportional font. Reformat if necessary.= ) > > After an interesting discussion with Job Snijders the other day about our > respective drafts, I think it would be helpful to analyze the issue of AS > path validation further before discussion specific solutions. > > I'm interested to hear if my assumptions and conclusions are shared. > > I think we can agree that any AS path that doesn't conform to the > valley-free model. A quick refresher: the valley-free model assumes four > types of relationships between ASes: > > customer-provider: / > provider-customer: \ > peer-peer: ^ > sibling-sibling: - > > I've invented the / \ ^ - characters to indicate relationships myself, th= e > idea being that they'll visually show valleys if a path isn't valley-free= . > > You can visualize valley-freeness as the customer ASes at the bottom > sending many up the hierarchy, and the money will only flow up, not down. > So if you have a "valley" in the relationships between the ASes in a path= , > someone isn't getting paid and the whole thing doesn't work economically. > > The model also allows for mutual backup arrangements, where basically two > ASes provide transit to each other (also called a sibling relationship). > How that works financially is a bit murky, but the interesting thing here > is that if nobody implements any policies or filters, you have a network > with only sibling relationships. > > So with these four relationships and the valley-free restriction we shoul= d > be able model any working real-world relationship between two or more ASe= s. > > (We'll ignore the possibility that the relationships between ASes may be > different for different address families and/or prefixes for now.) > > For a formal definition of the valley-free model, read "On inferring > autonomous system relationships in the internet", Gao, 2001. > > I'll state it in the form of the following AS path validation procedure. > > In addition to / \ ^ - we'll also allow ? to indicate an unknown > relationship between two adjacent ASes in the path. And we'll assume the > sibling relationship between an AS and itself (i.e., if there is AS path > prepending). > > The steps: > > 1. Trim from the right (origin) side all \ and - relationships > 2. Trim from the left side all / and - relationships > 3. If the path is now empty or contains just one ^, the path is > valley-free and therefore valid > 6. If the path still contains / or \ or contains multiple ^, the path is > invalid > > Here are a few valid paths: > > A: //\\ > B: /^\ > C: ^ > D: ^\-\ > > So the steps produce: > > A B C D > //\\ /^\ ^ ^\-\ > Step 1 // /^ ^ ^ > Step 2 ^ ^ ^ > Step 3 valid valid valid valid > > If we look at RFC 7908, the first four types of route leaks are caused by > the following relationships: > > 1: \/ > 2: ^^ > 3: ^/ > 4: \^ > > So the steps produce: > > Type 1 Type 2 Type 3 Type 4 > \/ ^^ ^/ \^ > Step 1 \/ ^^ ^/ \^ > Step 2 \/ ^^ ^/ \^ > Step 3 \/ ^^ ^/ \^ > Step 5 invalid invalid invalid invalid > > Now what if we have unknown relationships in the path? > > /?^\ could be: > > //^\ /-^\ /^^\ /\^\ > valid valid invalid invalid > > /?\ could be: > > //\ /-\ /^\ /\\ > valid valid valid valid > > In other words: if steps 1 and 2 above just leave a ?, then regardless of > what the unknown relationship turns out to be, we know the path will be > valley-free and valid. > > So we can now extend the validation steps to consider unknown > relationships and see even if we assume a best case scenario, we still en= d > up with an invalid path: > > 1. Trim from the right (origin) side all \ and - relationships > 2. Trim from the left side all / and - relationships > 3. If the path is now empty or contains just one ^ or just one ?, the pat= h > is valley-free and therefore valid > 4. Trim from the right (origin) side all \, - and ? relationships > 5. Trim from the left side all /, - and ? relationships > 6. If the path still contains / or \ or contains multiple ^, the path is > invalid > 7. Else the path validity is unknown > > Now all of the above assumes that the relationship between two ASes is > uncontested. But what if the two ASes claim to have different relationshi= ps? > > One approach would be to just assume an unknown relationship ?, so the > path will only validate under worst case assumptions. > > In my opinion, a better approach would be just keep track of claims of a > customer-provider relationship from the customer side (where the sibling > relationship is simply a mutual customer-provider relationship claim). > > Overclaiming of the relationship by a customer is relatively > unproblematic, because the claimed provider will simply not provide the > service with no ill effect. Overclaiming by the provider, on the other > hand, could be harmful, the combination of the relationship overclaim and > incorrect BGP filters will now create a route leak that our path validati= on > system will declare to have a valid path. > > There is probably no reason to publish peer-to-peer relationships, as a > path with ? where there should be ^ will also validate. > > One interesting issue is route servers, as deployed by internet exchanges= . > Typically (universally?) those don't add their AS to the AS path, breakin= g > the BGP specification in the process. In that case, the route server is > invisible, so validation will have the same result as with a direct peeri= ng > relationship. > > If this behavior is not universal, we should either assume a - > relationship for route servers, or define a new type of relationship that > will be removed from the valley-free validation process. > > With all of the above out of the way, we'll have to think about which > relationship claims to carry in-band and which out-of-band. > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --000000000000716349058c3cb061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Iljitsch,

I assume that a= fter talking with Job Snijders you are aware of ASPA drafts.
They= cover the detection of anomalies (invalid ASPATHs) that are received from = customers and peers + specify RPKI object exactly for customer-to-provider = pairs.

It has a different specification for unknow= n relations - (a1, a2) is unknown if only there are no ASPA records for a1.=
And of course, a path //^\ (in your notation) received from cust= omer or peer is invalid. But I assume that you also had this in mind.

What I find curious in your proposal is the goal to exte= nd the detection of invalid paths for prefixes that are received from provi= ders.
I was also considering this option, but it will not work with c2p = database only. The problem occurs with siblings.

Take a look a= t the next example:
a1 p2p a2 c2c a3 p2c a4 (p2p for peering, c2c for sibling, a4 is checking ASPATH)
If = records for a1 exists (so we know that a2 isn't in the set of providers= of a1), (a2, a3) records exist, but (a3, a2) doesn't, the outcome of v= erification procedure at a4 will be invalid.

Maybe= it can be fixed by adding a sibling flag to the c2p record, but at the mom= ent I'm not sure about security consequences.


=D1=81=D1=80, 26 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 18:19, Iljitsc= h van Beijnum <iljitsch=3D= 40muada.com@dmarc.ietf.org>:
(I hope the list retains my non-proportional font= . Reformat if necessary.)

After an interesting d= iscussion with Job Snijders the other day about our respective drafts, I th= ink it would be helpful to analyze the issue of AS path validation further = before discussion specific solutions.

I'm int= erested to hear if my assumptions and conclusions are shared.
<= div>
I think we can agree that any AS path that doesn't c= onform to the valley-free model.=C2=A0A quick refresher: the valley-free mo= del assumes four types of relationships between ASes:

customer-provider: =C2=A0/
provider-customer: =C2=A0\
peer-peer: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
sibling-sibling: =C2=A0 =C2=A0-

I've invented the / \ ^ - characters to = indicate relationships myself, the idea being that they'll visually sho= w valleys if a path isn't valley-free.

= You can visualize valley-freeness as the customer ASes at the bottom sendin= g many up the hierarchy, and the money will only flow up, not down. So if y= ou have a "valley" in the relationships between the ASes in a pat= h, someone isn't getting paid and the whole thing doesn't work econ= omically.

The model also allows for mutual = backup arrangements, where basically two ASes provide transit to each other= (also called a sibling relationship). How that works financially is a bit = murky, but the interesting thing here is that if nobody implements any poli= cies or filters, you have a network with only sibling relationships.=

So with these four relationships and the valley-f= ree restriction we should be able model any working real-world relationship= between two or more ASes.

(We'll ignor= e the possibility that the relationships between ASes may be different for = different address families and/or prefixes for now.)

For a formal definition of the valley-free model, read "On i= nferring autonomous system relationships in the internet", Gao, 2001.<= /font>

I'll state it in the form of the follow= ing AS path validation procedure.

In additi= on to / \ ^ - we'll also allow ? to indicate an unknown relationship be= tween two adjacent ASes in the path. And we'll assume the sibling relat= ionship between an AS and itself (i.e., if there is AS path prepending).

The steps:

1. Trim from the right (origin) side all \ and - relationsh= ips
2.= Trim from the left side all / and - relationships
3. If the path is now empty or= contains just one ^, the path is valley-free and therefore valid
6. If the path still contains / o= r \ or contains multiple ^, the path is invalid

Here are a few valid paths:

A: //\\=C2= =A0
B: /^\
<= div>C: ^
D: ^\-\

So the steps pro= duce:

<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 A =C2=A0 =C2=A0 =C2=A0 B =C2=A0 =C2=A0 =C2=A0 C =C2=A0 =C2=A0 =C2=A0= D
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0//\\ = =C2=A0 =C2=A0/^\ =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 ^\-\
Step 1 =C2=A0 =C2= =A0=C2=A0=C2=A0<= /span>// =C2=A0 =C2=A0 =C2=A0/^ =C2=A0 = =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0 ^
Step=C2=A02 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 ^
S= tep=C2=A0= 3 =C2=A0 =C2=A0 =C2=A0valid =C2=A0 valid = =C2=A0 valid =C2=A0 valid

If we look at RFC 7908, the first four types of route leaks are caused by = the following relationships:

1: \/
2: ^^
3: ^/
4: \^

So the steps produce:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Type 1 =C2=A0Type 2 =C2=A0Ty= pe 3 =C2=A0Type 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0\/ =C2=A0 =C2=A0 =C2=A0^^ =C2=A0= =C2=A0 =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^
Step 1 =C2=A0 =C2=A0=C2=A0=C2=A0\/ =C2=A0 =C2=A0 =C2=A0^^ =C2=A0 =C2=A0 = =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^
Step=C2=A02 =C2=A0 =C2=A0 =C2=A0\/ =C2=A0 =C2=A0 =C2=A0^^ =C2=A0 =C2=A0 =C2=A0^/ =C2=A0 =C2= =A0 =C2=A0\^
Step= =C2=A03 =C2=A0 = =C2=A0 =C2=A0\/ = =C2=A0 =C2=A0 =C2=A0^^ =C2=A0 =C2=A0 =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^=
Step=C2=A05=C2=A0 =C2=A0 =C2=A0 invali= d invalid invalid invalid

Now what if we have unknown relationships in the path?

/?^\ cou= ld be:

//= ^\ =C2=A0 =C2=A0/-^\ =C2=A0 =C2=A0/^^\ =C2=A0 =C2=A0/\^\
<= font size=3D"2" face=3D"Courier">valid =C2=A0 valid =C2=A0 invalid invalid<= /font>

/?\ could be:

//\ =C2=A0 =C2=A0 /-\ =C2=A0 =C2=A0 /^\ =C2=A0 =C2=A0 /\\
=
valid =C2=A0 valid =C2=A0 valid =C2= =A0 valid

In other words: if steps 1 and 2 = above just leave a ?, then regardless of what the unknown relationship turn= s out to be, we know the path will be valley-free and valid.

So we can now extend the validation steps to consider unk= nown relationships and see even if we assume a best case scenario, we still= end up with an invalid path:

1. Trim from the right (origin) side all \ and - relationships
2. Trim = from the left side all / and - relationships
3. If the path is now empty or con= tains just one ^ or just one ?, the path is valley-free and therefore valid=
4.=C2= =A0Trim from the= right (origin) side all \, - and ? relationships
5.=C2=A0Trim from the left side all /, - and ? = relationships
6. If the path still contains / or \ or contains multiple ^, the pa= th is invalid
7. Else the path validity is unknown

Now all of the above assumes that the relationship between two ASes= is uncontested. But what if the two ASes claim to have different relations= hips?

<= div>One approach would be to just assume = an unknown relationship ?, so the path will only validate under worst case = assumptions.

=
In my opinion, a better approa= ch would be just keep track of claims of a customer-provider relationship f= rom the customer side (where the sibling relationship is simply a mutual cu= stomer-provider relationship claim).

Overcl= aiming of the relationship by a customer is relatively unproblematic, becau= se the claimed provider will simply not provide the service with no ill eff= ect. Overclaiming by the provider, on the other hand, could be harmful, the= combination of the relationship overclaim and incorrect BGP filters will n= ow create a route leak that our path validation system will declare to have= a valid path.

There is probably no reason = to publish peer-to-peer relationships, as a path with ? where there should = be ^ will also validate.

One interesting is= sue is route servers, as deployed by internet exchanges. Typically (univers= ally?) those don't add their AS to the AS path, breaking the BGP specif= ication in the process. In that case, the route server is invisible, so val= idation will have the same result as with a direct peering relationship.

If this behavior is not universal, we should = either assume a - relationship for route servers, or define a new type of r= elationship that will be removed from the valley-free validation process.

With all of the above out of the way, we'= ;ll have to think about which relationship claims to carry in-band and whic= h out-of-band.

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov
--000000000000716349058c3cb061-- From nobody Wed Jun 26 09:52:12 2019 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 3C5A512003E for ; Wed, 26 Jun 2019 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 S5JggGP7fIYz for ; Wed, 26 Jun 2019 09:52:07 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A690C120100 for ; Wed, 26 Jun 2019 09:52:07 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id r21so3229408otq.6 for ; Wed, 26 Jun 2019 09:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HAtUELjnxQ9V/LjJRdTPRWdChhNiGjjn32bHMSAfeqc=; b=Nnqh/Pv2XhK7kudWN+j8m7yWBukj6Tes2KFG3t14/SPH+yt3Pw46tA219YElQTRTG0 pUI5HE+hP44i+Ed8s66nbEWUtIbcK3+vDJdZFDxwWg4smNtENeiSUPLXJSSJ3Fe6W2bZ x2ZH9PGvGtwXSqV3StyI1prBneLQbPPm4Pk1KyY9qrIjCRNl5pU4RT+Xgz1Un46k+5es uRvwsZTVruoW2w7fS6scRfAr9zvOZVN9A7ukVANPNX5tmFScBvjlLRL3maJd1AuFAEwq 57OGHtU/8+YFEfi/9tNTllkW7AFOqKBCobw10qRjZUwOyB45woViHjEG8b2lV2vd0c9i F03Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HAtUELjnxQ9V/LjJRdTPRWdChhNiGjjn32bHMSAfeqc=; b=h2UA0m1Pf0qMd/Ag9L1iTyyF1wukcWmp3MeqJrNGRfwdv5Q1QnAh8BifbmMrf/O8Oc mnJMH9EjTlDPqq8YXfLMJR3bs9iLkyWcFDc0aSBpXGWGpj2AP1jViJ2LxCBehWSPxEiS 0kWTNAFsKtpbaPoVGedOVIg7mjM3D8U6/Abpim7OMFCGSrYlgr86GdmEXJqlIrJbKZ67 yXmGVwKvazDPreIqD3x3ifzSP/cCo9563GgSahFzP+aFSTSo0lqdnoldHSUJHQcmzyb3 z9O+gOZIFCmnSeHBtRWLmhBRYF1BHxgic6rpevNKaPiPenSvZRayWpddxdxDso77ymtV TWUQ== X-Gm-Message-State: APjAAAVfNbZUOIOCFLHtJRT50hoYspKGM5FG39oSqxeGha+F6DaWQF/o Mal1spqm83WX5Ulv37dMnF0DRcnhMBHAZAW7hgg= X-Google-Smtp-Source: APXvYqzE9Qz8l2TU4a56rdAPzGzx6MNcZbz7xUt6p1ImM/4ePeCLF8APPGpf0TeWdDr4wzwBDGfRkoEjB2zN80QPZRk= X-Received: by 2002:a9d:76d3:: with SMTP id p19mr4113516otl.18.1561567926913; Wed, 26 Jun 2019 09:52:06 -0700 (PDT) MIME-Version: 1.0 References: <9D1926FB-30B0-4A28-8AAF-32527BCC2F9F@muada.com> In-Reply-To: From: Alexander Azimov Date: Wed, 26 Jun 2019 19:51:55 +0300 Message-ID: To: Iljitsch van Beijnum Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000939174058c3cdd5c" Archived-At: Subject: Re: [Sidrops] On validating AS paths 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: Wed, 26 Jun 2019 16:52:11 -0000 --000000000000939174058c3cdd5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And to follow up my previous email, if we have a network with malicious intent that would hijack/disaggregate prefixes + create a 'virtual peering link' between it and victim ASN, its customers will not able to detect it anyway since it will look like a valid path: '-\'. And we can't properly specify peerings because of transparent IXes. =D1=81=D1=80, 26 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 19:39, Alexander A= zimov : > Hi Iljitsch, > > I assume that after talking with Job Snijders you are aware of ASPA draft= s. > They cover the detection of anomalies (invalid ASPATHs) that are received > from customers and peers + specify RPKI object exactly for > customer-to-provider pairs. > > It has a different specification for unknown relations - (a1, a2) is > unknown if only there are no ASPA records for a1. > And of course, a path //^\ (in your notation) received from customer or > peer is invalid. But I assume that you also had this in mind. > > What I find curious in your proposal is the goal to extend the detection > of invalid paths for prefixes that are received from providers. > I was also considering this option, but it will not work with c2p databas= e > only. The problem occurs with siblings. > > Take a look at the next example: > a1 *p2p* a2 *c2c *a3 *p2c *a4 (p2p for peering, c2c for sibling, a4 is > checking ASPATH) > If records for a1 exists (so we know that a2 isn't in the set of provider= s > of a1), (a2, a3) records exist, but (a3, a2) doesn't, the outcome of > verification procedure at a4 will be invalid. > > Maybe it can be fixed by adding a sibling flag to the c2p record, but at > the moment I'm not sure about security consequences. > > > =D1=81=D1=80, 26 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 18:19, Iljitsch = van Beijnum 40muada.com@dmarc.ietf.org>: > >> (I hope the list retains my non-proportional font. Reformat if necessary= .) >> >> After an interesting discussion with Job Snijders the other day about ou= r >> respective drafts, I think it would be helpful to analyze the issue of A= S >> path validation further before discussion specific solutions. >> >> I'm interested to hear if my assumptions and conclusions are shared. >> >> I think we can agree that any AS path that doesn't conform to the >> valley-free model. A quick refresher: the valley-free model assumes four >> types of relationships between ASes: >> >> customer-provider: / >> provider-customer: \ >> peer-peer: ^ >> sibling-sibling: - >> >> I've invented the / \ ^ - characters to indicate relationships myself, >> the idea being that they'll visually show valleys if a path isn't >> valley-free. >> >> You can visualize valley-freeness as the customer ASes at the bottom >> sending many up the hierarchy, and the money will only flow up, not down= . >> So if you have a "valley" in the relationships between the ASes in a pat= h, >> someone isn't getting paid and the whole thing doesn't work economically= . >> >> The model also allows for mutual backup arrangements, where basically tw= o >> ASes provide transit to each other (also called a sibling relationship). >> How that works financially is a bit murky, but the interesting thing her= e >> is that if nobody implements any policies or filters, you have a network >> with only sibling relationships. >> >> So with these four relationships and the valley-free restriction we >> should be able model any working real-world relationship between two or >> more ASes. >> >> (We'll ignore the possibility that the relationships between ASes may be >> different for different address families and/or prefixes for now.) >> >> For a formal definition of the valley-free model, read "On inferring >> autonomous system relationships in the internet", Gao, 2001. >> >> I'll state it in the form of the following AS path validation procedure. >> >> In addition to / \ ^ - we'll also allow ? to indicate an unknown >> relationship between two adjacent ASes in the path. And we'll assume the >> sibling relationship between an AS and itself (i.e., if there is AS path >> prepending). >> >> The steps: >> >> 1. Trim from the right (origin) side all \ and - relationships >> 2. Trim from the left side all / and - relationships >> 3. If the path is now empty or contains just one ^, the path is >> valley-free and therefore valid >> 6. If the path still contains / or \ or contains multiple ^, the path is >> invalid >> >> Here are a few valid paths: >> >> A: //\\ >> B: /^\ >> C: ^ >> D: ^\-\ >> >> So the steps produce: >> >> A B C D >> //\\ /^\ ^ ^\-\ >> Step 1 // /^ ^ ^ >> Step 2 ^ ^ ^ >> Step 3 valid valid valid valid >> >> If we look at RFC 7908, the first four types of route leaks are caused b= y >> the following relationships: >> >> 1: \/ >> 2: ^^ >> 3: ^/ >> 4: \^ >> >> So the steps produce: >> >> Type 1 Type 2 Type 3 Type 4 >> \/ ^^ ^/ \^ >> Step 1 \/ ^^ ^/ \^ >> Step 2 \/ ^^ ^/ \^ >> Step 3 \/ ^^ ^/ \^ >> Step 5 invalid invalid invalid invalid >> >> Now what if we have unknown relationships in the path? >> >> /?^\ could be: >> >> //^\ /-^\ /^^\ /\^\ >> valid valid invalid invalid >> >> /?\ could be: >> >> //\ /-\ /^\ /\\ >> valid valid valid valid >> >> In other words: if steps 1 and 2 above just leave a ?, then regardless o= f >> what the unknown relationship turns out to be, we know the path will be >> valley-free and valid. >> >> So we can now extend the validation steps to consider unknown >> relationships and see even if we assume a best case scenario, we still e= nd >> up with an invalid path: >> >> 1. Trim from the right (origin) side all \ and - relationships >> 2. Trim from the left side all / and - relationships >> 3. If the path is now empty or contains just one ^ or just one ?, the >> path is valley-free and therefore valid >> 4. Trim from the right (origin) side all \, - and ? relationships >> 5. Trim from the left side all /, - and ? relationships >> 6. If the path still contains / or \ or contains multiple ^, the path is >> invalid >> 7. Else the path validity is unknown >> >> Now all of the above assumes that the relationship between two ASes is >> uncontested. But what if the two ASes claim to have different relationsh= ips? >> >> One approach would be to just assume an unknown relationship ?, so the >> path will only validate under worst case assumptions. >> >> In my opinion, a better approach would be just keep track of claims of a >> customer-provider relationship from the customer side (where the sibling >> relationship is simply a mutual customer-provider relationship claim). >> >> Overclaiming of the relationship by a customer is relatively >> unproblematic, because the claimed provider will simply not provide the >> service with no ill effect. Overclaiming by the provider, on the other >> hand, could be harmful, the combination of the relationship overclaim an= d >> incorrect BGP filters will now create a route leak that our path validat= ion >> system will declare to have a valid path. >> >> There is probably no reason to publish peer-to-peer relationships, as a >> path with ? where there should be ^ will also validate. >> >> One interesting issue is route servers, as deployed by internet >> exchanges. Typically (universally?) those don't add their AS to the AS >> path, breaking the BGP specification in the process. In that case, the >> route server is invisible, so validation will have the same result as wi= th >> a direct peering relationship. >> >> If this behavior is not universal, we should either assume a - >> relationship for route servers, or define a new type of relationship tha= t >> will be removed from the valley-free validation process. >> >> With all of the above out of the way, we'll have to think about which >> relationship claims to carry in-band and which out-of-band. >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >> > > > -- > Best regards, > Alexander Azimov > --=20 Best regards, Alexander Azimov --000000000000939174058c3cdd5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And to follow up my previous email, if we have a netw= ork with malicious intent that would hijack/disaggregate prefixes + create = a 'virtual peering link' between it and victim ASN, its customers w= ill not able to detect it anyway since it will look like a valid path: '= ;-\'.

And we can't properly specify peerin= gs because of transparent IXes.

=D1=81=D1=80, 26 =D0=B8=D1=8E=D0= =BD. 2019 =D0=B3. =D0=B2 19:39, Alexander Azimov <a.e.azimov@gmail.com>:
Hi Iljitsch,

I assume that after talking with Job Snijders you are awa= re of ASPA drafts.
They cover the detection of anomalies (invalid= ASPATHs) that are received from customers and peers + specify RPKI object = exactly for customer-to-provider pairs.

It has a d= ifferent specification for unknown relations - (a1, a2) is unknown if only = there are no ASPA records for a1.
And of course, a path //^\ (in = your notation) received from customer or peer is invalid. But I assume that= you also had this in mind.

What I find curious in = your proposal is the goal to extend the detection of invalid paths for pref= ixes that are received from providers.
I was also considering this optio= n, but it will not work with c2p database only. The problem occurs with sib= lings.

Take a look at the next example:
a1 p2= p a2 c2c a3 p2c a4 (p2p for peering, c2c for sibling, a4 = is checking ASPATH)
If records for a1 exists (so we know that a2 = isn't in the set of providers of a1), (a2, a3) records exist, but (a3, = a2) doesn't, the outcome of verification procedure at a4 will be invali= d.

Maybe it can be fixed by adding a sibling flag = to the c2p record, but at the moment I'm not sure about security conseq= uences.


<= div dir=3D"ltr" class=3D"gmail_attr">=D1=81=D1=80, 26 =D0=B8=D1=8E=D0=BD. 2= 019 =D0=B3. =D0=B2 18:19, Iljitsch van Beijnum <iljitsch=3D40muada.com@dmarc.ietf.o= rg>:
(I hope the list retains my non-pro= portional font. Reformat if necessary.)

After = an interesting discussion with Job Snijders the other day about our respect= ive drafts, I think it would be helpful to analyze the issue of AS path val= idation further before discussion specific solutions.

I'm interested to hear if my assumptions and conclusions are share= d.

I think we can agree that any AS path th= at doesn't conform to the valley-free model.=C2=A0A quick refresher: th= e valley-free model assumes four types of relationships between ASes:

customer-provider: =C2=A0/
provider-customer: =C2=A0\
<= font size=3D"2" face=3D"Courier">peer-peer: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0^
sibling-sibling: = =C2=A0 =C2=A0-

I've invented the / \ ^ = - characters to indicate relationships myself, the idea being that they'= ;ll visually show valleys if a path isn't valley-free.

You can visualize valley-freeness as the customer ASes at t= he bottom sending many up the hierarchy, and the money will only flow up, n= ot down. So if you have a "valley" in the relationships between t= he ASes in a path, someone isn't getting paid and the whole thing doesn= 't work economically.

The model also al= lows for mutual backup arrangements, where basically two ASes provide trans= it to each other (also called a sibling relationship). How that works finan= cially is a bit murky, but the interesting thing here is that if nobody imp= lements any policies or filters, you have a network with only sibling relat= ionships.

So with these four relationships = and the valley-free restriction we should be able model any working real-wo= rld relationship between two or more ASes.

= (We'll ignore the possibility that the relationships between ASes may b= e different for different address families and/or prefixes for now.)=

For a formal definition of the valley-free model,= read "On inferring autonomous system relationships in the internet&qu= ot;, Gao, 2001.

I'll state it in the fo= rm of the following AS path validation procedure.

In addition to / \ ^ - we'll also allow ? to indicate an unknown= relationship between two adjacent ASes in the path. And we'll assume t= he sibling relationship between an AS and itself (i.e., if there is AS path= prepending).

The steps:
<= font size=3D"2" face=3D"Courier">
1. Trim from the right (origin) side all \ = and - relationships
2. Trim from the left side all / and - relationships
3. If the path= is now empty or contains just one ^, the path is valley-free and therefore= valid
6. If the path st= ill contains / or \ or contains multiple ^, the path is invalid

Here are a few valid paths:

A: //\\=C2=A0
B: /= ^\
C: ^
D: ^\-\

= So the steps produce:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 A =C2=A0 =C2=A0 =C2=A0 B =C2=A0 =C2=A0 =C2=A0 C =C2=A0= =C2=A0 =C2=A0 D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0//\\ =C2=A0 =C2=A0/^\ =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 ^\-\
Step= 1 =C2=A0 =C2=A0=C2=A0=C2=A0// =C2=A0 =C2=A0 =C2= =A0/^ =C2=A0 =C2=A0 =C2=A0^ =C2=A0 =C2=A0 =C2=A0 ^
<= div>Step=C2=A02 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 = =C2=A0 =C2=A0 ^
Step=C2=A03 =C2=A0 =C2=A0 =C2=A0va= lid =C2=A0 valid =C2=A0 valid =C2=A0 valid

If we look at RFC 7908, the first four types of route lea= ks are caused by the following relationships:

1: \/
2: ^^
3: ^/
4: \^

<= div>
So the steps produce:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Type 1 = =C2=A0Type 2 =C2=A0Type 3 =C2=A0Type 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= /span>=C2=A0\/ =C2=A0 = =C2=A0 =C2=A0^^ =C2=A0 =C2=A0 =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^
<= div>Step 1 =C2=A0 =C2= =A0=C2=A0=C2=A0<= /span>\/ =C2=A0 =C2=A0 = =C2=A0^^ =C2=A0 =C2=A0 =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^
Step=C2=A02 =C2=A0 =C2=A0 =C2=A0\/ =C2=A0 =C2=A0 =C2=A0^^ =C2=A0 = =C2=A0 =C2=A0^/ =C2=A0 =C2=A0 =C2=A0\^
Step=C2=A03 =C2=A0 =C2=A0 =C2=A0\/ =C2=A0 =C2=A0 =C2=A0^^ =C2=A0 =C2=A0 =C2=A0^/ =C2= =A0 =C2=A0 =C2=A0\^
Step=C2=A05= =C2=A0 =C2=A0 =C2=A0 invalid invalid invalid invalid

Now what if we have unknown r= elationships in the path?

/?^\ could be:

//^\ =C2=A0 =C2=A0/-^\ =C2=A0 =C2=A0/^^\ =C2=A0 = =C2=A0/\^\
valid =C2=A0 = valid =C2=A0 invalid invalid

/?\ could be:<= /font>

//\ =C2=A0 =C2=A0 /-\ =C2=A0 =C2=A0 /^\ =C2= =A0 =C2=A0 /\\
valid =C2= =A0 valid =C2=A0 valid =C2=A0 valid

In oth= er words: if steps 1 and 2 above just leave a ?, then regardless of what th= e unknown relationship turns out to be, we know the path will be valley-fre= e and valid.

=
So we can now extend the valid= ation steps to consider unknown relationships and see even if we assume a b= est case scenario, we still end up with an invalid path:
<= font size=3D"2" face=3D"Courier">
1. Trim from the right (origin) side a= ll \ and - relationships
2. Trim from the left side all / and - relationships
3. If the= path is now empty or contains just one ^ or just one ?, the path is valley= -free and therefore valid
4.=C2=A0Trim from the right (origin) side all \, - and ? relationships<= /span>
5.=C2= =A0Trim from the= left side all /, - and ? relationships
6. If the path still contains / or \ or c= ontains multiple ^, the path is invalid
7. Else the path validity is unkno= wn

Now all of the above assumes that the re= lationship between two ASes is uncontested. But what if the two ASes claim = to have different relationships?

One approa= ch would be to just assume an unknown relationship ?, so the path will only= validate under worst case assumptions.

In = my opinion, a better approach would be just keep track of claims of a custo= mer-provider relationship from the customer side (where the sibling relatio= nship is simply a mutual customer-provider relationship claim).

Overclaiming of the relationship by a customer is rela= tively unproblematic, because the claimed provider will simply not provide = the service with no ill effect. Overclaiming by the provider, on the other = hand, could be harmful, the combination of the relationship overclaim and i= ncorrect BGP filters will now create a route leak that our path validation = system will declare to have a valid path.

T= here is probably no reason to publish peer-to-peer relationships, as a path= with ? where there should be ^ will also validate.

One interesting issue is route servers, as deployed by internet ex= changes. Typically (universally?) those don't add their AS to the AS pa= th, breaking the BGP specification in the process. In that case, the route = server is invisible, so validation will have the same result as with a dire= ct peering relationship.

If this behavior i= s not universal, we should either assume a - relationship for route servers= , or define a new type of relationship that will be removed from the valley= -free validation process.

With all of the a= bove out of the way, we'll have to think about which relationship claim= s to carry in-band and which out-of-band.

__________________________________= _____________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,Alexander Azimov


--
Best regards,
Alexander Azimov
--000000000000939174058c3cdd5c-- From nobody Wed Jun 26 15:44:24 2019 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 BBDD612012E for ; Wed, 26 Jun 2019 15:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com 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 CNoO1vREZ8qe for ; Wed, 26 Jun 2019 15:44:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740059.outbound.protection.outlook.com [40.107.74.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DA8120099 for ; Wed, 26 Jun 2019 15:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WMM/tHqwevxlCxzPiFuIvesZ74eBoTDdUYqmndfT0mI=; b=T6+ARCr2Z838qhLhmPumDTdFL/lAZ8tP8yzfcuwf8PCmv+w3Mn8+SqK3iM2fZfaKmkw1lDbied3zAQNrGgOC/+m76ykH4VqrVDyDb+JKyCc4zoVcUnJlMWQtJf17chSm05PBOz7RIYWbF8jO5ojIw11ROqxoJAZCBJ28/ZV7MPM= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.58.82) by BYAPR18MB2759.namprd18.prod.outlook.com (20.179.56.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Wed, 26 Jun 2019 22:44:15 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::707c:f1f3:45b1:7c84]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::707c:f1f3:45b1:7c84%6]) with mapi id 15.20.2008.018; Wed, 26 Jun 2019 22:44:15 +0000 From: Keyur Patel To: "sidrops@ietf.org" CC: Keyur Patel , Christopher Morrow Thread-Topic: SIDROPS WG Agenda Items Thread-Index: AQHVLHCunX38WElA1kKUJKCSEOKFIw== Date: Wed, 26 Jun 2019 22:44:15 +0000 Message-ID: <70767D02-6D5A-45EC-AC4C-3B8DD3594161@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [31.221.58.249] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23edf690-6242-49f8-c570-08d6fa87d137 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(7168020)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:BYAPR18MB2759; x-ms-traffictypediagnostic: BYAPR18MB2759: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(346002)(366004)(39830400003)(189003)(199004)(6506007)(316002)(186003)(66476007)(102836004)(68736007)(2906002)(256004)(66446008)(66556008)(66946007)(64756008)(91956017)(76116006)(26005)(4744005)(55236004)(73956011)(2351001)(33656002)(6916009)(66066001)(6116002)(3846002)(99286004)(36756003)(6486002)(54906003)(53936002)(4326008)(25786009)(508600001)(7736002)(86362001)(3480700005)(2501003)(6306002)(476003)(2616005)(54896002)(6512007)(6436002)(486006)(5660300002)(5640700003)(81166006)(81156014)(1730700003)(8676002)(8936002)(71200400001)(71190400001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2759; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lQNLMneVJtVg5PZhrc0m58XorUGbtg8r/xjD9XUuDSINlggKQmX/TY01/Pnm2LeRNDN91bWERh6H2p+1M4huL/a+IsEaCVNY9uELzIKuUDhjkVePyq59FFFpxBOGoZ+K+3SM2NgXqVBeTWgL1PIOcskRNzNzWr9vhuEuLJO3i5s0vmsajoHXhgBAP+qvylID8hBy0C1e7ZRvNuThnqCJTm3HDTHTfuBMcYtT/fnZgtXKGogyG9OElQv/+cJ+qV8jpWymMATke6utC2s1PINH8QMQjZLEP1VsTtSlvkjgk2IuzHQCgWJvtf8DM3aAd8nTkTsh2YHkg9wEi6DS9rUlyNql6F5gcU4aUTn084AXwsFCbzgfLXH7sYIuH1kZkVIA8TArhiHlXb22Gp8A45wl73ShVgdU5yEGtJllkcOmnJw= Content-Type: multipart/alternative; boundary="_000_70767D026D5A45ECAC4C3B8DD3594161arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23edf690-6242-49f8-c570-08d6fa87d137 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 22:44:15.5826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: keyur@arrcus.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2759 Archived-At: Subject: [Sidrops] SIDROPS WG Agenda Items 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: Wed, 26 Jun 2019 22:44:23 -0000 --_000_70767D026D5A45ECAC4C3B8DD3594161arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtMTA1IG9uIFR1ZXNkYXksIEp1 bHkgMjV0aCBmcm9tIDM6MjAgcG0g4oCTIDQ6NTAgcG0uICBQbGVhc2UgZm9yd2FyZCBhbnkgU0lE Uk9QUyBhZ2VuZGEgaXRlbXMgeW91IG1heSBoYXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFs c28gbWFrZSBzdXJlIHRoYXQgeW91ciBzbGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJz IGJ5IEZyaWRheSBtb3JuaW5nICg3LzE5LzIwMTkpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgdGhl IGRlYWRsaW5lIG1heSBub3QgYmUgYXZhaWxhYmxlIGZvciB1c2UgZHVyaW5nIHRoZSBtZWV0aW5n Lg0KDQpSZWdhcmRzLA0KQ2hyaXMgYW5kIEtleXVyDQoNCg0K --_000_70767D026D5A45ECAC4C3B8DD3594161arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U0lEUk9QUyB3aWxsIG1lZXQgYXQgSUVU Ri0xMDUgb24gVHVlc2RheSwgSnVseSAyNTxzdXA+dGg8L3N1cD4gZnJvbSAzOjIwIHBtIOKAkyA0 OjUwIHBtLg0KPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlBsZWFzZSBmb3J3YXJkIGFueSZuYnNwO1NJRFJPUFMmbmJzcDthZ2VuZGEgaXRlbXMgeW91IG1h eSBoYXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28gbWFrZSBzdXJlIHRoYXQgeW91ciBz bGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5IEZyaWRheSBtb3JuaW5nICg3LzE5 LzIwMTkpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgdGhlIGRlYWRsaW5lIG1heSBub3QgYmUNCiBh dmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5DaHJpcyBhbmQmbmJzcDtLZXl1ciZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_70767D026D5A45ECAC4C3B8DD3594161arrcuscom_-- From nobody Thu Jun 27 15:53:15 2019 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 21678120287 for ; Thu, 27 Jun 2019 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 CRuiWtBiFKfA for ; Thu, 27 Jun 2019 15:53:11 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840104.outbound.protection.outlook.com [40.107.84.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F88012026F for ; Thu, 27 Jun 2019 15:53:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=eY+QEoZcAj0dQPMgcLJWb/SvyDb9Uui2K2/HVjKVk9IlK8ML/xGRHyecEcPXE/ehEIq4VAZPltH4v4M92BlQZ4SXi9HF9+TaiDUCkJ+3QB++NvSutmKxJq6IqQkPkghW6XREWOm4J5c75///osYXn3JhMQ2CkFKc4DTXP46L7cA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBKJQJxdnKWilyJMCDNKsi6vMl3vYDHAmoKbcgnsMIM=; b=VkxYs8H5ripPD4r+dUMd5IfWerGdTBG4k2GorFQFSPiikvsKtKkTHa2xs+zTO1CCC2za6iVVvy3HpDixKIKvhqGN1grubYYCsO0vvvxOE3XUQOnh3CUfbPt9XCAnQIPrEelA8CmG8vg8CnsJ7qFDY+PgKQlnxC3PxFMDjLFB/7I= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBKJQJxdnKWilyJMCDNKsi6vMl3vYDHAmoKbcgnsMIM=; b=MMxccOGNvmgKISlVM/tPXEhaBB0AaD0Sjch8yvyE5MybbUH9DTlK4jvuG8XCWfhLWvQh1nBeov4/mWJBAvre2d5jyZHcK4ioZIkOOU85PKTupa94ob16Y5m6YR4cwBxxmt1Eh1DTkqMMjhCvZnPhL7yTwYscRfGWSyN6se4Nt5U= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB2794.namprd09.prod.outlook.com (20.176.98.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 22:53:09 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::146b:72d7:952f:2424]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::146b:72d7:952f:2424%7]) with mapi id 15.20.2032.018; Thu, 27 Jun 2019 22:53:09 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Iljitsch van Beijnum CC: "sidrops@ietf.org" Thread-Topic: Re: [Sidrops] Path validation with RPKI Thread-Index: AdUtOXg7ebscyRtcRr+cBM+WeTCZhA== Date: Thu, 27 Jun 2019 22:53:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cb950f7-b633-4474-0073-08d6fb5239eb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB2794; x-ms-traffictypediagnostic: DM6PR09MB2794: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(136003)(366004)(346002)(189003)(199004)(76116006)(14454004)(5660300002)(7736002)(26005)(316002)(4326008)(73956011)(66556008)(66446008)(66476007)(102836004)(66946007)(74316002)(966005)(6506007)(52536014)(305945005)(8676002)(71190400001)(6246003)(86362001)(64756008)(186003)(66066001)(478600001)(53936002)(6436002)(486006)(9686003)(68736007)(55016002)(229853002)(7696005)(81166006)(81156014)(8936002)(25786009)(2906002)(3846002)(6116002)(14444005)(6916009)(256004)(33656002)(71200400001)(6306002)(99286004)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB2794; H:DM6PR09MB3019.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oob9rJzLoDhSTXPlHlw51nrJ9ovhZwX3XklP+b8e8x7J+rttpXefQpobkqtBImDnsKXdNZOLvis4T50gAxNwrmyJNbB0JI79BeCZW1UWR1YZqErr9GmoVVx0WsbdekBzEonOqpuG1tRJkHLzx+HBADpgD7x4DHs943Zx+P8Mr9SpvuRaCaeqeptPGKQKTG0tOpWCHgLVVZrT82Zlpvy6PvAqUQFylcrbeyLfrqejsowMdFWukHfGzB/1IWyHr8c6s+zlsnEX1K5QJqwV3CP8z8alCEEnFeesSlcKYeEzw3J5ZS5adFDWycDhhnfr/v//7Dwe/j8CHdA7Wk61EEVq+UakSTo4yCdXF1tKjCL8wKbhuNLcB9pXMVH9hcV7Ad31qVbbJOI/ZqNJESLpHGooAu153Np2EM2tTc+YPfz72VA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 6cb950f7-b633-4474-0073-08d6fb5239eb X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 22:53:09.6016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ksriram@nist.gov X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB2794 Archived-At: Subject: Re: [Sidrops] Path validation with RPKI 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: Thu, 27 Jun 2019 22:53:14 -0000 Iljitsch, Just in case you are not aware, there is another effort in the GROW WG=20 for route leaks solution: https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation= -00 =20 =20 You mention, "We implement this by extending RPKI ROAs so that=20 in addition to the origin AS, they also list all possible transit ASes." The idea of "extended ROA" was considered during BGPsec=20 design discussions. See Section 6.5.2, list item #3 in RFC 8374: https://tools.ietf.org/html/rfc8374=20 The extended ROA was proposed to include the transit AS of the origin AS. The purpose was to make it easier for resource-constrained stub ASes=20 to participate in BGPsec without incurring the upgrade costs. In your design, you seem to include in the ROA a sequence AS1, AS2, AS3, ..= . where AS1 is the origin AS, AS2 is transit of AS2, AS3 is transit of AS3, etc. Is= that right?=20 Prefix owner may know the origin AS (AS1) and one level higher transit AS (= AS2). But they would typically not know the transit ASes further up in the hierar= chy. Does that pose a challenge for your design?=20 Sriram From nobody Fri Jun 28 14:36:12 2019 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 5DBA91202BD; Fri, 28 Jun 2019 14:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jem5vs8uLtVk; Fri, 28 Jun 2019 14:36:03 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B6A12028B; Fri, 28 Jun 2019 14:36:02 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id k8so12514830edr.11; Fri, 28 Jun 2019 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hKNuaERLnWsMAYFokY+GA/W+UdB3AJ4x/xfVlkTlU80=; b=M8zdrV0KSivPzS9vYVJLj+/7ZO1IcYsBOW3xSLghzFq1k2/Jf74UqQ1hMnNfkD/ZQe 0xvoUK+1fHv/zmq7KK5MM+7MSoI/sxLgWfeADTS3vDVpCVZAGv3lWhIN4Ez0nyhOJ3XL pGxZWbxidHCNaUR3ZnEzJ7ZuwpOu+361f8KdDZLgPjUg4C08TJTmwDJ7Hvfe1f6B5ti+ NMMSSM3um6tGqLVJzYuyecNxMBixGyNV7qir7iCDX8yxLIGbDgFl9CgUcS/PUqDZycQv Ozv/tB7kELdeOckH0aU+eNyANvE9S7MKYH6+14hcUe0V3jciqdO79B6OfZxjfoRJJ+TC vt9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hKNuaERLnWsMAYFokY+GA/W+UdB3AJ4x/xfVlkTlU80=; b=m3SJnipKp8ckb4R4MHlBG65HYBEaxU5sfpQjeLSgThBHSlJH7ZboM2YYwJgmlEqNuA GDtQOvrfMnAC3qRyprILLLx+Yht/jcJeXQpnQ+LrO3uL6/EK9y67WuWVdNyZrd5ADah9 F8ffh892G4N7NOaPOoII7fezcQbYcLP5pV7fUKHcSiFxuwj8SPtgg0iNmD2jDRkN33qv 2wa278BOkntKGpCrkJ6gIo5uJEvfOzwHEQbqVJ35m/jdmZEwzlruXe8oPiD6UgLtcv7S ufIcEU21cG3UN04v3OL+UJTNNSR/oz2wiv58QgvnsAlRCei7i4KWyaub6bGTZ6VWK9R3 AzeQ== X-Gm-Message-State: APjAAAXjMRjEhmKdJTQsK2uMgoOo11PI462bcdrYlw93msKL+XOedcc5 Yhp8OmmUq3VrvfSB1uF6KxFK6wyHfJK9xgZ2glA= X-Google-Smtp-Source: APXvYqxnodRxn2M+XZQxv6tLriNGiBAEHo6fISM3zC6wNdvLPXXn+MVgdInH1aBv3osECfRffvSP+Owto0sS9qcnrWQ= X-Received: by 2002:a17:906:401a:: with SMTP id v26mr11020624ejj.62.1561757761484; Fri, 28 Jun 2019 14:36:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Jun 2019 16:36:00 -0500 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 28 Jun 2019 16:36:00 -0500 Message-ID: To: Alberto Leiva , Russ Housley Cc: IETF SIDR , SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000099399f058c6910d5" Archived-At: Subject: Re: [Sidrops] [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates 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: Fri, 28 Jun 2019 21:36:06 -0000 --00000000000099399f058c6910d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Adding sidrops.] Hi! I was just looking at this report=E2=80=A6 https://www.rfc-editor.org/errata_search.php?rfc=3D7935 The report says: "All existing RPKI readers and writers that I've seen, as well as the global RPKI repository certificates themselves, currently use rsaEncryption as the public key algorithm of subjectPublicKeyInfo. Therefore, this change should also reflect existing practice.=E2=80=9D It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the res= ulting text is: o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID MUST be used in the algorithm field, as specified in Section 2.1.1 of [RFC5480]. The value for the associated parameters MUST be secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. The erratum was filed in May of this year, and rfc8608 was published in June. Does the report apply to rfc8608, or does the information there reflect existing practice? Thanks! Alvaro. On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com) wrote: I see. Is this erratum-worthy? On Thu, May 23, 2019 at 11:23 AM Russ Housley wrote: > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrote: > > > > Hello > > > > Another question. > > > > RFC 7935 states the following: > > > > 3.1. Public Key Format > > > > (...) > > > > algorithm (which is an AlgorithmIdentifier type): > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > > used in the algorithm field, as specified in Section 5 of > > [RFC4055]. The value for the associated parameters from that > > clause MUST also be used for the parameters field. > > > > I've never seen a certificate that declares sha256WithRSAEncryption ({ > > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). > > > > (Certificates always define the signature algorithm as > > sha256WithRSAEncryption, but that's a different field.) > > > > Is everyone doing it wrong, or am I missing something? > > > > I'm aware that this is likely a triviality--rsaEncryption and > > sha256WithRSAEncryption probably mean the same in this context. > > There's also a thread in this list in which people seem to have > > experienced headaches over this topic. But the thread is talking about > > CMS signed objects (which I believe is different from certificates), > > and happened before 7935 was released, so it feels like the RFC should > > mandate something consistent with reality by now. > > > > Thanks for any pointers. > > You are right. > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > In the signature, the algorithm identifier should be sha256WithRSAEncryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v1.5 with SHA-256 as the hash algorithm. > > Russ > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --00000000000099399f058c6910d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
[Adding sidrops.]

Hi!

I was just looking at this report=E2=80=A6

= The report says: "All existing RPKI readers and writers that I've = seen, as well as the global RPKI repository certificates themselves, curren= tly use rsaEncryption as the public key algorithm of subjectPublicKeyInfo. = Therefore, this change should also reflect existing practice.=E2=80=9D

It turns out that rfc82= 08, and then rfc8608 Updated rfc7935=E2=80=A6the resulting text is:<= /div>

= =C2=A0 =C2=A0o =C2=A0algorithm (an AlgorithmIdentifier type): The id-ecPubl= icKey OID
= =C2=A0 =C2=A0 =C2=A0 MUST be used in the algorithm field, as specified in S= ection 2.1.1
=C2=A0 =C2=A0 =C2=A0 of [RFC5480].=C2=A0 The value for the associated para= meters MUST be
=C2=A0 =C2=A0 =C2=A0 secp256r1, as specified in Section 2.1.1.1 of [RFC5= 480].


The erratum was file= d in May of this year, and rfc8608 was published in June.

Does the report apply to rfc8608, = or does the information there reflect existing practice?

Thanks!

Alvaro.

On May 23, = 2019 at 2:17:17 PM, Alberto Leiva (yda= hhrk@gmail.com) wrote:

I see. Is this = erratum-worthy?

On Thu, May 23, 2019 at 11:23 AM Russ Housley <housley@vigilsec.com> wrote:
>
>
>
> > On May 22, 2019, at 6:18 PM, Alberto Leiva <ydahhrk@gmail.com> wrote:
> >
> > Hello
> >
> > Another question.
> >
> > RFC 7935 states the following:
> >
> > 3.1. Public Key Format
> >
> > (...)
> >
> > algorithm (which is an AlgorithmIdentifier type):
> > The object identifier for RSA PKCS #1 v1.5 with SHA-256 = MUST be
> > used in the algorithm field, as specified in Section 5 o= f
> > [RFC4055]. The value for the associated parameters from= that
> > clause MUST also be used for the parameters field.
> >
> > I've never seen a certificate that declares sha256WithRSA= Encryption ({
> > pkcs-1 11 }) as its public key algorithm. Every certificate I= 've come
> > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }).
> >
> > (Certificates always define the signature algorithm as
> > sha256WithRSAEncryption, but that's a different field.)
> >
> > Is everyone doing it wrong, or am I missing something?
> >
> > I'm aware that this is likely a triviality--rsaEncryption= and
> > sha256WithRSAEncryption probably mean the same in this contex= t.
> > There's also a thread in this list in which people seem t= o have
> > experienced headaches over this topic. But the thread is talk= ing about
> > CMS signed objects (which I believe is different from certifi= cates),
> > and happened before 7935 was released, so it feels like the R= FC should
> > mandate something consistent with reality by now.
> >
> > Thanks for any pointers.
>
> You are right.
>
> In the subjectPublicKeyInfo, the algorithm identifier should be rs= aEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the publi= c key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP.
>
> In the signature, the algorithm identifier should be sha256WithRSA= Encryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS= #1 v1.5 with SHA-256 as the hash algorithm.
>
> Russ
>
>

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf= .org/mailman/listinfo/sidr
=
--00000000000099399f058c6910d5-- From nobody Fri Jun 28 15:30:58 2019 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 A8A61120105; Fri, 28 Jun 2019 15:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CiuwIdRbmLPy; Fri, 28 Jun 2019 15:20:35 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7050D120157; Fri, 28 Jun 2019 15:20:35 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id u19so7203265ior.9; Fri, 28 Jun 2019 15:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=crJBqNPJ12mgrtPMtCOPwgMApx8vjpD0U3Juhv9YBo8=; b=FAZZoQoNORsohQT+P0UEGOE4zIJ2vMRyUukzBnm7OqevJcdYoItXds8Q/JHjIAsskQ KNGgECikoPLHEOZ5gxbs6EPZV7vD88BTtUQPej9bC2MrzylWVoDzY9gnyyag2+Y6fyqh Dx6SpsqXWqaR9aCEj9RRxc6TkWCLawAt1PSl5SIadQHd1S9NkbU8WvG6aIYf0gMbOBew q7K8UdyJBxq90Is7ZpYKs6lsDeyqGMOxs8g3gfuWr7nv5SR6qYacu6ldaBzE7mGCD9qp C1S8SFHVp6uusVyfV2ljFuZpXa/W3/QgEOcBt84FsujWwyPrF/IjlniwEdICRHR9TfWx ch4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=crJBqNPJ12mgrtPMtCOPwgMApx8vjpD0U3Juhv9YBo8=; b=mJGw7IP0cSY0qd4ZxsDEh0lpobQieVwwHcwFfGD+YHYeRbYGGjqjEIuGOCI5lT3P9i 7+zrb759DFLiK1hygKBRpHR9OqUwGDgbrb1sBaBwRIyjtjyCYTdlJv6GiSppYVuYMT4j CtIzW74JtAeAErTMNp7L6dC8Xke9z9LlT49vkecGN+YivrNoDFScWR5hel+4BaxC2IVY IYEyutTr5/smX3YJaQvuKhiVdVbONsRxK6nu2jrnVvsbbdUkrPJPgfZ/0+ZIMOxSZ5E4 1lkmIq7GQ07BJ0cHi3au8iaUcgs9KHk9SF6hFIaIz2e0/JLKEo2YPMBDKMnVcnXL+4JM TUsw== X-Gm-Message-State: APjAAAXWNYUw57LGuiYQFwTaz+/qWMD+dDAOflbznSCm1397J7hcPr1q KykkSVWga/rTwHJVACa0KMb0PZlLdV9InQezygM= X-Google-Smtp-Source: APXvYqzUyeB+Btp0g2MgecE7sGsx3Lv2Hq8+XJjEbgvXJ9XE4MMUgk6XvyMrTJGGkISRQO3ErCypYLTrob0eTcWxpTg= X-Received: by 2002:a02:600c:: with SMTP id i12mr13727734jac.108.1561760434452; Fri, 28 Jun 2019 15:20:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Fri, 28 Jun 2019 17:20:23 -0500 Message-ID: To: Alvaro Retana Cc: Russ Housley , IETF SIDR , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 28 Jun 2019 15:30:57 -0700 Subject: Re: [Sidrops] [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates 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: Fri, 28 Jun 2019 22:20:38 -0000 I think those particular sections of RFCs 7935 and 8608 are talking about different documents: 3. Asymmetric Key Pair Formats The key formats used to compute signatures on CA certificates, BGPsec Router Certificates, and CRLs are as specified in Section 3 of [RFC7935]. This section addresses key formats found in the BGPsec Router Certificate requests and in BGPsec Router Certificates. (https://tools.ietf.org/html/rfc8608#section-3) On Fri, Jun 28, 2019 at 4:36 PM Alvaro Retana wrot= e: > > [Adding sidrops.] > > Hi! > > I was just looking at this report=E2=80=A6 > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 > > The report says: "All existing RPKI readers and writers that I've seen, a= s well as the global RPKI repository certificates themselves, currently use= rsaEncryption as the public key algorithm of subjectPublicKeyInfo. Therefo= re, this change should also reflect existing practice.=E2=80=9D > > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the r= esulting text is: > > o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID > MUST be used in the algorithm field, as specified in Section 2.1.1 > of [RFC5480]. The value for the associated parameters MUST be > secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. > > > The erratum was filed in May of this year, and rfc8608 was published in J= une. > > Does the report apply to rfc8608, or does the information there reflect e= xisting practice? > > Thanks! > > Alvaro. > > On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com) wrote: > > I see. Is this erratum-worthy? > > On Thu, May 23, 2019 at 11:23 AM Russ Housley wrot= e: > > > > > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrote: > > > > > > Hello > > > > > > Another question. > > > > > > RFC 7935 states the following: > > > > > > 3.1. Public Key Format > > > > > > (...) > > > > > > algorithm (which is an AlgorithmIdentifier type): > > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > > > used in the algorithm field, as specified in Section 5 of > > > [RFC4055]. The value for the associated parameters from that > > > clause MUST also be used for the parameters field. > > > > > > I've never seen a certificate that declares sha256WithRSAEncryption (= { > > > pkcs-1 11 }) as its public key algorithm. Every certificate I've come > > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). > > > > > > (Certificates always define the signature algorithm as > > > sha256WithRSAEncryption, but that's a different field.) > > > > > > Is everyone doing it wrong, or am I missing something? > > > > > > I'm aware that this is likely a triviality--rsaEncryption and > > > sha256WithRSAEncryption probably mean the same in this context. > > > There's also a thread in this list in which people seem to have > > > experienced headaches over this topic. But the thread is talking abou= t > > > CMS signed objects (which I believe is different from certificates), > > > and happened before 7935 was released, so it feels like the RFC shoul= d > > > mandate something consistent with reality by now. > > > > > > Thanks for any pointers. > > > > You are right. > > > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEncr= yption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public key = to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > > > In the signature, the algorithm identifier should be sha256WithRSAEncry= ption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v1.= 5 with SHA-256 as the hash algorithm. > > > > Russ > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Jun 28 15:31:04 2019 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 7AAC612018E; Fri, 28 Jun 2019 15:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8dqydjp0j0Th; Fri, 28 Jun 2019 15:26:09 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182951201AA; Fri, 28 Jun 2019 15:26:07 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id r185so15758929iod.6; Fri, 28 Jun 2019 15:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eFKPD6y3LBJr3qCD6JtFzlSElggS27EJkH4tgivwHVc=; b=AwwktxWNg3gpZmCmA63PP6aDQlnYU3Ou1oggHJju+zT73VqOIr3Dhu0Z2WvnFUsMYt dzHspALgzfoQuhAvEoG379SaATkkLN7FcX2YhWfYhzgeEKygpRccIWdI1ZbQRsEzmPbF az3wJ3uvrwRdVqeimecZACxliU4M3rSC+VN64fwLyZ91IsQDByo/1O4XTdFTRGcdeUli RoZaZ8Xpeh3Iv40ti5YnqLWe4jxM0gZMdGSgdCVR4K0KlJy7epI0ZDkP+iTl/ZPzsu+o iKx4OJyo2+UwCzrpHvfiW7ZWyIOuLw5+64wx7O3V81e/TDc4b+qSgxs5bVytLglkb1X4 lkwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eFKPD6y3LBJr3qCD6JtFzlSElggS27EJkH4tgivwHVc=; b=Qn0NCKXv4OpQDpq9s0mzUIYRDjsYIpvFiPv6wJ6+JMCGCxX1QIEYQwO7NmhQpKCjBV qI9kthjYgpFmJ6cYIcbUohUjbdij43BuLZbI4g8ix7p9PVU2+RHxd5R5ccOj77rz4m2N hWoNPHpd0oi040HZ3dMyP73iS0IqZe2NOoirDKN1K9R10Oda1sUkmq4G8JPP42go/4YX 3AC3TyGFJJs1TlmfmyWud8YKIB34hT25WnAQK488F5nrRagBsGkRVC1U8tLBvLfY8hkQ zn4OuCAJyPPbFFkqtYwGrfrApsjRH9up/0dSQO8WHigcUOLnpouRvQJe2TRMuGmv88PI 3tpA== X-Gm-Message-State: APjAAAUpPgPKvAsaA00Xe9MehC3m8W7ZaoFKy9Px/CrOIZevScIkNmAI aBQ8n9LtJhuTJM428t6FIjNthyVgwI45Gx04Mmg= X-Google-Smtp-Source: APXvYqwayh+N8lgN925jsT4YKj8LyDcsaeezjUhQw5cZo8Wu9IsUXuzoiQsMEy3AFTfeWcd+f+XlMpYR0G/mTeVDKC0= X-Received: by 2002:a02:ad17:: with SMTP id s23mr14595474jan.137.1561760766355; Fri, 28 Jun 2019 15:26:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alberto Leiva Date: Fri, 28 Jun 2019 17:25:55 -0500 Message-ID: To: Alvaro Retana Cc: Russ Housley , IETF SIDR , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 28 Jun 2019 15:30:57 -0700 Subject: Re: [Sidrops] [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates 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: Fri, 28 Jun 2019 22:26:12 -0000 Oh, never mind. Both sections include "BGPsec Router Certificates." *scraches head* I don't know what's happening. On Fri, Jun 28, 2019 at 5:20 PM Alberto Leiva wrote: > > I think those particular sections of RFCs 7935 and 8608 are talking > about different documents: > > 3. Asymmetric Key Pair Formats > The key formats used to compute signatures on CA certificates, BGPsec > Router Certificates, and CRLs are as specified in Section 3 of > [RFC7935]. This section addresses key formats found in the BGPsec > Router Certificate requests and in BGPsec Router Certificates. > (https://tools.ietf.org/html/rfc8608#section-3) > > On Fri, Jun 28, 2019 at 4:36 PM Alvaro Retana wr= ote: > > > > [Adding sidrops.] > > > > Hi! > > > > I was just looking at this report=E2=80=A6 > > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 > > > > The report says: "All existing RPKI readers and writers that I've seen,= as well as the global RPKI repository certificates themselves, currently u= se rsaEncryption as the public key algorithm of subjectPublicKeyInfo. There= fore, this change should also reflect existing practice.=E2=80=9D > > > > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the= resulting text is: > > > > o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID > > MUST be used in the algorithm field, as specified in Section 2.1.= 1 > > of [RFC5480]. The value for the associated parameters MUST be > > secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. > > > > > > The erratum was filed in May of this year, and rfc8608 was published in= June. > > > > Does the report apply to rfc8608, or does the information there reflect= existing practice? > > > > Thanks! > > > > Alvaro. > > > > On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com) wrote: > > > > I see. Is this erratum-worthy? > > > > On Thu, May 23, 2019 at 11:23 AM Russ Housley wr= ote: > > > > > > > > > > > > > On May 22, 2019, at 6:18 PM, Alberto Leiva wrot= e: > > > > > > > > Hello > > > > > > > > Another question. > > > > > > > > RFC 7935 states the following: > > > > > > > > 3.1. Public Key Format > > > > > > > > (...) > > > > > > > > algorithm (which is an AlgorithmIdentifier type): > > > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be > > > > used in the algorithm field, as specified in Section 5 of > > > > [RFC4055]. The value for the associated parameters from that > > > > clause MUST also be used for the parameters field. > > > > > > > > I've never seen a certificate that declares sha256WithRSAEncryption= ({ > > > > pkcs-1 11 }) as its public key algorithm. Every certificate I've co= me > > > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). > > > > > > > > (Certificates always define the signature algorithm as > > > > sha256WithRSAEncryption, but that's a different field.) > > > > > > > > Is everyone doing it wrong, or am I missing something? > > > > > > > > I'm aware that this is likely a triviality--rsaEncryption and > > > > sha256WithRSAEncryption probably mean the same in this context. > > > > There's also a thread in this list in which people seem to have > > > > experienced headaches over this topic. But the thread is talking ab= out > > > > CMS signed objects (which I believe is different from certificates)= , > > > > and happened before 7935 was released, so it feels like the RFC sho= uld > > > > mandate something consistent with reality by now. > > > > > > > > Thanks for any pointers. > > > > > > You are right. > > > > > > In the subjectPublicKeyInfo, the algorithm identifier should be rsaEn= cryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the public ke= y to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP. > > > > > > In the signature, the algorithm identifier should be sha256WithRSAEnc= ryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This identifies PKCS#1 v= 1.5 with SHA-256 as the hash algorithm. > > > > > > Russ > > > > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Jun 28 16:00:06 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EFA120977; Fri, 28 Jun 2019 15:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267341.11015.7872238411186793369.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:53 -0700 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 105 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:58:00 -0000 Dear Keyur Patel, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:30 requested) Tuesday, 23 July 2019, Afternoon Session II 1520-1650 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Keyur Patel Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 62 Conflicts to Avoid: First Priority: idr grow lsvr rtgwg lsr mpls pim spring 6man People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 29 00:03:43 2019 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 4EF9E12096D for ; Sat, 29 Jun 2019 00:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SUBJ_BRKN_WORDNUMS=0.01] 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 0uVafx4Xoxby for ; Sat, 29 Jun 2019 00:03:40 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C771200E6 for ; Sat, 29 Jun 2019 00:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 81512300AF9 for ; Sat, 29 Jun 2019 02:44:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sO7YYoYoDKNx for ; Sat, 29 Jun 2019 02:44:18 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 199783009FF; Sat, 29 Jun 2019 02:44:18 -0400 (EDT) From: Russ Housley Message-Id: <5C033DD8-EE26-4413-875C-426FFC7E8A4C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 29 Jun 2019 03:03:34 -0400 In-Reply-To: Cc: Alberto Leiva , SIDR Operations WG , IETF SIDR To: Alvaro Retana References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sidrops] [sidr] rsaEncryption vs sha256WithRSAEncryption in RPKI certificates 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: Sat, 29 Jun 2019 07:03:42 -0000 --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro: I think that RFC 8208 is talking about the keys used to sign BGPsec, = where elliptic curve is used because the size a huge consideration. Russ > On Jun 28, 2019, at 5:36 PM, Alvaro Retana = wrote: >=20 > [Adding sidrops.] >=20 > Hi! >=20 > I was just looking at this report=E2=80=A6 > https://www.rfc-editor.org/errata_search.php?rfc=3D7935 = =20 >=20 > The report says: "All existing RPKI readers and writers that I've = seen, as well as the global RPKI repository certificates themselves, = currently use rsaEncryption as the public key algorithm of = subjectPublicKeyInfo. Therefore, this change should also reflect = existing practice.=E2=80=9D >=20 > It turns out that rfc8208, and then rfc8608 Updated rfc7935=E2=80=A6the = resulting text is: >=20 > o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID > MUST be used in the algorithm field, as specified in Section = 2.1.1 > of [RFC5480]. The value for the associated parameters MUST be > secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. >=20 >=20 > The erratum was filed in May of this year, and rfc8608 was published = in June. >=20 > Does the report apply to rfc8608, or does the information there = reflect existing practice? >=20 > Thanks! >=20 > Alvaro. >=20 > On May 23, 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com = ) wrote: >=20 >> I see. Is this erratum-worthy?=20 >>=20 >> On Thu, May 23, 2019 at 11:23 AM Russ Housley > wrote:=20 >> >=20 >> >=20 >> >=20 >> > > On May 22, 2019, at 6:18 PM, Alberto Leiva > wrote:=20 >> > >=20 >> > > Hello=20 >> > >=20 >> > > Another question.=20 >> > >=20 >> > > RFC 7935 states the following:=20 >> > >=20 >> > > 3.1. Public Key Format=20 >> > >=20 >> > > (...)=20 >> > >=20 >> > > algorithm (which is an AlgorithmIdentifier type):=20 >> > > The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be=20= >> > > used in the algorithm field, as specified in Section 5 of=20 >> > > [RFC4055]. The value for the associated parameters from that=20 >> > > clause MUST also be used for the parameters field.=20 >> > >=20 >> > > I've never seen a certificate that declares = sha256WithRSAEncryption ({=20 >> > > pkcs-1 11 }) as its public key algorithm. Every certificate I've = come=20 >> > > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }).=20 >> > >=20 >> > > (Certificates always define the signature algorithm as=20 >> > > sha256WithRSAEncryption, but that's a different field.)=20 >> > >=20 >> > > Is everyone doing it wrong, or am I missing something?=20 >> > >=20 >> > > I'm aware that this is likely a triviality--rsaEncryption and=20 >> > > sha256WithRSAEncryption probably mean the same in this context.=20= >> > > There's also a thread in this list in which people seem to have=20= >> > > experienced headaches over this topic. But the thread is talking = about=20 >> > > CMS signed objects (which I believe is different from = certificates),=20 >> > > and happened before 7935 was released, so it feels like the RFC = should=20 >> > > mandate something consistent with reality by now.=20 >> > >=20 >> > > Thanks for any pointers.=20 >> >=20 >> > You are right.=20 >> >=20 >> > In the subjectPublicKeyInfo, the algorithm identifier should be = rsaEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This allow the = public key to be used with PKCS#1 v1.5, RSASSA-PSS, and RSAES-OAEP.=20 >> >=20 >> > In the signature, the algorithm identifier should be = sha256WithRSAEncryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This = identifies PKCS#1 v1.5 with SHA-256 as the hash algorithm.=20 >> >=20 >> > Russ=20 >> >=20 >> >=20 >>=20 >> _______________________________________________=20 >> sidr mailing list=20 >> sidr@ietf.org =20 >> https://www.ietf..org/mailman/listinfo/sidr = =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alvaro:

I = think that RFC 8208 is talking about the keys used to sign BGPsec, where = elliptic curve is used because the size a huge consideration.

Russ


On Jun 28, 2019, at 5:36 PM, Alvaro Retana = <aretana.ietf@gmail.com> wrote:

[Adding= sidrops.]

Hi!

I was just looking at this report=E2=80=A6
https://www.rfc-editor.org/errata_search.php?rfc=3D7935&nbs= p;

The report says: "All existing RPKI readers and writers that = I've seen, as well as the global RPKI repository certificates = themselves, currently use rsaEncryption as the public key algorithm of = subjectPublicKeyInfo. Therefore, this change should also reflect = existing practice.=E2=80=9D

It turns out that rfc8208, and then rfc8608 Updated = rfc7935=E2=80=A6the resulting text is:

   o =  algorithm (an AlgorithmIdentifier type): The id-ecPublicKey = OID
      MUST be used in the = algorithm field, as specified in Section 2.1.1
      of [RFC5480].  The value for the = associated parameters MUST be
      = secp256r1, as specified in Section 2.1.1.1 of = [RFC5480].


The erratum was filed in May of this year, = and rfc8608 was published in June.

Does the report apply to rfc8608, or does = the information there reflect existing practice?

Thanks!

Alvaro.

On May 23, = 2019 at 2:17:17 PM, Alberto Leiva (ydahhrk@gmail.com) wrote:

I see. Is this erratum-worthy? 

On Thu, May 23, 2019 at 11:23 AM Russ Housley <housley@vigilsec.com> wrote: 
> 
> 
> 
> > On = May 22, 2019, at 6:18 PM, Alberto Leiva <ydahhrk@gmail.com> = wrote: 
> > > > Hello 
> = > 
>= > Another question. 
> = > 
>= > RFC 7935 states the following: 
> = > 
>= > 3.1. Public Key Format 
> = > 
>= > (...) 
> > > > algorithm (which is an AlgorithmIdentifier = type): 
> > The object identifier for RSA PKCS #1 v1.5 with = SHA-256 MUST be 
> > used in the algorithm field, as specified in = Section 5 of 
> > [RFC4055]. The value for the associated parameters = from that 
> > clause MUST also be used for the parameters = field. 
> > > > I've never seen a certificate that declares = sha256WithRSAEncryption ({ 
> > = pkcs-1 11 }) as its public key algorithm. Every certificate I've = come 
>= > across labels its algorithm as rsaEncryption ({ pkcs-1 1 }). 
> = > 
>= > (Certificates always define the signature algorithm as 
> > = sha256WithRSAEncryption, but that's a different field.) 
> = > 
>= > Is everyone doing it wrong, or am I missing something? 
> = > 
>= > I'm aware that this is likely a triviality--rsaEncryption and 
> > = sha256WithRSAEncryption probably mean the same in this context. 
> > = There's also a thread in this list in which people seem to have 
> > = experienced headaches over this topic. But the thread is talking = about 
> > CMS signed objects (which I believe is different = from certificates), 
> > and happened before 7935 was released, so it feels = like the RFC should 
> > mandate something consistent with reality by = now. 
>= > 
> > Thanks for any pointers. 
> 
> You are = right. 
> 
> In the subjectPublicKeyInfo, the algorithm identifier = should be rsaEncryption, which is { 1, 2, 840, 113549, 1, 1, 1 }. This = allow the public key to be used with PKCS#1 v1.5, RSASSA-PSS, and = RSAES-OAEP. 
> 
> In the signature, the algorithm identifier should be = sha256WithRSAEncryption, which is { 1, 2, 840, 113549, 1, 1, 11 }. This = identifies PKCS#1 v1.5 with SHA-256 as the hash algorithm. 
> 
> = Russ 
> 
> 

_______________________________________________ 
sidr mailing = list 
sidr@ietf.org 
https://www.ietf..org/mailman/listinfo/sidr 
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_5F1C60AE-FE80-4FFB-A74C-A1EB384F5097--