From nobody Tue Sep 1 01:18:38 2020 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 7C2B93A0D9D for ; Tue, 1 Sep 2020 01:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 3JrPYEGM83sy for ; Tue, 1 Sep 2020 01:18:35 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20C63A0D9C for ; Tue, 1 Sep 2020 01:18:34 -0700 (PDT) Received: from [172.20.10.4] (unknown [109.37.140.135]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8F0851F79C; Tue, 1 Sep 2020 10:18:31 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598948311; bh=iJMPizyN/iMRS4EfnuzfdlyIkS3JW92mNzWmYfA6fxM=; h=Subject:From:In-Reply-To:Date:References:To; b=yh37lGls8ANo/u1s0RLl9NN47omWJKFWtVcbFDoMwV6nADfK7qTxjEhOZ82WW8uss lrvqqIOWZeU4BYyJMIP4Lyq/pYGy6XROJjxB2hPHcvHSz4DUD3aea5ywapsUbSV8kD 5i+Q09IyvHj2odRk0p9W07j5j447VWDVmbcjEltQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <159890072559.31155.191532586512778700@ietfa.amsl.com> Date: Tue, 1 Sep 2020 10:18:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> References: <159890072559.31155.191532586512778700@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 08:18:37 -0000 Hi all, I just submitted this as WG document per request by the chairs on July = 16. The issues that I think could be most controversial are: 1) rsync URIs as object identifiers (section 4) In summary: the document proposes that we keep rsync URI as useful = object identifiers even if the objects cannot be retrieved at that = location. The main reason for this is pragmatism: introducing a new kind = of object identifier (e.g. URN based) would introduce a breaking change = and make deployment much, much harder. 2) rsync still allowed Currently the document says (tries to say) that if operators want, they = can still leave an rsync server running. While they are not required to = do so, it is not forbidden either. 3) rsync URIs in RRDP - can they be trusted? Finally, we recently had a discussion related to manifests (6484-bis) = and a concern was raised that the rsync URIs in the RRDP XML cannot be = trusted. I also took this to the list on 25 June (subject RRDP and rsync = URIs). But for clarity I think it's best to continue to discuss here. While it may seem odd that the rsync URIs could be for different hosts = than the RRDP base URI, my main original motivation for allowing this in = RRDP was to provide CDN support. The Publication Server may outsource = its HTTPS function to a CDN, but it may not possible for this CDN to = handle or forward rsync requests. While any RRDP server can include any rsync URI in the and = elements in its XML, this is not really an issue because = relying parties know both the rsync URI *and* the RRDP server when = validating - so they can look for the rsync URI at the relevant RRDP = server only. The Publication Server (PS) is supposed to let its publisher publish = under a base uri only (RFC8181 and 8183). None of this is changed. In = principle the PS can have bugs, or do a poor job of checking this. But = they are already able to mess things up when we have rsync only. Because = of the compound URI (RRDP + rsync) there is no new attack vector opened = this way. Kind regards, Tim > On 31 Aug 2020, at 21:05, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : Resource Public Key Infrastructure (RPKI) = Repository Requirements > Authors : Tim Bruijnzeels > Randy Bush > George Michaelson > Filename : draft-ietf-sidrops-deprecate-rsync-00.txt > Pages : 10 > Date : 2020-08-31 >=20 > Abstract: > This document formulates a plan of a phased transition to a state > where RPKI repositories and Relying Party software performing RPKI > Validation will use the RPKI Repository Delta Protocol (RRDP) > [RFC8182] as the only mandatory to implement access protocol. >=20 > In short this plan consists of the following phases. >=20 > In phase 0, today's deployment, RRDP is supported by most, but not > all Repositories, and most but not all RP software. >=20 > In the proposed phase 1 RRDP will become mandatory to implement for > Repositories, in addition to rsync. This phase can start as soon as > this document is published. >=20 > Once the proposed updates are implemented by all Repositories phase = 2 > will start. In this phase RRDP will become mandatory to implement > for all RP software, and rsync must no longer be used. >=20 > Measurements will need to be done to help determine when it will be > safe to transition to the final phase of this plan. During this > phase Repositories will no longer be required to provide rsync = access > for RPKI validation purposes. However, they may still provide rsync > access for direct access to files for other purposes, if desired, at > a best effort basis. >=20 > Although this document currently includes descriptions and updates = to > RFCs for each of these phases, we may find that it will be = beneficial > to have separate documents for the plan, and each phase, so that it > might be more clear to all when the updates to RFCs take effect. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00 > = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-0= 0 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Sep 1 16:27:19 2020 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 9119D3A08C4 for ; Tue, 1 Sep 2020 16:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=algebras-org.20150623.gappssmtp.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 KBnWghnaeCRu for ; Tue, 1 Sep 2020 16:27:16 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 34E583A08B9 for ; Tue, 1 Sep 2020 16:27:16 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id w8so3331255ilj.8 for ; Tue, 01 Sep 2020 16:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eCjx6vxtwMpiYQ+Mc1GI6/8xHWtdcANtEBEilEQ7IFw=; b=EEfwp7MmCEfZ+Zd1QyJHAy6QjI8O5mTGPdbgdtzAx230ZFrwVVqiXhOKrhMs9e9us8 4dK/xk4AykWR9elxtkmLLPJFLKI2KhQpxrOFptgUY7lJvggqWYfb9d18mbkD22KoZDXm RFjsDvNAr8Vi3cFeY1d55qExcg4+cBtitOgNYontjQX79mCZqz8KzUtXQAFp33/xzz53 XN9rkg7Ghg/LWdxuTYaOvcstEIoI/xiS1UbQIVuSmqEuVuugNMCfdwih27/q8MaAixiN J2QQ/QuAPSHTFiuGxrMgZU0h1OQ65nKbmhjxECpKF7cOMPwYxpYqw3lmEsTZaPGaePfH F5UA== 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=eCjx6vxtwMpiYQ+Mc1GI6/8xHWtdcANtEBEilEQ7IFw=; b=TBiqX5ToDPxWEosXFu1FOOLTg1zypTSg+8nrV9lAHvjaPtbjhI98SmmNKuL7URPnEf nKBEiHOWK970NoL7zlKYgXVCvqpLA2ayA8t2DwTjOnf5DGZmVtBKWYJIbocnqANyKID6 H67n9OrX/zZEKwK1zJ595JKEryPsiYSk+5BGQfZ0D4SlQG/IWFny43lR4Jxi+Q3QVBvh hZh88Z2xCu3hhRu41xcflZt+0+AJAIJTvK4ZSv5AAsnrSnLrmqMi8Jhf1Ev3gqoxHQgz TiYiAYQxYJ6X02k3/Pjk8hI9c5ir6DTxCn0A1v5MlXfWHXV3EY0CWXIRJv+ip7BOS5z4 g+YA== X-Gm-Message-State: AOAM532aOka8fcHWPgbfuEFtV9smOh3ukeinPH9lm5MRWLohMSLRZDWa rYKZ6Tdu6OXp5NADnosUwnhvEfJV4QyjgClgp8B+GQ== X-Google-Smtp-Source: ABdhPJxO7Hl7N/7Fualkccw8JUTXgxK+PP6FwsHvzCO0y4BJOaxrO1XsdmpfCmXTcxXsfbzoZ5BBf4YdIz3TNaJtsYQ= X-Received: by 2002:a92:5e5b:: with SMTP id s88mr1201030ilb.65.1599002835122; Tue, 01 Sep 2020 16:27:15 -0700 (PDT) MIME-Version: 1.0 References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> In-Reply-To: <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> From: George Michaelson Date: Wed, 2 Sep 2020 09:27:04 +1000 Message-ID: To: Tim Bruijnzeels Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 23:27:19 -0000 Purely on aesthetics, and personal drive, I would prefer we change the "handles" which are rsync URI to be something else, preferably the HTTPS path to the object. I understand why people don't want to do this, but I would have chosen this path, had we not arrived at the point in time where the volume of RPs is non-trivial. The delay deciding on this has magnified the problem. This kind of thing has been discussed: people hate flag dates. OTOH, they never get easier by delaying. But, your comment about this being a breaking change for RPs is well made. -G From nobody Tue Sep 1 17:53:24 2020 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 A489B3A08E5 for ; Tue, 1 Sep 2020 17:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.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 xlL51vvc2Aeu for ; Tue, 1 Sep 2020 17:53:21 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 7C27F3A08DB for ; Tue, 1 Sep 2020 17:53:21 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id q14so3532690ilm.2 for ; Tue, 01 Sep 2020 17:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/bIH3CIvwPZrxk5PtTG/uoPwPfoge4sUipUuIvUpYww=; b=ib5OflXvUKM/Oc+pzw794i00m/AEG/ISbgcxIhRH0TQX9ra5a3/JLckbuglHzyi4FH uJ6QYlFWI6oQlZpucrsPzqjY6tnllEwGZMGaoUPAo/WtflQ4S2/lJZkdh17ihbrsv7vz pQqtlhQcNsp3W5XFNBgJ/GFRnJXO8zjvF23cpWG7bkC8DzkcytA4si4gs092iH3GPKWx /roSzoiZn7MUGoxiEbrKEUTB6KF2UEiUAGCpBmhwHdM5oSigxbNo9k5c9QXMaiv+JXht OLnX3dNsrkg8CIRBy7aG8SNVfVKkIklYiHIQnnTaVP6rRp6gbGZegToHEiyEHF6gO5v+ 14dw== 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=/bIH3CIvwPZrxk5PtTG/uoPwPfoge4sUipUuIvUpYww=; b=VzDOdXIKOW0OaWkIpsR8S//Zf50UOVzYt5r9H0yRp7/ygIiiflAa6KfYnXMGrTO2Rl viVFlq76e5owXLONeOLa4SCp5zVjJMOGZtMx1x6VjlMJNfkTxJtkgnyUsieG16mkoA/1 s/dw6ivqb7rnOrV4T++a6vObTTu1PKRuk0cHUIOpsNZP7E1Oe4wHPOMZzIXk54/iU3Ms k7rAgMlqRJ1UwmkV3YllLEpHVE5xgBPkw5ziL7bMpFTPmxitlNGFo5fhUsMLUs4Fydwn QO2O+Xl4rOGuOAlIrgCEl4bWCKCZmbK03k8tPjKzB12NO9I9x4oDhNVnIi3hCf8QcYDL 4IKw== X-Gm-Message-State: AOAM5306GxjzACBj4OniEOS8UaCEcr3vPPFYX9gbaXdMlNY4MM1ar7b+ 61cg6LVycqVuZ9f+BvPcDam8XKElECs8I59gI+aHU9ELE2gZ4HHl X-Google-Smtp-Source: ABdhPJxjwPgDlWPb2CLf+S+Sl7O5g5bjP1GTjLVau22ozm0ANSINze0i1s7/KBWC98oIi1OE39eYsWH5yAKMptNo8a0= X-Received: by 2002:a92:ad12:: with SMTP id w18mr1436782ilh.218.1599008000250; Tue, 01 Sep 2020 17:53:20 -0700 (PDT) MIME-Version: 1.0 From: George Michaelson Date: Wed, 2 Sep 2020 10:53:09 +1000 Message-ID: To: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] AS0 RPKI system deployed in production (Prop132) 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, 02 Sep 2020 00:53:24 -0000 ________________________________________________________________________ AS0 RPKI system deployed in production (Prop132) ________________________________________________________________________ The AS0 RPKI system previously in test has now been deployed to production. This completes implementation of APNIC Policy Prop132 "RPKI ROAs for unallocated and unassigned APNIC address space" https://www.apnic.net/community/policy/proposals/prop-132 A new TAL is being used which can be fetched from: https://tal.apnic.net/apnic-as0.tal Alternate forms of this TAL are also available and are documented at: https://www.apnic.net/community/security/resource-certification/tal-archive/ Please replace any prior TAL configuration in your RPKI validation systems. If you are not using this TAL consider adding it to get notification of authenticated denial of unallocated resources in the APNIC region. A report on deployment will be presented at APNIC50. This service will be discussed in the APNIC Routing SIG at the meeting, and subsequently on the mailing list: https://www.apnic.net/community/participate/sigs/routing-sig/ A blog article describing the deployment methodology is available at: https://blog.apnic.net/2020/09/02/policy-prop-132-as0-for-unallocated-space-deployed-in-service/ Caveats and warnings about the use of this AS0 ROA are documented at: https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki/#caveatsandwarnings ________________________________________________________________________ APNIC Secretariat secretariat@apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net ________________________________________________________________________ From nobody Tue Sep 1 20:30:30 2020 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 C5B3B3A0ABC for ; Tue, 1 Sep 2020 20:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1iAI7v512EtT for ; Tue, 1 Sep 2020 20:30:26 -0700 (PDT) Received: from out20-109.mail.aliyun.com (out20-109.mail.aliyun.com [115.124.20.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1283A0AB9 for ; Tue, 1 Sep 2020 20:30:24 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1448723|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0337084-0.00581254-0.960479; FP=0|0|0|0|0|-1|-1|-1; HT=e01l07440; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.IRU0oqt_1599017420; Received: from 192.168.90.98(mailfrom:madi@rpstir.net fp:SMTPD_---.IRU0oqt_1599017420) by smtp.aliyun-inc.com(10.147.40.44); Wed, 02 Sep 2020 11:30:20 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: Date: Wed, 2 Sep 2020 11:30:15 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: George Michaelson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] AS0 RPKI system deployed in production (Prop132) 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, 02 Sep 2020 03:30:29 -0000 George, Thanks for this update. I have RPSTIR2 configured with AS0 tal and being tested. Di > 2020=E5=B9=B49=E6=9C=882=E6=97=A5 08:53=EF=BC=8CGeorge Michaelson = =E5=86=99=E9=81=93=EF=BC=9A >=20 > = ________________________________________________________________________ >=20 > AS0 RPKI system deployed in production (Prop132) > = ________________________________________________________________________ >=20 > The AS0 RPKI system previously in test has now been deployed to > production. This completes implementation of APNIC Policy Prop132 > "RPKI ROAs for unallocated and unassigned APNIC address space" >=20 > https://www.apnic.net/community/policy/proposals/prop-132 >=20 >=20 > A new TAL is being used which can be fetched from: >=20 > https://tal.apnic.net/apnic-as0.tal >=20 > Alternate forms of this TAL are also available and are documented at: >=20 >=20 > = https://www.apnic.net/community/security/resource-certification/tal-archiv= e/ >=20 > Please replace any prior TAL configuration in your RPKI validation > systems. If you are not using this TAL consider adding it to get > notification of authenticated denial of unallocated resources in the > APNIC region. >=20 > A report on deployment will be presented at APNIC50. This service will > be discussed in the APNIC Routing SIG at the meeting, and subsequently > on the mailing list: >=20 > https://www.apnic.net/community/participate/sigs/routing-sig/ >=20 > A blog article describing the deployment methodology is available at: >=20 >=20 > = https://blog.apnic.net/2020/09/02/policy-prop-132-as0-for-unallocated-spac= e-deployed-in-service/ >=20 > Caveats and warnings about the use of this AS0 ROA are documented at: >=20 > = https://www.apnic.net/community/security/resource-certification/apnic-limi= tations-of-liability-for-rpki/#caveatsandwarnings >=20 > = ________________________________________________________________________ >=20 > APNIC Secretariat = secretariat@apnic.net > Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 > PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 > 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net > = ________________________________________________________________________ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Wed Sep 2 03:57:48 2020 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 21A3A3A10B9 for ; Wed, 2 Sep 2020 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WTrR9FtUZIjh for ; Wed, 2 Sep 2020 03:57:44 -0700 (PDT) Received: from out20-26.mail.aliyun.com (out20-26.mail.aliyun.com [115.124.20.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB8B3A10B6 for ; Wed, 2 Sep 2020 03:57:41 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1088736|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0673574-0.00624544-0.926397; FP=0|0|0|0|0|-1|-1|-1; HT=e01l10422; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.IRn7kdO_1599044253; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.IRn7kdO_1599044253) by smtp.aliyun-inc.com(10.147.40.2); Wed, 02 Sep 2020 18:57:34 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: Date: Wed, 2 Sep 2020 18:57:28 +0800 Cc: George Michaelson , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Di Ma X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] AS0 RPKI system deployed in production (Prop132) 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, 02 Sep 2020 10:57:46 -0000 George, It works very well with RPSTIR2 and you can use RPKI-VIZ to display its = structure. http://rpkiviz.zdns.cn/search?q=3Ddb42e932-926a-42bd-afdb-63320fa7ec40.roa= Di > 2020=E5=B9=B49=E6=9C=882=E6=97=A5 11:30=EF=BC=8CDi Ma = =E5=86=99=E9=81=93=EF=BC=9A >=20 > George, >=20 > Thanks for this update. >=20 > I have RPSTIR2 configured with AS0 tal and being tested. >=20 > Di >=20 >> 2020=E5=B9=B49=E6=9C=882=E6=97=A5 08:53=EF=BC=8CGeorge Michaelson = =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> = ________________________________________________________________________ >>=20 >> AS0 RPKI system deployed in production (Prop132) >> = ________________________________________________________________________ >>=20 >> The AS0 RPKI system previously in test has now been deployed to >> production. This completes implementation of APNIC Policy Prop132 >> "RPKI ROAs for unallocated and unassigned APNIC address space" >>=20 >> https://www.apnic.net/community/policy/proposals/prop-132 >>=20 >>=20 >> A new TAL is being used which can be fetched from: >>=20 >> https://tal.apnic.net/apnic-as0.tal >>=20 >> Alternate forms of this TAL are also available and are documented at: >>=20 >>=20 >> = https://www.apnic.net/community/security/resource-certification/tal-archiv= e/ >>=20 >> Please replace any prior TAL configuration in your RPKI validation >> systems. If you are not using this TAL consider adding it to get >> notification of authenticated denial of unallocated resources in the >> APNIC region. >>=20 >> A report on deployment will be presented at APNIC50. This service = will >> be discussed in the APNIC Routing SIG at the meeting, and = subsequently >> on the mailing list: >>=20 >> https://www.apnic.net/community/participate/sigs/routing-sig/ >>=20 >> A blog article describing the deployment methodology is available at: >>=20 >>=20 >> = https://blog.apnic.net/2020/09/02/policy-prop-132-as0-for-unallocated-spac= e-deployed-in-service/ >>=20 >> Caveats and warnings about the use of this AS0 ROA are documented at: >>=20 >> = https://www.apnic.net/community/security/resource-certification/apnic-limi= tations-of-liability-for-rpki/#caveatsandwarnings >>=20 >> = ________________________________________________________________________ >>=20 >> APNIC Secretariat = secretariat@apnic.net >> Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 = 3100 >> PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 = 3199 >> 6 Cordelia Street, South Brisbane, QLD = http://www.apnic.net >> = ________________________________________________________________________ >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Sep 2 10:39:55 2020 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 4F7153A0C2A for ; Wed, 2 Sep 2020 10:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 rFxq33eMnrNX for ; Wed, 2 Sep 2020 10:39:52 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 DAD1D3A0C15 for ; Wed, 2 Sep 2020 10:39:51 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id z2so4204169qtv.12 for ; Wed, 02 Sep 2020 10:39:51 -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=0ycXhAcFWUXi0t2j0OKTMls9td9y/AflP+8xXK/K3Ow=; b=KP0VaDjM7iwad8Ebx6z5tYYhmY2MCab+PJ+8dQlokEf4VSj2hVZP9I6OuHuoTX71Nt GzuX3mowDDN9b0ZWaV8rf4m6Iwbbshq3MHEvA/AYtk0oJ32du8YT8/p+xUmpO9vNVfBl xaIuTn3ExAY3QGdnVPxVOJpPerDmvUOIqmcn5zogvMI/ceQpfNc7bnBCToo8LG+mtHPU KDoXgLnlh4/9x7qCpBi4AuIpc+w4EFSoGfrSnz0W6E0jFe5r5hme7ly6pwgB1gxD3SWU zyA9T6/5C8xNKv2dpIWgKA6LO/rMD9CuR7bRUfa2KlBhcgLVwDX/NXstgwhexyPie303 qvzw== 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=0ycXhAcFWUXi0t2j0OKTMls9td9y/AflP+8xXK/K3Ow=; b=V2IQTsb9f6EZUS83HNKvaUPvcH9IHslK8CNIueFVrUf0BDCbDicgQf92YyqwLBp/ej xA1AO6AlEr0XNs3aqHB++NUhiaZEn1CSiAKgMiDipIbe654SAVzxWK4KtJq8AIX+esqr wRlrEi0Lec5yVD7lxF7IcNGqd4DscJfjKmIHYdR6XwFgoOfmXjHWzCkCaP9ngFnCKozk U6YB/iYSlgkwoO9jGIadwbogdoYjG/q/rSfpC6kPXNgwsi7HixcGHjWygYl+FtfrzEXn YU9jv9MI1A+iYpnekIl47B67zx3wTks1eGu7Y39bUzM+w6N93phmPDC+ufdC7t998ZZM qA9A== X-Gm-Message-State: AOAM53360gY6oFd92zXGt2AazqmeDCTnLDhpOrf+7HKQlP7LKrSGGYYj Pq+o7XW07KfcKOEthgaVFvcmzumSemHnDMAC+ragrEVNxT2SKg== X-Google-Smtp-Source: ABdhPJwkEVnnFjID/K8e+TT1ZcnuK5cQeDRaYrL6fIMIJPBgWYFeYPhAoNHujVJ4VkEj1aNBtt3eBV2yJu5yvcGsTPE= X-Received: by 2002:ac8:37bb:: with SMTP id d56mr7725078qtc.222.1599068390693; Wed, 02 Sep 2020 10:39:50 -0700 (PDT) MIME-Version: 1.0 References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> In-Reply-To: From: Christopher Morrow Date: Wed, 2 Sep 2020 13:39:39 -0400 Message-ID: To: Randy Bush Cc: Keyur Patel , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 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, 02 Sep 2020 17:39:53 -0000 asking as a wg participant... 1) I think some of the friction here is the use of eBGP in the document. This particular quote: (section 4) "(including a trusted EBGP peer for instance controlled by the same operator as lined out in Section 3)" PERHAPS this means 'confed boundary' not 'eBGP' ? 2) I think the purpose proposed is basically: "the speaker may be overloaded and not processing bgpsec functions, it could tell neighbors that this is happening" *** "neighbors" here meaning ibgp(and confed) only neighbors.*** 3) the proposal is to add some 'add magic/standard community to all routes processed, regardless of validation processing' where 1 value could be: "i could not process this route for validation... good luck fellow traveler!" I think leaking this outside your ibgp (or confed) boundary changes from having a simple metric system to a mess. If you want this for internal debug/metrics great. If you want your iBGP neighbors to perform validation on the routes because the edge-speaker skipped out on that... ok. If you want to send this knowledge along to your external peers, no. Why wouldn't they just perform BGPSEC validation on their own? How would you know if I added the 'can not process' or you did? or someone else did? How would you know what to do based on the community in question? (because you have no idea who added/removed/etc it) At best this becomes (across ebgp boundaries) useless info, since the speaker SHOULD just process the route normally (and if invalid drop). -chris there's this quote from the document: " On Wed, Aug 26, 2020 at 1:07 PM Randy Bush wrote: > > > A working group last call has been requested for > > draft-sidrops-bgpsec-validation-signaling-03, =E2=80=9CBGPsec Validatio= n State > > Signaling=E2=80=9D. Please reply to the list with your comments. The WG= LC will > > end on August 25, 2020. > > i think this is as good as we will do in this area. sad to say, among > other things, we are going to have rov incapable devices in our networks > for some years. > > but yes nick, perhaps sec cons could be sterner about filtering the > community. as you know, i am not fond of communities and leakage > thereof. but we're not going over to idr and creating an attribute. > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Sep 2 10:46:46 2020 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 0ED0D3A0B45 for ; Wed, 2 Sep 2020 10:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmP1HostnYyr for ; Wed, 2 Sep 2020 10:46:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C137A3A0943 for ; Wed, 2 Sep 2020 10:46:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kDWqH-0008Fn-2W; Wed, 02 Sep 2020 17:46:41 +0000 Date: Wed, 02 Sep 2020 10:46:40 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: Keyur Patel , "sidrops@ietf.org" In-Reply-To: References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 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, 02 Sep 2020 17:46:45 -0000 of course, i have no idea what the authors meant > 1) I think some of the friction here is the use of eBGP in the > document. This particular quote: > (section 4) > "(including a trusted EBGP peer for > instance controlled by the same operator as lined out in Section 3)" > PERHAPS this means 'confed boundary' not 'eBGP' ? yes, confed is ebgp. but there are providers with multiple ASs which might trust eachother, e.g. the classic 70[1-4] > I think leaking this outside your ibgp (or confed) boundary changes > from having a simple metric system to a mess. > If you want this for internal debug/metrics great. > If you want your iBGP neighbors to perform validation on the routes > because the edge-speaker skipped out on that... ok. > If you want to send this knowledge along to your external peers, no. > Why wouldn't they just perform BGPSEC validation on their own? lack of horsepower, expecially as the use case seems to be bgpsec randy From nobody Wed Sep 2 11:34:02 2020 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 97F823A0CC0 for ; Wed, 2 Sep 2020 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 BOTvDRhy_qtA for ; Wed, 2 Sep 2020 11:33:59 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27C3A0CBE for ; Wed, 2 Sep 2020 11:33:59 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 268202C607 for ; Wed, 2 Sep 2020 18:33:59 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id EFAF25640A3A; Wed, 2 Sep 2020 14:33:58 -0400 (EDT) X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24399.58769.547600.368430@oz.mt.att.com> Date: Wed, 2 Sep 2020 14:33:53 -0400 From: Jay Borkenhagen To: sidrops@ietf.org In-Reply-To: <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 02 Sep 2020 18:34:01 -0000 Steve, Stephen Kent writes: > The crux of the issue is whether it is preferable to reject all objects > at a pub point if an error is detected (until the error is rectified), > and thus potentially treat many more routes as having an unknown > verification status, or to accept bits and pieces of data from a pub > point with the potential that some routes will be treated as valid, even > if they are invalid. To me, that is a value judgement to be made by > network operators, not by developers of RP software. [...] No, there is a bit more to it than that. I want my network's routers and those of all other networks to be fed with VRPs that represent all the verified and legitimate published origin-ASN intentions of verified, legitimate IP number resource holders. Clearly the challenge there is in determining "verified" and "legitimate." In creating the rules (to be documented in standards-track RFCs) for those determinations, I would like the input of all SIDROPS participants to be valued, including the input of the RPKI designers, the CA- and RP-implementers, the RIRs, and the network operators. To my point: if RP-implementers feel that the "bits and pieces of data" (to use your words) should be considered to best make those determinations, such input should be welcomed; conversely, if RP-implementers feel that strict publication rules and accompanying strict handling of retrieved records together create the best way to make those determinations, we all should listen to what they have to say. > Experience with X.509 cert extensions suggests that the approach I noted > is preferable. Saying that older RPs can ignore objects they don't > understand introduces ambiguity in RP behavior, which is precisely the > concern that motivated the effort to generate 6486bis. Ambiguity is bad in any technical endeavor where precision is needed. And we're here discussing this now because there was ambiguity in rfc6486 (not assigning blame -- I missed it, too). But I don't see how it follows that if/when ASPA (for example) is standardized, that older RPs should be required to throw away all records retrieved from PPs whose MFTs now cite ASPA records. Thanks. Jay B. From nobody Wed Sep 2 12:02:27 2020 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 1C26A3A0CBA for ; Wed, 2 Sep 2020 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Mg1Pl-EqIT93 for ; Wed, 2 Sep 2020 12:02:25 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 D37973A0D0E for ; Wed, 2 Sep 2020 12:01:40 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id o2so113470qvk.6 for ; Wed, 02 Sep 2020 12:01:40 -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=3GaSHwVpFojZJWerQaVSleVaPEpkDobSB5cbV0PYP/U=; b=t6bwiVXcPehNQQ+jx+/mArKrATvObbCE0oWVvuECOWNDKAoMn9tRmeypo3A6GHRrpU iHJPSAgQ4fWBUMcioNpfrPRJyVwyoWXUNtrAjt2IKbFg/4w6L+UGXs8E7wQ+ijCILSeX pRqdvZKTETEMWLV/G8oqoAAqMTqvf3YBgMxj2K5jkaFjWsopY92XFpv8ZO7yQPKFFQVs hNqdIpFf5awY4DPIesBuWox01PtY09w+XVcRJ5TUUMkcAtJFvYa8Xcx6BYiEGrGkomF1 3SnmLjuAG/t27P6Z0K1llpi23LKeucqdoVRnYLCqfSXGpgVpMnzWuILBmGeaIpPHtsXX nGCw== 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=3GaSHwVpFojZJWerQaVSleVaPEpkDobSB5cbV0PYP/U=; b=mIb+j3O2eooMmFtCkbY5OHknibdDnL2Iitz5hQTuvpNc5EneP0qihnibicAGlepJDb GNRr1l6+WsavpcoYzoRfn89N4k6HdltCgRAHNxrg8Dia3+anNtViyzGIc7fDVIEwmjX5 oefAfkBE0dR8QEHqKCl7/LWBjlAAw2wLF28VLU792p8k3c/1Hbrum2R3txEn5JVvfFdF 7UcIv7eIkiOgitXtcuKLveJdNfZexO7bs+zLiERXo4Ow/QGTbUT96/xUfAN2wAlpVJJt FJYFXd/hXF/IhYB2KyawrHV2V9KQuKawjlDfxcL5ZPijRRAaJGXu0bSn8MfAGr9DGegE XEmA== X-Gm-Message-State: AOAM531/1/20LKA5JSj4rbWMxpRSs5cD4EX2JkVPg3bucXvnF29UKKQ8 0OUcO+RvMRpPnmfU79zuEL4RgnKjTM27DwOVU9M= X-Google-Smtp-Source: ABdhPJyzsk+/FlLVkgWWVIF0rzaSsce1f8oPXVKS86XQbEhHaWLhAwsiKe+igv2NgHbzbTuxtZsvIGcMDlwDSxe9118= X-Received: by 2002:a0c:ea34:: with SMTP id t20mr7964480qvp.233.1599073299691; Wed, 02 Sep 2020 12:01:39 -0700 (PDT) MIME-Version: 1.0 References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> In-Reply-To: From: Christopher Morrow Date: Wed, 2 Sep 2020 15:01:28 -0400 Message-ID: To: Randy Bush Cc: Keyur Patel , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 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, 02 Sep 2020 19:02:26 -0000 On Wed, Sep 2, 2020 at 1:46 PM Randy Bush wrote: > > of course, i have no idea what the authors meant > > > 1) I think some of the friction here is the use of eBGP in the > > document. This particular quote: > > (section 4) > > "(including a trusted EBGP peer for > > instance controlled by the same operator as lined out in Section 3)" > > PERHAPS this means 'confed boundary' not 'eBGP' ? > > yes, confed is ebgp. but there are providers with multiple ASs which > might trust eachother, e.g. the classic 70[1-4] Sure, but I think confed boundary passes non-transitive communities... so that should 'just work'. For cases of: "my 2 asn are not confed, but mine and I trust myself" I'd just signal across the boundary with some set of communities outside this set... heck, you probably have to already do that today, so this is just par-for-the-course. (I would think anyway) > > I think leaking this outside your ibgp (or confed) boundary changes > > from having a simple metric system to a mess. > > If you want this for internal debug/metrics great. > > If you want your iBGP neighbors to perform validation on the routes > > because the edge-speaker skipped out on that... ok. > > If you want to send this knowledge along to your external peers, no. > > Why wouldn't they just perform BGPSEC validation on their own? > > lack of horsepower, expecially as the use case seems to be bgpsec Sure, that was the reason the original speaker tacked on the community, right? the next neighbor though may not be in the same bind? > randy From nobody Thu Sep 3 17:40:52 2020 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 411173A005E; Thu, 3 Sep 2020 17:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3S9xUVvJR3YA; Thu, 3 Sep 2020 17:40:20 -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 DDCE53A11F2; Thu, 3 Sep 2020 17:39:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 481FEF40763; Thu, 3 Sep 2020 17:39:21 -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: <20200904003921.481FEF40763@rfc-editor.org> Date: Thu, 3 Sep 2020 17:39:21 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8897_on_Requirements_for_Resource_Public?= =?utf-8?q?_Key_Infrastructure_=28RPKI=29_Relying_Parties?= 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, 04 Sep 2020 00:40:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8897 Title: Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties Author: D. Ma, S. Kent Status: Informational Stream: IETF Date: September 2020 Mailbox: madi@zdns.cn, kent@alum.mit.edu Pages: 11 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidrops-rp-06.txt URL: https://www.rfc-editor.org/info/rfc8897 DOI: 10.17487/RFC8897 This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. This document is a product of the SIDR Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Fri Sep 4 08:40:14 2020 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 416273A0E1B for ; Fri, 4 Sep 2020 08:40:12 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 j5tOFdiS5N83 for ; Fri, 4 Sep 2020 08:40:10 -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 70C3C3A0E0F for ; Fri, 4 Sep 2020 08:40:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E4D5B300B7C for ; Fri, 4 Sep 2020 11:40:07 -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 bZgcF8rmEHiE for ; Fri, 4 Sep 2020 11:40:06 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id ED6DD30009B; Fri, 4 Sep 2020 11:40:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> Date: Fri, 4 Sep 2020 11:40:07 -0400 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt 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, 04 Sep 2020 15:40:12 -0000 Tim: I think that RFC 6487 should also be updated to adjust the RPKI = certificate profile. In phase 1, several URLs in the certificate could = offer rsync:// and rrdp://, and then in Phase 4 (not documented), the = rsync:// can get dropped. Russ > On Sep 1, 2020, at 4:18 AM, Tim Bruijnzeels wrote: >=20 > Hi all, >=20 > I just submitted this as WG document per request by the chairs on July = 16. >=20 > The issues that I think could be most controversial are: >=20 > 1) rsync URIs as object identifiers (section 4) >=20 > In summary: the document proposes that we keep rsync URI as useful = object identifiers even if the objects cannot be retrieved at that = location. The main reason for this is pragmatism: introducing a new kind = of object identifier (e.g. URN based) would introduce a breaking change = and make deployment much, much harder. >=20 > 2) rsync still allowed >=20 > Currently the document says (tries to say) that if operators want, = they can still leave an rsync server running. While they are not = required to do so, it is not forbidden either. >=20 > 3) rsync URIs in RRDP - can they be trusted? >=20 > Finally, we recently had a discussion related to manifests (6484-bis) = and a concern was raised that the rsync URIs in the RRDP XML cannot be = trusted. I also took this to the list on 25 June (subject RRDP and rsync = URIs). But for clarity I think it's best to continue to discuss here. >=20 > While it may seem odd that the rsync URIs could be for different hosts = than the RRDP base URI, my main original motivation for allowing this in = RRDP was to provide CDN support. The Publication Server may outsource = its HTTPS function to a CDN, but it may not possible for this CDN to = handle or forward rsync requests. >=20 > While any RRDP server can include any rsync URI in the and = elements in its XML, this is not really an issue because = relying parties know both the rsync URI *and* the RRDP server when = validating - so they can look for the rsync URI at the relevant RRDP = server only. >=20 > The Publication Server (PS) is supposed to let its publisher publish = under a base uri only (RFC8181 and 8183). None of this is changed. In = principle the PS can have bugs, or do a poor job of checking this. But = they are already able to mess things up when we have rsync only. Because = of the compound URI (RRDP + rsync) there is no new attack vector opened = this way. >=20 >=20 > Kind regards, > Tim >=20 >=20 >> On 31 Aug 2020, at 21:05, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the SIDR Operations WG of the IETF. >>=20 >> Title : Resource Public Key Infrastructure (RPKI) = Repository Requirements >> Authors : Tim Bruijnzeels >> Randy Bush >> George Michaelson >> Filename : draft-ietf-sidrops-deprecate-rsync-00.txt >> Pages : 10 >> Date : 2020-08-31 >>=20 >> Abstract: >> This document formulates a plan of a phased transition to a state >> where RPKI repositories and Relying Party software performing RPKI >> Validation will use the RPKI Repository Delta Protocol (RRDP) >> [RFC8182] as the only mandatory to implement access protocol. >>=20 >> In short this plan consists of the following phases. >>=20 >> In phase 0, today's deployment, RRDP is supported by most, but not >> all Repositories, and most but not all RP software. >>=20 >> In the proposed phase 1 RRDP will become mandatory to implement for >> Repositories, in addition to rsync. This phase can start as soon as >> this document is published. >>=20 >> Once the proposed updates are implemented by all Repositories phase = 2 >> will start. In this phase RRDP will become mandatory to implement >> for all RP software, and rsync must no longer be used. >>=20 >> Measurements will need to be done to help determine when it will be >> safe to transition to the final phase of this plan. During this >> phase Repositories will no longer be required to provide rsync = access >> for RPKI validation purposes. However, they may still provide rsync >> access for direct access to files for other purposes, if desired, at >> a best effort basis. >>=20 >> Although this document currently includes descriptions and updates = to >> RFCs for each of these phases, we may find that it will be = beneficial >> to have separate documents for the plan, and each phase, so that it >> might be more clear to all when the updates to RFCs take effect. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00 >> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-0= 0 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Sep 4 13:10:28 2020 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 877953A0FA5 for ; Fri, 4 Sep 2020 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 XGpWk8jWyXNS for ; Fri, 4 Sep 2020 13:10:24 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631BC3A0D87 for ; Fri, 4 Sep 2020 13:10:24 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540] (unknown [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9399024533; Fri, 4 Sep 2020 22:10:22 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599250222; bh=QbEvMKj+LCdJLBe/Fo+4GKgoma89g7mc7wGgMeH4saE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CC0xc8WBlnR305F7svrRKZFyLbfXc8kboHK5xuyfyQGSERf0uhsWdmtlLW/q6QHKF Q/IRY2ojCP0HnHqc9jPHhd+4FmBHZ4pmliKb83nAHg/B6ajdKXuX2ZD4BFht3punoK bwHlaoc9vcKWxKaCiGQwXPC/nmwphyGGkQyf+heY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> Date: Fri, 4 Sep 2020 22:10:22 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <47B41A31-D557-46E1-9EE7-56352C604224@nlnetlabs.nl> References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt 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, 04 Sep 2020 20:10:27 -0000 Hi Russ, On 4 Sep 2020, at 17:40, Russ Housley wrote: >=20 > Tim: >=20 > I think that RFC 6487 should also be updated to adjust the RPKI = certificate profile. Can you please elaborate why? My personal drive with this draft, despite its name perhaps, is to = deprecate the *operational* dependency on rsync. In my opinion the rsync = URIs can stay and serve as namespaces, even if the servers are not = guaranteed to be available. Think XML name spaces. I don't think we need = to forbid running rsyncd either. > In phase 1, several URLs in the certificate could offer rsync:// and = rrdp://, and then in Phase 4 (not documented), the rsync:// can get = dropped. It may not be aesthetically pleasing, but removing the rsync URIs = completely is a much, much bigger effort. Incomplete dump of pointers of = what would be affected: RFC6487: allow https URIs, or URNs maybe RFC8183: Repository Response, replace rsync base uri RFC8181: Publication Protocol, no more rsync uris RFC8182: RRDP, includes rsync uris - replace RFC6492: 'up-down': Let CAs request certs with other URI types New OIDs mean that all RPs treat objects as invalid. Essentially all RPs = would have to support the new OIDs before anything can be deployed by = CAs - or they will reject all publication points. Child CAs can only = deploy when parents support. Extending RFC8181 and 6492 will mean = multiple versions. If we really do need to go down this path, then I believe that this = exceeds the possible scope of this single document. And if we do *all* = this, then we should probably stop to think first about whether current = repository structure, and RRDP (which tried to follow rsync as close as = possible) are really what we want then. So, in short I would then suggest that we do this as a separate effort. = And we live with rsync URIs as namespaces for a while. Then at least the = operational burdens can be reduced while we figure out how to solve it = completely. Tim >=20 > Russ >=20 >> On Sep 1, 2020, at 4:18 AM, Tim Bruijnzeels wrote: >>=20 >> Hi all, >>=20 >> I just submitted this as WG document per request by the chairs on = July 16. >>=20 >> The issues that I think could be most controversial are: >>=20 >> 1) rsync URIs as object identifiers (section 4) >>=20 >> In summary: the document proposes that we keep rsync URI as useful = object identifiers even if the objects cannot be retrieved at that = location. The main reason for this is pragmatism: introducing a new kind = of object identifier (e.g. URN based) would introduce a breaking change = and make deployment much, much harder. >>=20 >> 2) rsync still allowed >>=20 >> Currently the document says (tries to say) that if operators want, = they can still leave an rsync server running. While they are not = required to do so, it is not forbidden either. >>=20 >> 3) rsync URIs in RRDP - can they be trusted? >>=20 >> Finally, we recently had a discussion related to manifests (6484-bis) = and a concern was raised that the rsync URIs in the RRDP XML cannot be = trusted. I also took this to the list on 25 June (subject RRDP and rsync = URIs). But for clarity I think it's best to continue to discuss here. >>=20 >> While it may seem odd that the rsync URIs could be for different = hosts than the RRDP base URI, my main original motivation for allowing = this in RRDP was to provide CDN support. The Publication Server may = outsource its HTTPS function to a CDN, but it may not possible for this = CDN to handle or forward rsync requests. >>=20 >> While any RRDP server can include any rsync URI in the and = elements in its XML, this is not really an issue because = relying parties know both the rsync URI *and* the RRDP server when = validating - so they can look for the rsync URI at the relevant RRDP = server only. >>=20 >> The Publication Server (PS) is supposed to let its publisher publish = under a base uri only (RFC8181 and 8183). None of this is changed. In = principle the PS can have bugs, or do a poor job of checking this. But = they are already able to mess things up when we have rsync only. Because = of the compound URI (RRDP + rsync) there is no new attack vector opened = this way. >>=20 >>=20 >> Kind regards, >> Tim >>=20 >>=20 >>> On 31 Aug 2020, at 21:05, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the SIDR Operations WG of the IETF. >>>=20 >>> Title : Resource Public Key Infrastructure (RPKI) = Repository Requirements >>> Authors : Tim Bruijnzeels >>> Randy Bush >>> George Michaelson >>> Filename : draft-ietf-sidrops-deprecate-rsync-00.txt >>> Pages : 10 >>> Date : 2020-08-31 >>>=20 >>> Abstract: >>> This document formulates a plan of a phased transition to a state >>> where RPKI repositories and Relying Party software performing RPKI >>> Validation will use the RPKI Repository Delta Protocol (RRDP) >>> [RFC8182] as the only mandatory to implement access protocol. >>>=20 >>> In short this plan consists of the following phases. >>>=20 >>> In phase 0, today's deployment, RRDP is supported by most, but not >>> all Repositories, and most but not all RP software. >>>=20 >>> In the proposed phase 1 RRDP will become mandatory to implement for >>> Repositories, in addition to rsync. This phase can start as soon as >>> this document is published. >>>=20 >>> Once the proposed updates are implemented by all Repositories phase = 2 >>> will start. In this phase RRDP will become mandatory to implement >>> for all RP software, and rsync must no longer be used. >>>=20 >>> Measurements will need to be done to help determine when it will be >>> safe to transition to the final phase of this plan. During this >>> phase Repositories will no longer be required to provide rsync = access >>> for RPKI validation purposes. However, they may still provide rsync >>> access for direct access to files for other purposes, if desired, at >>> a best effort basis. >>>=20 >>> Although this document currently includes descriptions and updates = to >>> RFCs for each of these phases, we may find that it will be = beneficial >>> to have separate documents for the plan, and each phase, so that it >>> might be more clear to all when the updates to RFCs take effect. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-0= 0 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Sep 4 13:34:20 2020 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 AB5B33A100A for ; Fri, 4 Sep 2020 13:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7VReYYnliWKH for ; Fri, 4 Sep 2020 13:34:18 -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 567213A0A96 for ; Fri, 4 Sep 2020 13:34:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F13E8300B92 for ; Fri, 4 Sep 2020 16:34:15 -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 YIKB6HkaZWnE for ; Fri, 4 Sep 2020 16:34:14 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id A411E300B42; Fri, 4 Sep 2020 16:34:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <47B41A31-D557-46E1-9EE7-56352C604224@nlnetlabs.nl> Date: Fri, 4 Sep 2020 16:34:16 -0400 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> <47B41A31-D557-46E1-9EE7-56352C604224@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt 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, 04 Sep 2020 20:34:20 -0000 Tim: >> I think that RFC 6487 should also be updated to adjust the RPKI = certificate profile. >=20 > Can you please elaborate why? >=20 > My personal drive with this draft, despite its name perhaps, is to = deprecate the *operational* dependency on rsync. In my opinion the rsync = URIs can stay and serve as namespaces, even if the servers are not = guaranteed to be available. Think XML name spaces. I don't think we need = to forbid running rsyncd either. For example, RFC 6487, Section 4.8.6 says: ... The preferred URI access mechanism is a single rsync URI ("rsync://") [RFC5781] that references a single inclusive CRL for each issuer. ... Other access form URIs MAY be used in addition to the rsync URI, representing alternate access mechanisms for this CRL. There are similar words in Sections 4.8.7, 4.8.8.1, and 4.8.8.2. It seem to me you are changing the "preferred" way to handle these, even = if both are allowed for decades. >=20 >> In phase 1, several URLs in the certificate could offer rsync:// and = rrdp://, and then in Phase 4 (not documented), the rsync:// can get = dropped. >=20 > It may not be aesthetically pleasing, but removing the rsync URIs = completely is a much, much bigger effort. Incomplete dump of pointers of = what would be affected I agree, and that it is why I called it Phase 4, which is beyond the = scope of this document. Russ From nobody Fri Sep 4 13:40:52 2020 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 BD6933A0FC0 for ; Fri, 4 Sep 2020 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 0qud4yHD2-ie for ; Fri, 4 Sep 2020 13:40:48 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F213A0CE7 for ; Fri, 4 Sep 2020 13:40:48 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540] (unknown [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 82E4F2456E; Fri, 4 Sep 2020 22:40:46 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599252046; bh=K7yI1fWFQvp/RCHeO0d95geIrtYbyO4KALyR5PGCnYc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QLspyPa19YXoURG+Id+wZpDz6fTRrmUQKKbUcdtJUzWn28QHcUx4HuzYuOAS0jmwA zjXcgK2uq4bpG1bd4FD4fcVeKbk6xRE93HZjfbO6Vhdn8/AeQocUDLVWBt7+pmxvgk LFLBe4J48apbfqGXrHbnnNJS1rcUtY70LbYfOWRE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <24399.58769.547600.368430@oz.mt.att.com> Date: Fri, 4 Sep 2020 22:40:46 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> <24399.58769.547600.368430@oz.mt.att.com> To: Jay Borkenhagen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 04 Sep 2020 20:40:51 -0000 Hi, > On 2 Sep 2020, at 20:33, Jay Borkenhagen wrote: >=20 > Steve, >=20 > Stephen Kent writes: >> The crux of the issue is whether it is preferable to reject all = objects=20 >> at a pub point if an error is detected (until the error is = rectified),=20 >> and thus potentially treat many more routes as having an unknown=20 >> verification status, or to accept bits and pieces of data from a pub=20= >> point with the potential that some routes will be treated as valid, = even=20 >> if they are invalid. To me, that is a value judgement to be made by=20= >> network operators, not by developers of RP software. [...] >=20 > No, there is a bit more to it than that. >=20 > I want my network's routers and those of all other networks to be fed > with VRPs that represent all the verified and legitimate published > origin-ASN intentions of verified, legitimate IP number resource > holders. >=20 > Clearly the challenge there is in determining "verified" and > "legitimate." In creating the rules (to be documented in > standards-track RFCs) for those determinations, I would like the input > of all SIDROPS participants to be valued, including the input of the > RPKI designers, the CA- and RP-implementers, the RIRs, and the network > operators. >=20 > To my point: if RP-implementers feel that the "bits and pieces of > data" (to use your words) should be considered to best make those > determinations, such input should be welcomed; conversely, if > RP-implementers feel that strict publication rules and accompanying > strict handling of retrieved records together create the best way to > make those determinations, we all should listen to what they have to > say. I don't think it's entirely fair to say that us 'developers' are willing = to create security issues for network operators. This document is still under discussion, and there simply are still = cases that are not fully discussed, e.g. how to filter VRPs if a = publication point is found to be bad - to which I posted a suggestion = only last week. I thought that discussion phases were meant for that. To = look at things from different angles. I am quite certain though that = consensus can be reached if we have constructive talks, and that = implementation can follow quickly when it does. To the point of "bits and pieces". Rejecting a full publication point is = the easiest to reason about, so I can see its appeal. That said, = consider the case where a ROA is invalid because it contains a prefix no = longer held by the CA. Instead of rejecting the complete PP for a CA = certificate, and filtering out all VRPs overlapping the resources on it, = one could also reject all the invalid ROAs and only filter out VRPs that = have any overlap with those ROAs. I understand this is a bit more = elaborate, but not dramatically different. As far as I can tell it is = just as secure in that this cannot result in RPKI invalid announcements = because of a single invalid ROA object. Note that I talk about ROA objects that can be fetched, and are known to = be current. I.e. the actual manifest content. And provided they can be = parsed and validated so you know which resources are affected. If any = objects are missing or obsolete then assume the worst - I actually made = statements to that effect months ago. In any case, I can live with the reject-all model for its simplicity. = But I would like to hear an operator input on whether this is indeed = desirable. And that the consequence of child CAs - even NIR sized ones - = blinking out for a few hours every now and then is an acceptable price = for this simplicity. Tim >=20 >> Experience with X.509 cert extensions suggests that the approach I = noted=20 >> is preferable. Saying that older RPs can ignore objects they don't=20 >> understand introduces ambiguity in RP behavior, which is precisely = the=20 >> concern that motivated the effort to generate 6486bis. >=20 > Ambiguity is bad in any technical endeavor where precision is needed. > And we're here discussing this now because there was ambiguity in > rfc6486 (not assigning blame -- I missed it, too). But I don't see > how it follows that if/when ASPA (for example) is standardized, that > older RPs should be required to throw away all records retrieved from > PPs whose MFTs now cite ASPA records. >=20 > Thanks. >=20 > Jay B. >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Sep 4 16:14:02 2020 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 4B0EA3A0B8B for ; Fri, 4 Sep 2020 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 vI3VnrgT4iJT for ; Fri, 4 Sep 2020 16:13:58 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C5B3A0B6E for ; Fri, 4 Sep 2020 16:13:58 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540] (unknown [IPv6:2001:981:4b52:1:55e4:165c:ff49:a540]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 7C62B24751; Sat, 5 Sep 2020 01:13:56 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599261236; bh=jTnEqQkKgEytlXGPUjfPIohzVTah/MLyC6qVHi9BpAI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Ceir8LqxrmtJQNWIUOpJO2uZGU6ppz+HhSu5HwK8Rd3zYJI3XbZjHBCNlud+GVQDY Yg7tID9qZBhWxP08pXoS1n8dKRszNh5dKOp80yamn18SuzDS+TI25fjRidaOMuI6kR zYq00JuphyB9j19/3PuJrIfKZVKnfXmDXF5YoyhE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl> Date: Sat, 5 Sep 2020 01:13:56 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02763DA8-EE43-405B-9D87-B704D33D9C57@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> <24399.58769.547600.368430@oz.mt.att.com> <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl> To: Jay Borkenhagen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 04 Sep 2020 23:14:00 -0000 > On 4 Sep 2020, at 22:40, Tim Bruijnzeels wrote: >=20 > Hi, >=20 >> On 2 Sep 2020, at 20:33, Jay Borkenhagen wrote: >>=20 >> Steve, >>=20 >> Stephen Kent writes: >>> The crux of the issue is whether it is preferable to reject all = objects=20 >>> at a pub point if an error is detected (until the error is = rectified),=20 >>> and thus potentially treat many more routes as having an unknown=20 >>> verification status, or to accept bits and pieces of data from a pub=20= >>> point with the potential that some routes will be treated as valid, = even=20 >>> if they are invalid. To me, that is a value judgement to be made by=20= >>> network operators, not by developers of RP software. [...] >>=20 >> No, there is a bit more to it than that. >>=20 >> I want my network's routers and those of all other networks to be fed >> with VRPs that represent all the verified and legitimate published >> origin-ASN intentions of verified, legitimate IP number resource >> holders. >>=20 >> Clearly the challenge there is in determining "verified" and >> "legitimate." In creating the rules (to be documented in >> standards-track RFCs) for those determinations, I would like the = input >> of all SIDROPS participants to be valued, including the input of the >> RPKI designers, the CA- and RP-implementers, the RIRs, and the = network >> operators. >>=20 >> To my point: if RP-implementers feel that the "bits and pieces of >> data" (to use your words) should be considered to best make those >> determinations, such input should be welcomed; conversely, if >> RP-implementers feel that strict publication rules and accompanying >> strict handling of retrieved records together create the best way to >> make those determinations, we all should listen to what they have to >> say. >=20 > I don't think it's entirely fair to say that us 'developers' are = willing to create security issues for network operators. >=20 > This document is still under discussion, and there simply are still = cases that are not fully discussed, e.g. how to filter VRPs if a = publication point is found to be bad - to which I posted a suggestion = only last week. I thought that discussion phases were meant for that. To = look at things from different angles. I am quite certain though that = consensus can be reached if we have constructive talks, and that = implementation can follow quickly when it does. >=20 > To the point of "bits and pieces". Rejecting a full publication point = is the easiest to reason about, so I can see its appeal. That said, = consider the case where a ROA is invalid because it contains a prefix no = longer held by the CA. Instead of rejecting the complete PP for a CA = certificate, and filtering out all VRPs overlapping the resources on it, = one could also reject all the invalid ROAs and only filter out VRPs that = have any overlap with those ROAs. This should have said: overlap with the intersection of resources on = those ROAs and the CA certificate. > I understand this is a bit more elaborate, but not dramatically = different. As far as I can tell it is just as secure in that this cannot = result in RPKI invalid announcements because of a single invalid ROA = object. >=20 > Note that I talk about ROA objects that can be fetched, and are known = to be current. I.e. the actual manifest content. And provided they can = be parsed and validated so you know which resources are affected. If any = objects are missing or obsolete then assume the worst - I actually made = statements to that effect months ago. >=20 > In any case, I can live with the reject-all model for its simplicity. = But I would like to hear an operator input on whether this is indeed = desirable. And that the consequence of child CAs - even NIR sized ones - = blinking out for a few hours every now and then is an acceptable price = for this simplicity. >=20 > Tim >=20 >=20 >>=20 >>> Experience with X.509 cert extensions suggests that the approach I = noted=20 >>> is preferable. Saying that older RPs can ignore objects they don't=20= >>> understand introduces ambiguity in RP behavior, which is precisely = the=20 >>> concern that motivated the effort to generate 6486bis. >>=20 >> Ambiguity is bad in any technical endeavor where precision is needed. >> And we're here discussing this now because there was ambiguity in >> rfc6486 (not assigning blame -- I missed it, too). But I don't see >> how it follows that if/when ASPA (for example) is standardized, that >> older RPs should be required to throw away all records retrieved from >> PPs whose MFTs now cite ASPA records. >>=20 >> Thanks. >>=20 >> Jay B. >>=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sat Sep 5 11:07:23 2020 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 5C6713A0B9A for ; Sat, 5 Sep 2020 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 ECiuqIgtuPg2 for ; Sat, 5 Sep 2020 11:07:20 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 1CF953A0B93 for ; Sat, 5 Sep 2020 11:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329238; bh=DmDWqkIVvhFUCXSrS551BWp+vhicLybq/5JHuyLKn5w=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=IeIcjXUKiT6+STseD5SuR3UkZpINDFIJ9XWZo5CqXn9ZU6utBkxLlUN+KH/Uvjkuhs8n1jHO21DZT/BeQ968typyP7OENCIXRRwVMnS7nVOxx8dr38MKtlINPnX2lXAMpz5q9hDtyx9PkDXXuuzmpgZ8IQGH+H32LT4c9VU8yWVfply7kvmvTZnz6nX2/mDShiT+e+PaMen2zDWqQEZ/SSa/uODvRdeVe/SQCJPwzi6yPpKCfqbsatX7xLvMmShVvUR07YOAPQY5vAI3J8LHPIPMJOnGbm+Z/P3lepfCiIjv02cSizxKDHAGXnmWKShBokjx8H7xLwRwsbDgRpKaJQ== X-YMail-OSG: NVUpvqsVM1mio979fyXpNqkBc5yJv4RdMFJwle4TE3wwTBLacG__bH6n73u6YLK J4LIwZcdi1KJbtbUz0vMfGlhLYo9.uyMlnEm4kqpjhJdOLmVEhP8qLCAGMUpcD5XswGjzQOHykpz hPVgNnIiNMS7ves4iE0Eiy6YdwwMYKOiJaccH7wOGE1h1w5shJTRhuhF125U.T8.miGre_N4nmEl WD7wRFD_0ShqgCF84CNx6i608Y6O7kHXhVgb9DcYm_Lke1Se0qOdPBuMRDshmsNPmSoenrY3xlr7 IRpfWbZfhLIvqAjo2Em3Yk.B3_JqpflymT.FzHH9dQJvMp1dBNcZcpsIj_yPbTzQlicunTaaRb15 nAseExvLTuks4dfHF658uqYY3W2pjEQLdDq1pOjQebfLLCrerQjfWum8pPkSgBQk7vuPLCvJYM2i ZAQYeLUeCM1GePyr2UQIT6mV1L7da8.9FFuB4lNPZHNXcs84RQz3HKTgqUyRtZp.lN_ecPJbc9E_ 9vWtAK9UaviyMCBu5BqSinoU7fig9WVuPcNoOU8_8Fo.eufeIHNixZXydye6BMIGZCSW.fiZ17JL N7031F7qfCPS33FigwddvXtyuI7W842V9LWtiQkCikyvG1SX1BFYtw16X9HxV8zwVBoFj2y_aA10 _Vlsc5n.TA8MB8HLb.YmYkqX1sVl9.MKzgPZDV2mja9PVG7XshJU63JczdA1t60Ck_5cN8os7SY5 V5g2CLqWz0lim7l86b7NaSzKKL_YFM7Gq.s51pwOMmCCSrx47k9t.qFNXNOE9U5o6fesS9kNNjdG jB22vdulKdMlWmHJtFpjAnP7ahdkMLJTuvCqCUB09kYopCpFQFvxg_Wx3ywqU69ZucDD.TJ91MCB 1fc8kzIKc6hk9nQsxwyZgThT5U8ml4dk37U.C6IbTCbbBrUOkmBZMCMFhg4A05iDOajX_vSxLOYk hPmFW9Jo3Al5p.7NSJui5FoNqZoXd7JZ62gAB_kHtQhmB3OOWlS9Xl4B17qEIV4BcuzBuG2CKec6 BiFJRRGZhZ3m7NTPLS64Ngay.j4GED11dAhqfuJUwpbk62D7sYUxfwk4M.DUZ2oWK6_EUpAkyxIe MGCy6jSZ8I_byCxk7MDvr4O1vcjHDv7mKzFY2Yj71Y_9QeGOmAQTImxZaUWexrPukLHE26pWMJPP UuFRtJA7IBNBWqCIW.UZ5Q7rv1rO.dVKlu7TXiUbqK6_KZW.VkZzDZPVQewU85JA1.wuTc016nkj 6_n_AyQPbhub8ClIhpgi4H8KI20lYFxTcPrMG9bj8g0EwlFwEya1w591GUSa8a86hmDqBnQ7EE8E JnFOm7CV0IpCwzgb_l7Rh6n3N3CJYLqt5pWb3OrL1pOfeYI6IaFFyN71qAxk0o92fwm7M676zUUm _yh.prLzdcpEgzqUOE0pnhcGYjBNYNr2rt2gA715MNJ85ChSzCBzgy4JBXTZ0Lyy4jtFAkYprxoZ FZDNK_YRY8g5vo1ZqV.5jfvlILhkkyUzcIYBuKFgfkq0HH6NTpIbbVrhhgnT3Oe.HHowFwGd4TVS z1n5tI1h7QUfgsJaTm4fZDTg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:07:18 +0000 Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 408f46627a2546e15d319d1b4548c1fd; Sat, 05 Sep 2020 18:07:17 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> <24399.58769.547600.368430@oz.mt.att.com> Message-ID: <4f1dd854-3adc-e9f0-c818-186c7ac613d0@verizon.net> Date: Sat, 5 Sep 2020 14:07:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <24399.58769.547600.368430@oz.mt.att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 05 Sep 2020 18:07:22 -0000 Jay, > ... > > To my point: if RP-implementers feel that the "bits and pieces of > data" (to use your words) should be considered to best make those > determinations, such input should be welcomed; conversely, if > RP-implementers feel that strict publication rules and accompanying > strict handling of retrieved records together create the best way to > make those determinations, we all should listen to what they have to > say. Sorry, but I beg to differ on this point. My judgement of what is critical to the "best" operation of an ISP is not as valuable as that of an experienced network operator. On the other hand, my judgement on what constitutes secure operation in a PKI context, is, IMHO, more valued than that of most folks. We each have our strengths and limitations and these ought to be taken into account when valuing inputs to a standard like this. That's what I expect the WG chairs to do when reviewing comments on the list. > > Experience with X.509 cert extensions suggests that the approach I noted > > is preferable. Saying that older RPs can ignore objects they don't > > understand introduces ambiguity in RP behavior, which is precisely the > > concern that motivated the effort to generate 6486bis. > > Ambiguity is bad in any technical endeavor where precision is needed. > And we're here discussing this now because there was ambiguity in > rfc6486 (not assigning blame -- I missed it, too). But I don't see > how it follows that if/when ASPA (for example) is standardized, that > older RPs should be required to throw away all records retrieved from > PPs whose MFTs now cite ASPA records. I quickly reviewed the ASPA ID. I didn't see a description of how the RPKI is used to validate these newly-proposed, signed objects.  Until that is made clear, it isn't clear why an ASPA even belongs in the RPKI repository system. So, your question seems premature. Steve From nobody Sat Sep 5 11:08:58 2020 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 059113A0B9C for ; Sat, 5 Sep 2020 11:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 zXWQP4YP1gr3 for ; Sat, 5 Sep 2020 11:08:55 -0700 (PDT) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 9A53D3A0B9A for ; Sat, 5 Sep 2020 11:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329334; bh=AIkzhvKUuQ90GEcBp4Xt1TBmCLinFz+yvxsJUm8cafw=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=uFQYSHEq2P+3KukaquLUCDQ6sfioPoTr5hTYTFJLPHK/afhskOWz0hyd89LC8+MwcqSDEm99tCtORRmJTOhRqC3H0wLEYVAcoj/xwAYcjZDIkD7U9b2UHfH9gA5nE6HpOy7WrdBzBNPvjp1R1ehrEUhK9KWSvmPxQcppbwDkDpgGDK4cmBL7o5S79+s7Xp24i9RNeQC7PC5t6pA2S3b2pboUAvNFao9SMibvzVqcqOolzZhxaHKKzCH2DMnXtqUBFsA7FY6m8NGWrI47Qr6dlFSrj1Fm7gO0cNP7qVcDS9kkUacG2MiEyaMtKG+pZEOqI+JJ6ClhYqCW60d5USreug== X-YMail-OSG: yQN9qD8VM1kL2RzwX2AJuDiv_QBb75LsxUWaBtImgGReuOrIZH5ZYV5KRbpevPJ 1vz19SjM18Gz3OJ54pYWF2VZwsP62Ncka2M7C_6LC0.4AvMlHddF0_qqv.sRFodeSDJIvEMUkTlG zm.cxHJ82TKIHXyyq8wAuImaZxgFsLZ2fjUy9FfN5dzrNk2EyR4jr05YfoQGzMkqRFjZ_NVkZPUY 81KPdjLekc1ODIcBV2niPgHiqwuKH6Vz6m0Pl3dYiao4TTswOMJUKT9yezcCax5IqnzNz8nfTvOE U6EHmZO4HRHDXgwxwIGQ.aQaY.1MyEYFQ.9rIaDdWWCRcObjeklydNPnuRwJ8BtBOs8h3z6EwpMh Rw8NP6kn8e8XbfeTp7n7a9PganD0V4Jo6ijmNv0Fj5X0mb30rXlqns6WdUCrJsUXWLtf1gttNz4E QggA96GvbAC6WGkjJGlbXjnkvcJbBpaEedS9C1POitX4dgOXytU8RfziEwNWhoIxkcf0slT9DVy6 im3faJbZvq7iXPbsUfKtNY8D7NUFEMFgEjWg9chQBFjL5A69B5O5HI8ScVAG6I68Ct63txLjRywS IVaSIWeMRdgx7NcM2.GDfNcynGy8NNxh6WJz3Jafhp7.nqgrilzey06EDEt4BvAc_iJ75DUvLfFv QjWm1mVJ0rfAxD51MpfQhSi_CsSzATvqIu6Nrhq2gb7p70LsGjqrs6vjp.kPatAQEJHJcV93ZA9G pXhzw1nCxdl6ClTdfWs9FJ6NvsurQOav8QpRkHI1ag2ZmenEabxFaXnxCTRLS99zp3o6VclF.6jh T7qkOOqkBp_BiVQEMA0aXJyIkJFul2i7Ca6anUMa7eP1vbI.pi5jvDwFyNFpZYNKIQF3PuNkS_pc vg_U881hsPv0subRxHP5ap08FjxQZFA9lPZe9zDj7JQeiFP55LyyN1rWpaVxLpGM.Q_F702ZcPU2 BXgSrUoQFrN02a5PlEIo9Tanx8oiDOAjSiL118eg5vMVj5YX82NFoMJhWV9pTDWyAggqx8H3b_WM xnHjko8Ef2RG9TJMHcHFxeix5AMPy1SUKh7pwqdcuwnIFoBWXEyun5S6Dczd04i_nHVP1r.n9Q.A dqW3iFXuInnh0EqkEeFlPx8YAuUVEEqKBreXgQEedCxb8wTiYoJrEug0dDSDtzDPGzeP0TvlM9Dn D3Plz_4.stn7TOYacNpd1AFOElLqP8fkgt8pJH_5z080z4lyV0kKSCpNKEQnLTH_mSFGjlyZQoW. Wa41nMtQBKIOfdQ81_nIe71rHPQeuJzjRuxh.VISIzd2zWMHyB.Om5KtZheP0ezLbPXLqArCOScP ccS1trToC0KltSPVdz3LRIxnClUkOG1YXNCZWcmhR8tyx1nwvVZleODQSjzqWiijLI10RUV9ihNO 8HnQPPrwo5Lc3lnBkCv7nRWiSRiXZ.zuw0LqZFgG0qO26PrU3Nz1mDsU.f9TV.IqEPVZ2ECdGYcZ a5ldk6qRWwMpcO3.BOSoGpqjPhUHVK5PCzOABIa886V9ysdAAaV3If3gn0IgrB6xFEv5vn2E0IM0 dUUECJRYjDprH_36zgKoF4u1RiKzhZch.51hanaU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:08:54 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b4bc99c3f870284ca36f0129e64e7f6; Sat, 05 Sep 2020 18:08:50 +0000 (UTC) From: Stephen Kent To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> Message-ID: <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> Date: Sat, 5 Sep 2020 14:08:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 05 Sep 2020 18:08:57 -0000 Tim, > ... > In short: Given that I expect that we are never come to a consensus other than the total reject-all-if-one-fails - I can live with this if we must, but don't let it come as a surprise. Works for me. >> ... >> Allowing RPs to ignore object types they don't understand prevents a CA from being able to convey the notion that a new object type is important (to that CA). I don't think this is a good strategy. It means that RP behavior will be ambiguous relative to new object types. > So far none of the objects have seemed to need this flag. If the goal is to define a very general scheme, then a flag may be necessary to accommodate objects not yet defined, since we cannot yet know whether a uniform response for all such objects will be appropriate. I agree that this need not be a binary flag, as in cert extensions. You suggested a three-value flag below, for example. > ... >> If we want to have a consistent and flexible approach to accommodating new objects I suggest the strategy I mentioned earlier. Define an additional SIA URI that points to a pub point (and manifest) where we can introduce the next version of the signed object format, one that includes a critical flag, analogous to X.509v3 extensions. This allows each CA to decide which object types have to be processed by an RP in order for the whole pub point to be accepted vs. rejected. Note that this will require modifying a lot of RFCs, but it is a flexible, extensible approach to this issue. > I agree that it's flexible and extensible. I had not thought of this approach. > > But it is a lot of work, not just in RFCs, also in code. It also raises questions about how and when old PPs without the new objects can be deprecated. You can give operators more time to upgrade, but at some point plugs will probably be pulled? Maintaining multiple PPs indefinitely seems rather wasteful. > > I would like to hear what others have to say.. I have the feeling that ASPA is getting close, and I would really not like to see it delayed because of this. It will take a while to complete another revision of the manifest doc, if we purse additional changes, and even longer before an RFC is approved and published. So ASPA will not be accommodated quickly. Also, as I noted in my reply to jay, a quick read of the ASPA doc didn't indicate how these new objects are validated using the RPKI. > If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand. One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea. Your example bothers me a bit- it seems to argue for CA-directed processing flags, perhaps to accommodate experimentation with new object types. This sounds like adopting elements of the IRR DB model which didn't seem to be so great, IMHO. Separately, I think we need to make GBR mandatory for all pub points. If the intent is to cause RPs to contact a CA/pub point maintainer when errors are encountered, then we need to be confident that RPs know who to contact and how. Steve From nobody Sat Sep 5 11:14:53 2020 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 A54E63A0AF5 for ; Sat, 5 Sep 2020 11:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 avNbmyx60MYD for ; Sat, 5 Sep 2020 11:14:50 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 02F463A09C0 for ; Sat, 5 Sep 2020 11:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329687; bh=RTRJAkdTG8Jja342KVk6egAtoiB+HZ/MD1XPVQc9eag=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=QBZgxkuXVHwwfjhYbCm7T4dsW4aAwsjFIPU61c31C5U8WgOSfOblhYPJ74gEBVNP0QICqzqCvHdIlT+lvs8ky/5bZvKrXgsE0lAfq8I1QC+WTg6RMat4AYHeh5T0uO5QTECiSdN9OXbJSAtND4DhLm4iYDW8aNafJuChmnrCwJWWvH9A2p62SIZofJAQMC8VtA+NOEby5H9XES3qlZhDZsfMA/voXFPKIKq6BTYWYcFsKy/5K0f790GE8m3m1jZS91IokGOvBaQ1m6GNUi+qvXbnDxFqgdQB7W6Oi3i6uzPNhXb4tQNI244p1WNiRTl/vuZ6pSyDH7z50MFqktyilg== X-YMail-OSG: Sm9RiUoVM1lzc_jnMiPnJRBo9d1LWAZ7yCsnEEeB5QobZ0r3SWMcnMUSBmilGxy yTyv6RIrguEeLydPJK64VSf2BvDBA7bK6j7qxyMBmfwiiRSBHydnBp4JAA8RpQjJPid3zo_8i4H7 GpmjMh5ref53PGna87kuj_paIFw0ORfaCgZ0x95rkGBYZMLQ0S1vTo49UZOrCUdMg13UhmBbyA.d AnvKgwUtGREaGl5V8EhcUBTl98IQL13UO25mH2ITtlgewaSAkOGQqmb_uXd6lqPOb83tRCPLi7Zy gjgjXJ3qAsw.xO_AHcnW1_C0evia0tK5RDuP2JDvWBzrpc92KwS6uU6w5pWLlpVYC4sw9SzEu36r 08J24URQ_pGdVuEcu0piESs_wdXTCaiRXM1KfQuFhNmP9Y.rSGQtXDOC5fMm7dKhAiyFZ6TIlmOa Q1nzHs5q_zglqVib5FRSgmrRQ..kadDDLB5HAOAZ8Cp01IsHICBYqtW6OmwqpTSr2UK4hKG9VRJe 9UqJW9f4z8A01N1FMqfSDDm_9LNAAPcd1R_DQEPScHOhPpmrE9UdIl2dlJf3HB_60J3FYyvlfW50 bOrF8zKrq38ZRQ2okvg8RwsHent7ZoMmrZdMFrdpd1TsaKerdP8yLXqQfh.to8Ue65.eWzI0E.De qJDJETHsKL.0AxXZ97Di9UItoKxj1RwRlPxNvMTF6WEX6c_02ey..U9PZxcSsQHv.v1Q6EYShMWy VRgGy1oqBHZdiRJXXKHOuOP3Am2e7Fw.juGMYsZh5Zx_maSLC6txhR25z3KBiXychUTXKfNjHPJN WPbsBLqI4m_ThfOI7sJEOomhzawp62tuPbGg78c7fFvQPbGhivOn5HpM0AQg2fz4MKALeumkh9gL SMnVcciWxsVUUlJVTtO5ItWHnHfxUDRqLZeCrgcEKw683EEKV0FUDmPYpRtSZNB_SITYE4vGskJD oIvigry0qy4Xb.jdZLy6quYsn9iYfctuPfOvYztPIJQuvtSIrdTcV6igzn_J1bq5dROmkzc6wkYb _PmHpgZwWTprG7K7UV0cCYTgRLHGkUesMqH2cNsXjp7jNj7kG0VpV3vwLMx1EEyNDgAUPhaO03yv cmgFspMTAaGdrU_0ojZ4bcocMATan1Howy0UnBmgQJXT2oSBzqs2IhIthkwsE9beCgs8masE51P. _1BSHZuiUB8xu.vsljYAIjiYXXrNDdVpTIahWjXmTDfTumiz8o9W6b9OkuWUXfkSTWSAQRLOzno. 6UXQMxMUMkiTrZ8F3V9G4Y0solgQBNPvEUex86WRgCsAI0_6Z_F1f81IPSPLnQp2VnnGeIiItApr wvtsZmzAxBDBdRd4.6SQeynYq9Vi4NkMejsC1redHfIBz868YlOfJePRQhySRC_FNwShJqqPgPyN .mRailSCnBM93HqrWgzW_JpU7aelXrZk4mSCLKYZLdFC5bJtaq_AgA0a2zKgjJZk0s3TJMB1IZM. Oxgn9x_AUKolSnb2yIcLaXxLhv4udf7iI4v2OsTN9sxDUP_UsoJJAxhc8Sq61CqU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:14:47 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b8f46c5335deea40084dc6c9857bc4a2; Sat, 05 Sep 2020 18:14:45 +0000 (UTC) To: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> <24399.58769.547600.368430@oz.mt.att.com> <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Sat, 5 Sep 2020 14:14:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8AAB93F3-6024-438E-9A32-5AE583A51C06@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 05 Sep 2020 18:14:52 -0000 Tim, > Hi, > >> On 2 Sep 2020, at 20:33, Jay Borkenhagen wrote: >> >> Steve, >> >> Stephen Kent writes: >>> The crux of the issue is whether it is preferable to reject all objects >>> at a pub point if an error is detected (until the error is rectified), >>> and thus potentially treat many more routes as having an unknown >>> verification status, or to accept bits and pieces of data from a pub >>> point with the potential that some routes will be treated as valid, even >>> if they are invalid. To me, that is a value judgement to be made by >>> network operators, not by developers of RP software. [...] >> No, there is a bit more to it than that. >> >> I want my network's routers and those of all other networks to be fed >> with VRPs that represent all the verified and legitimate published >> origin-ASN intentions of verified, legitimate IP number resource >> holders. >> >> Clearly the challenge there is in determining "verified" and >> "legitimate." In creating the rules (to be documented in >> standards-track RFCs) for those determinations, I would like the input >> of all SIDROPS participants to be valued, including the input of the >> RPKI designers, the CA- and RP-implementers, the RIRs, and the network >> operators. >> >> To my point: if RP-implementers feel that the "bits and pieces of >> data" (to use your words) should be considered to best make those >> determinations, such input should be welcomed; conversely, if >> RP-implementers feel that strict publication rules and accompanying >> strict handling of retrieved records together create the best way to >> make those determinations, we all should listen to what they have to >> say. > I don't think it's entirely fair to say that us 'developers' are willing to create security issues for network operators. > > This document is still under discussion, and there simply are still cases that are not fully discussed, e.g. how to filter VRPs if a publication point is found to be bad - to which I posted a suggestion only last week. I thought that discussion phases were meant for that. To look at things from different angles. I am quite certain though that consensus can be reached if we have constructive talks, and that implementation can follow quickly when it does. Sure. > To the point of "bits and pieces". Rejecting a full publication point is the easiest to reason about, so I can see its appeal. That said, consider the case where a ROA is invalid because it contains a prefix no longer held by the CA. Instead of rejecting the complete PP for a CA certificate, and filtering out all VRPs overlapping the resources on it, one could also reject all the invalid ROAs and only filter out VRPs that have any overlap with those ROAs. I understand this is a bit more elaborate, but not dramatically different. As far as I can tell it is just as secure in that this cannot result in RPKI invalid announcements because of a single invalid ROA object. > > Note that I talk about ROA objects that can be fetched, and are known to be current. I.e. the actual manifest content. And provided they can be parsed and validated so you know which resources are affected. If any objects are missing or obsolete then assume the worst - I actually made statements to that effect months ago. > > In any case, I can live with the reject-all model for its simplicity. But I would like to hear an operator input on whether this is indeed desirable. And that the consequence of child CAs - even NIR sized ones - blinking out for a few hours every now and then is an acceptable price for this simplicity. In revising 6486 I iterated through several versions, and received feedback that the less strict versions were not consistent with the perceived) WG consensus. That's how we arrived at the current version of the document. Simplicity is certainly a virtue wrt security, so more "elaborate" approaches to RP processing of repository data do concern me. Also, if a lot of RP software is having a hard time implementing the current set of validation procedures correctly, adding more complexity seems like a bad idea. Steve From nobody Mon Sep 7 04:17:33 2020 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 6C7053A0BEF for ; Mon, 7 Sep 2020 04:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 5miyUiS-Rsox for ; Mon, 7 Sep 2020 04:17:30 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA8E3A0BEE for ; Mon, 7 Sep 2020 04:17:29 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:fce7:462d:d025:2a3d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 09D6A26263; Mon, 7 Sep 2020 13:17:26 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599477446; bh=lDGTiTQthraqVSLFvJvfZNuuX6ZqEAQUhqhL1MhcnkU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Oexu3DDo7qPgh82orSZiPs+wOmwXdygdnTkRzVj/zbyF+1tA6svncugy7y+Jweb67 HZXJ/Xz661QtzufT6l84v7SKqTkphOj6QomAI0pIy6EkGO+K/sev0NJLqjslYMEzhS 0SEUDMnavyuVqLfVXuWXUx7fmIoAjOboM5mVSdKU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> Date: Mon, 7 Sep 2020 13:17:25 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 07 Sep 2020 11:17:31 -0000 Hi > On 5 Sep 2020, at 20:08, Stephen Kent wrote: >=20 > Tim, >> ... >> In short: Given that I expect that we are never come to a consensus = other than the total reject-all-if-one-fails - I can live with this if = we must, but don't let it come as a surprise. > Works for me. >>> ... >>> Allowing RPs to ignore object types they don't understand prevents a = CA from being able to convey the notion that a new object type is = important (to that CA). I don't think this is a good strategy. It means = that RP behavior will be ambiguous relative to new object types. >> So far none of the objects have seemed to need this flag. > If the goal is to define a very general scheme, then a flag may be = necessary to accommodate objects not yet defined, since we cannot yet = know whether a uniform response for all such objects will be = appropriate. I agree that this need not be a binary flag, as in cert = extensions. You suggested a three-value flag below, for example. >> ... >>> If we want to have a consistent and flexible approach to = accommodating new objects I suggest the strategy I mentioned earlier. = Define an additional SIA URI that points to a pub point (and manifest) = where we can introduce the next version of the signed object format, one = that includes a critical flag, analogous to X.509v3 extensions. This = allows each CA to decide which object types have to be processed by an = RP in order for the whole pub point to be accepted vs. rejected. Note = that this will require modifying a lot of RFCs, but it is a flexible, = extensible approach to this issue. >> I agree that it's flexible and extensible. I had not thought of this = approach. >>=20 >> But it is a lot of work, not just in RFCs, also in code. It also = raises questions about how and when old PPs without the new objects can = be deprecated. You can give operators more time to upgrade, but at some = point plugs will probably be pulled? Maintaining multiple PPs = indefinitely seems rather wasteful. >>=20 >> I would like to hear what others have to say.. I have the feeling = that ASPA is getting close, and I would really not like to see it = delayed because of this. > It will take a while to complete another revision of the manifest doc, = if we purse additional changes, and even longer before an RFC is = approved and published. So ASPA will not be accommodated quickly. Also, = as I noted in my reply to jay, a quick read of the ASPA doc didn't = indicate how these new objects are validated using the RPKI. https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-02#section-4 The text is still a bit short, and can probably use some feedback, but I = believe that the direction is clear. Informally: It's an RPKI signed = object, that contains a "customer" ASN which MUST be in the EE = certificate. The EE certificate MUST of course be valid. In my perception ASPA is quite close to testing (no not in the = production repositories of course). >> If we do go down this road then I think that we should also look at = the manifest object itself, and let it convey which object (types) are = critical (and while we are at it, we can specify types instead of using = filename extensions). That way future object types could introduced more = easily perhaps - this obviously needs more discussion but it could even = allow for semantics like: 1) new object please test, don't use, 2) new = objects, use if you can, 3) new objects, critical - fail if you don't = understand. >=20 > One could combine the new SIA URI and a revised manifest, in which the = manifest contains the per-object flag, rather than redefining the basic = object format to accommodate the flag. That would reduce the number of = RFCs that need to change. Good idea. Upon reflection I realised that even the introduction of an SIA in the = issuing CA certificate will lead to issues. RPs would reject the CA = certificate, and as a result the whole PP of the parent CA. This means = that the SIA cannot be deployed without leaving a significant number of = RP installations behind. E.g. if I run a delegated CA under an RIR which = wants to adopt ASPA, and I get a new CA certificate with the additional = SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be = rejected. So the only option then is to wait for a significant number of updated = RP tools to be available, and then at some point take the plunge and let = CAs deploy - and tell operators who suddenly find that their VRP count = drops to near zero that they should (have) upgrade(d). This poses a serious problem to future RFCs - I just don't see how they = can achieve an incremental deployment that does not result in the issues = above. I understand your desire to keep 6486bis focused - and I sympathise. = However, I do believe that it needs to specify some plan. Perhaps an SIA = can be reserved? Perhaps it can be published in conjunction with ASPA - = timelines permitting - postponing the pain? Perhaps just checking the = presence and hashes for unknown object types, but not validating them = can be reconsidered? (I heard your objections, just listing it again in = this context) I am quite open to other suggestions. But, if there can be no plan that = facilitates future RFC deployments, then I believe that at the very = least the document should include a section that discusses this issue = (perhaps security considerations, or a separate section altogether). > Your example bothers me a bit- it seems to argue for CA-directed = processing flags, perhaps to accommodate experimentation with new object = types. This sounds like adopting elements of the IRR DB model which = didn't seem to be so great, IMHO. Not where I meant to go, but this can be a future discussion. Tim >=20 > Separately, I think we need to make GBR mandatory for all pub points. = If the intent is to cause RPs to contact a CA/pub point maintainer when = errors are encountered, then we need to be confident that RPs know who = to contact and how. >=20 > Steve From nobody Mon Sep 7 05:42:56 2020 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 8E87D3A0CA2 for ; Mon, 7 Sep 2020 05:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 SBLs1CM_ssIH for ; Mon, 7 Sep 2020 05:42:54 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479D43A0CA1 for ; Mon, 7 Sep 2020 05:42:54 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:fce7:462d:d025:2a3d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 768DF26399; Mon, 7 Sep 2020 14:42:51 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599482571; bh=NXY3GdtHi2333PlFM6U5CiJbMzEuwDEWfRPl5C9Oxtc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jf8tYePVjYLmxfz08KDzVAa6tRqOZy6tYeggT/Uz2Kxn1kGYvEYjnOpfXa/8rfY4O MdlSIdPq0kUdGItOl6jD/j/eLXe6m0cq79fTOSuQMPArYvAHIUziJrZW0pTpbUmRZ0 C90QucUsfcKj3bjs/84JUMXtOu6i6HGQ1iQScLuE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 7 Sep 2020 14:42:51 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> <47B41A31-D557-46E1-9EE7-56352C604224@nlnetlabs.nl> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt 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, 07 Sep 2020 12:42:56 -0000 Hi, > On 4 Sep 2020, at 22:34, Russ Housley wrote: >=20 > Tim: >=20 >>> I think that RFC 6487 should also be updated to adjust the RPKI = certificate profile. >>=20 >> Can you please elaborate why? >>=20 >> My personal drive with this draft, despite its name perhaps, is to = deprecate the *operational* dependency on rsync. In my opinion the rsync = URIs can stay and serve as namespaces, even if the servers are not = guaranteed to be available. Think XML name spaces. I don't think we need = to forbid running rsyncd either. >=20 > For example, RFC 6487, Section 4.8.6 says: >=20 > ... The preferred URI access mechanism is a single rsync > URI ("rsync://") [RFC5781] that references a single inclusive CRL = for > each issuer. >=20 > ... Other access form URIs MAY be used in addition to the > rsync URI, representing alternate access mechanisms for this CRL. >=20 > There are similar words in Sections 4.8.7, 4.8.8.1, and 4.8.8.2. >=20 > It seem to me you are changing the "preferred" way to handle these, = even if both are allowed for decades. Right, thank you for this pointer! I think I have misremembered some of what RFC 6487 said. It seems that = even though only 'rsync' is used to today for the CRL DP, SIA and AIA - = other access mechanisms are explicitly allowed. I would not feel safe about including https in there today without some = proper field testing, but it seems that updating this may indeed be less = problematic than I thought. It would still leave questions around = certificate provisioning (6492) and publication (8181). I need to think = about this a bit. Tim >=20 >>=20 >>> In phase 1, several URLs in the certificate could offer rsync:// and = rrdp://, and then in Phase 4 (not documented), the rsync:// can get = dropped. >>=20 >> It may not be aesthetically pleasing, but removing the rsync URIs = completely is a much, much bigger effort. Incomplete dump of pointers of = what would be affected >=20 > I agree, and that it is why I called it Phase 4, which is beyond the = scope of this document. >=20 > Russ From nobody Tue Sep 8 09:51:33 2020 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 B9E183A14DC for ; Tue, 8 Sep 2020 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.20150623.gappssmtp.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 V3iYyldJmEpO for ; Tue, 8 Sep 2020 09:51:23 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 AB20C3A1465 for ; Tue, 8 Sep 2020 09:51:03 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id z19so9282552pfn.8 for ; Tue, 08 Sep 2020 09:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QW8UDYPqJv1bhABAgGI8DX/4FuaVY+W2S4yqkTKMcVI=; b=veapzO9EQZlrNKqLuQwcvrep6QShj2JshkfXbWfkxnbk8V1TS+vShUQJ1kG1NqOJgN e0EQPTLyVUHH+ys3z10jRv3QsZkhmeCt1T1iIADn1650SzHyzwhPET+kK3fO7PggcLNG BLEg6le6+H8wS41WqK3CNbcbUqxvhXFZZ6S9/Ukm7ZFeoPgjfogYmRgTpFZwYzA8lDaI I8Mj/A8UgCJXXyUIUz3dDw9MUUblMA2eNDUPI1qd5fL79n2EZ9USN98qFVs6jpXvYGyn v+zvnBJT25cPcF2Au6WJP8+679SdLaC7b8sLxFI9+BmXSx8lCSBR1cscMNObTjC+wJa1 2Z2g== 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=QW8UDYPqJv1bhABAgGI8DX/4FuaVY+W2S4yqkTKMcVI=; b=nfgUytcNkGRYbyTfyeY+yEFk0RvDzwSJ/9nOVbixwmdgKgPVnOXdKLgVNUDNTcoFxw V0gKlk7qEl6GJNDGvbQG9q4lTnedeC4ORqsHvrhKgnmFfIHrBjy8cdY+KtD/nWgWpLcN d+2B/fQTDtx2phs2qtI/2QzyrDw+O2ShdjUrF6pOuJXXfuIMmyFGTARzCiHZLFW0i2i0 BGQ+KSP3FwjKlNPoT8KGq6Wgb7IEUOUIbCVxc3D5ChTU8TB4zmaasEpl+ZemZ4/o5B3z xGZR2Jt1Oux4eeAhglxg1RDSMAclZJNUULrVlkweZK700qoc8nYBSr6Q+2vcDJiNEZt5 lS0g== X-Gm-Message-State: AOAM532EeUmwF/gQ7YXgd1HKDRcArRlIlf+tf/t2yKVSsMp0SLCCvXs9 OCI4idiewYSiOr8DeP0e5Bo2KEQS00nNdI+rEyRxiA== X-Google-Smtp-Source: ABdhPJz3UmPyt/oIfQxzUxbNQLzMhdPSalusSk6GZdQKkLSdILBsL3cC5a8ENS7rtupqv2Hs6AK2+iil5o9TXFwFVkE= X-Received: by 2002:a63:c10:: with SMTP id b16mr20380407pgl.240.1599583863265; Tue, 08 Sep 2020 09:51:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Melchior Aelmans Date: Tue, 8 Sep 2020 18:50:52 +0200 Message-ID: To: Di Ma Cc: SIDROps Chairs , Chris Morrow , Keyur Patel , SIDR Operations WG , Nathalie Trenaman Content-Type: multipart/alternative; boundary="000000000000f56ea305aed0236e" Archived-At: Subject: Re: [Sidrops] Adoption request of draft-madi-sidrops-rush-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 16:51:32 -0000 --000000000000f56ea305aed0236e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chairs, Any word on the ask below? The authors are curious to hear what you think ;= ) Thanks and cheers, Melchior On Sat, Aug 29, 2020 at 12:27 PM Di Ma wrote: > Chairs, > > We authors just update draft-madi-sidrops-rush into v2 re Randy and Job= =E2=80=99s > concern raised in last IETF SIDROPS meeting. > > This version articulates in Security Consideration that : > > "RUSH is designed to carry out RPKI cache data update from one to another= , > with out-of-band trust established between those cache servers. That is, > the scope of RUSH usage is convergent. Cache subscription management migh= t > be employed to implement cache identification and verification. " > > Please consider this mail as the formal request of adoption of > draft-madi-sidrops-rush-02 as WG item. > > Thanks. > > Di > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000f56ea305aed0236e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chairs,

Any word on the a= sk below? The authors are curious to hear what you think ;)

T= hanks and cheers,
Melchior

On Sat, Aug 29, 2020 at 12:27 PM Di Ma = <madi@rpstir.net> wrote:
Chairs,

We authors just update draft-madi-sidrops-rush into v2 re Randy and Job=E2= =80=99s concern raised in last IETF SIDROPS meeting.

This version articulates in Security Consideration that :

"RUSH is designed to carry out RPKI cache data update from one to anot= her, with out-of-band trust established between those cache servers.=C2=A0 = That is, the scope of RUSH usage is convergent. Cache subscription manageme= nt might be employed to implement cache identification and verification. &q= uot;

Please consider this mail as the formal request of adoption of draft-madi-s= idrops-rush-02 as WG item.

Thanks.

Di
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000f56ea305aed0236e-- From nobody Thu Sep 10 00:31:30 2020 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 1AC4F3A0FA1; Thu, 10 Sep 2020 00:31:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <159972308503.21770.7896442802667471744@ietfa.amsl.com> Date: Thu, 10 Sep 2020 00:31:25 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-03.txt 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: Thu, 10 Sep 2020 07:31:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : A Profile for Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Uskov Randy Bush Keyur Patel Job Snijders Russ Housley Filename : draft-ietf-sidrops-aspa-profile-03.txt Pages : 9 Date : 2020-09-10 Abstract: This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized members of Provider set to be its upstream providers and for the Providers to send prefixes received from the Customer Autonomous System in all directions including providers and peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-profile-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 10 00:34:30 2020 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 453963A0F94; Thu, 10 Sep 2020 00:34:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <159972326525.22616.9386098751105952524@ietfa.amsl.com> Date: Thu, 10 Sep 2020 00:34:25 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-05.txt 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: Thu, 10 Sep 2020 07:34:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-05.txt Pages : 12 Date : 2020-09-10 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 10 10:27:46 2020 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 E10EF3A0E29 for ; Thu, 10 Sep 2020 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 dC0l0TuhprFp for ; Thu, 10 Sep 2020 10:27:41 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2041.outbound.protection.outlook.com [40.107.220.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D23C3A0E47 for ; Thu, 10 Sep 2020 10:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=knTWBmkzsAH9lUTmp+bL5ii5PCXnu8yKNepWhvxS/kkQppHd6+UKGGEsK8YKvVvOJZcrVoPzHIUXaTD5hiHky239vAxf8JHN5z2hq/WrL1Lzsz0paqF2p+wubwEH4BC/YXlmuAW5noNIH7vcRTiM8qQEO6J75VyPs/N6Lb4o1mdr1LrCiIs2g8ZvpcYmny51Pv9B7hpQ2r4pn8Zwd+pxSixIKyiurbyLihrEAUq7fT6swSw+ME0jXwGL1AcanPxkxfGe14JBW8eWSsdkBtlwiENKkpd1WZtdRGt2tD9BmAybQirUPKMRgNv9TJWDvs4jplevsOl0RxHj6ZKMpZE+Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCoPa1rZq10oO5t7h87qOe0tVrwGum8nr3Heooc+uW4=; b=ng52KZcEa5FctyuLsWVzykHo/kTgxzRCKnKvRK2Ln2NGIyqc1ZVvHZKbEWr0NkGQl4LNDvnmHE11YckTojUtWiUIeAo0wogoZwuZeFmWK3/lxQRT37rPYT08NiNq1Q8QIFC7AfVEboBrlS3IviJqm6pxvE9G/YZ3qnqK0ZZbkMTQ5qrmeO6kr8OJui7eHsNy5eNu8itlIrARjGGkaoPJUneWXdNDtmyHQsyh+KQQSX6dnTIgJdmrq3FvwCLK+vGZ2hdKVNtACXduz94R170jMM5gLb7zwUr4phtWFADTAES4p0lpEO9ZbtGVG7a8slprYQqcPzM89MUaPeqbaaWefQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCoPa1rZq10oO5t7h87qOe0tVrwGum8nr3Heooc+uW4=; b=t3VCNya2TDY6ATtU8D/23vn8Z1WHzshaZA6Cw3VAPdvuceRjOm7VFFLFN62EqPtZrZmZey4/vkkWyPTrNaN07bCy703qWA3dfnlzAzr/WV/U9JB+Ed4PzhV8CQ9mhoYFp96gALAiqaaexf4i3pxUUDKwi8wg79T14X023CgN4TY= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3393.namprd18.prod.outlook.com (2603:10b6:a03:1a5::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Thu, 10 Sep 2020 17:27:35 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d%7]) with mapi id 15.20.3370.016; Thu, 10 Sep 2020 17:27:35 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtuQ== Date: Thu, 10 Sep 2020 17:27:34 +0000 Message-ID: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4c32613-0636-4c34-b973-08d855aece9b x-ms-traffictypediagnostic: BY5PR18MB3393: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y3iyOZwbBJJSY08LVMAL7MR1G+NlejBU9AiqGhYonn00w9jvp2QLS3dm+ICLYHmfuLpl69pFInFoCG/BMkaCrkWDNZ3jq62rOV8Z4QpODCLaT+UrFhbpSU6ItuiUgz2JXOV/sWNniyw3o4iXU19gXmibYUALABl1bFRq6iZfpjeRu2PUE+jTVz82a1FTjwAtj4T3c76zOv5Az7E2ffKri1/STBbJTue/SMOgmpokg4gx7RNnjWxDhCO8vOuDqRqu+z8ihORP8zGQ2zV+ZrFI/a38TlTgK304Z9dtQy/bCfFoqR3Z49lSXnG3d4ZOK2fHWEeJu+HJ5B9ntM2kr4ZU9zN2NYXedti+ZMQzqg204ZEYFLEQSdTPFwKRaKBm2Tdx5CL0q6Pg/toCVoNTAK0Yqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(136003)(396003)(39830400003)(6486002)(2906002)(6506007)(6512007)(36756003)(83380400001)(316002)(8676002)(6916009)(53546011)(8936002)(9326002)(966005)(166002)(66476007)(33656002)(76116006)(2616005)(4744005)(64756008)(66446008)(66946007)(186003)(26005)(71200400001)(478600001)(5660300002)(86362001)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EAsEFmQu/M37WD7m09XVMwQRHjuXqByeo9i81+65qXFnWh8eJVtFy87Z+sMDMofIHduMOwknwXtUyvoiEpAZV49iNiPXGPRfgkrl5Q74riVs+xxV1cBHFgzT7xMLFf2eVKE1YjHTYHP4xm0aBDN/fH4s8BiDSIsrvzk8vcjH7CwV5ctdCoibTBIOO3UOfArJxHyX0tHyoMaClwKusO0SnP2JJ8JQtoEk0mU5YgXY4KUz076c3qi47XVkHrPs4HeiXPS4zcJo1b0C8HzRJoy+1m+yOIQtoGT7MFcbZNbqeqCHK2x4lAIb4LwRhy2jozie9253Ch24pILynxH+jEPqFchsKLd+SpsmXy+skbk3dzfC6gWeQEzW45PTJWcj38RRAXlmi2dT/UyChwnOc/878FfrSMNBSe6dh4h7B9GrNnlmugbcvV0FuA6Hb54vy/SAgZ5+edNSFPQdv0/2yTnX5WmZxzMdIBcAv2LwhbAoNsiBN3ljM+60wTPZPqz73zTJvpW0Kba8U9b1SDRlscZPvTkv2JRcHqwVJyoLoaDLZpwvbtw1LW6IhXgsYJaWBGePO7K/PNONbUDRN9jqdZveSlbueeVMfsH8CNNj5CVzPBrYIuzE4ysdAd1SdEoUDWdo0R4qpr0+JxoU+t9MBgeZTQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_08ACF86D6B134D7CADD908227931C107arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4c32613-0636-4c34-b973-08d855aece9b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2020 17:27:34.9649 (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: 6LWOlkzjcDZDZfqSAdr7I0zdBnQY558gxHIlUfC2VohsXveLkkF9+0gZ4kEK4tsFID9EN80VodEAf5Uyr47ugw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3393 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 10 Sep 2020 17:27:44 -0000 --_000_08ACF86D6B134D7CADD908227931C107arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQgdGhlIGNhbGwgZm9yIGEgd2VlayBp biBob3BlcyB0aGF0IHdlIHdvdWxkIGhhdmUgYSBjb25zZW5zdXMuIFNlZW1zIGxpa2UgbW9yZSBk aXNjdXNzaW9uIGlzIG5lZWRlZCBhbmQgc28gd2UgcGxhbiBleHRlbmQgdGhlIGNhbGwgZm9yIDEg bW9yZSB3ZWVrLiBUaGUgV0dMQyB3aWxsIG5vdyBlbmQgb24gU2VwdGVtYmVyIDE3LCAyMDIwDQoN CkJlc3QgUmVnYXJkcywNCktleXVyDQoNCkZyb206IEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMu Y29tPg0KRGF0ZTogVHVlc2RheSwgQXVndXN0IDExLCAyMDIwIGF0IDExOjQ1IEFNDQpUbzogInNp ZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogW1dHTENdIGRyYWZ0 LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIC0gZW5kcyAyNS9BdWd1c3Qv MjAyMA0KDQpIaSBGb2xrczoNCg0KQSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiBy ZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAz LCDigJxCR1BzZWMgVmFsaWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBsZWFzZSByZXBseSB0 byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIEF1Z3Vz dCAyNSwgMjAyMC4NCg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0w My4gIEF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJl IG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuDQoNClJlZ2Fy ZHMsDQpLZXl1cg0KDQo= --_000_08ACF86D6B134D7CADD908227931C107arrcuscom_ 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 YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIEZvbGtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHdnIGNoYWlycyBleHRlbmRl ZCB0aGUgY2FsbCBmb3IgYSB3ZWVrIGluIGhvcGVzIHRoYXQgd2Ugd291bGQgaGF2ZSBhIGNvbnNl bnN1cy4gU2VlbXMgbGlrZSBtb3JlIGRpc2N1c3Npb24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFu IGV4dGVuZCB0aGUgY2FsbCBmb3IgMSBtb3JlIHdlZWsuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj53aWxsIG5vdyBlbmQgb24gU2VwdGVtYmVyIDE3LCAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+S2V5dXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXIgUGF0ZWwgJmx0O2tl eXVyQGFycmN1cy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEF1Z3VzdCAxMSwg MjAyMCBhdCAxMTo0NSBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2lkcm9wc0BpZXRmLm9yZyZx dW90OyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1dHTENd IGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIC0gZW5kcyAyNS9B dWd1c3QvMjAyMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRv Oy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0 ZWQgZm9yIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzLCDigJxC R1BzZWMgVmFsaWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBsZWFzZSByZXBseSB0byB0aGUg bGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPndpbGwNCiBlbmQgb24gQXVndXN0IDI1LCAyMDIwLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtv cnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBkcmFmdCBjYW4gYmUgZm91 bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJn cHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyIgdGl0bGU9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24t c2lnbmFsaW5nLTAzPC9hPjwvc3Bhbj4uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkF1dGhvcnMsIHBsZWFzZSByZXBseSBp bmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBo YXNuJ3QgYmVlbiBkaXNjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXI8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_08ACF86D6B134D7CADD908227931C107arrcuscom_-- From nobody Thu Sep 10 19:48:14 2020 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 6A5A73A0AC3; Thu, 10 Sep 2020 19:48:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159979249233.8768.13825707144576111685@ietfa.amsl.com> Date: Thu, 10 Sep 2020 19:48:12 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 109 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, 11 Sep 2020 02:48:13 -0000 A new meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: idr, rtgwg,grow Technology Overlap: opsec Key Participant Conflict: dnsop People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Sep 10 20:16:37 2020 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 227933A0AB1; Thu, 10 Sep 2020 20:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 j0pmXgf5ZdDa; Thu, 10 Sep 2020 20:16:35 -0700 (PDT) Received: from relay.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51303A0AFA; Thu, 10 Sep 2020 20:16:34 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 2A73A3C1ED8; Fri, 11 Sep 2020 03:16:33 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id D12E62A; Fri, 11 Sep 2020 03:16:32 +0000 (UTC) Date: Fri, 11 Sep 2020 03:16:32 +0000 Message-ID: <87sgbpknov.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-ads@ietf.org, sidrops-chairs@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] Interim Meeting Scheduled - 10/01/2020 - 10am ET / 7am PT / 0am SYD / 10pm HKG 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, 11 Sep 2020 03:16:36 -0000 Howdy folks, We'd like to have a meeting before the next face-to-face meeting to sort out: (in no particular order) o 6486bis work o onlist discussions / methods Ideally these are able to progress to reason in the 2 hours alotted. If there are other topics we can discussion them after these 2 topics are sorted. See you all there (virtually, I mean). Thanks! -chris co-chair persona From nobody Fri Sep 11 07:07:58 2020 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 25CED3A09C5 for ; Fri, 11 Sep 2020 07:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 ogtPvB5-5yRd for ; Fri, 11 Sep 2020 07:07:54 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 7F5323A0414 for ; Fri, 11 Sep 2020 07:07:54 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id f11so5254463qvw.3 for ; Fri, 11 Sep 2020 07:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=Eo5nPELk5S24WQQkeIPyHjp+YT1DeApTNL2exbxRRh8=; b=G3SuiaPrJh0IDzsWY8Vv7Hl7RAqIr4QBegZO1hQWKuyKGEGagAh4DhnZoVmHoeYeT3 7FphKQaV9wl+kPWEKibdMDUF8ebjboYi8MHsxP7AYzn1y6Tuf1D2+QEbQGLsxV8jOXwR mOiBphuyvLE0EqK5XZsf9+OfBQhDbUVMeyS3JWHJaAmzDXZct3U7SELQhSkVpk+ehKXs va+mVPHYDgNpjy4yjT0AtihnbqzNxDzHoOLxNDRtldhvZUVoiOCx2+XjKHRF0xuSypGY cYeWOtxcrmfXktH6AzXG3omb8C4wiIj0RGLX2SKAPp6cGMgMSZ9qjCANbN4HHgtV66gO LQqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=Eo5nPELk5S24WQQkeIPyHjp+YT1DeApTNL2exbxRRh8=; b=f2KvFBito6VPVlHGT1+YGcHNfx7qmkLP0OvGJb5RY0rvbh7HqzEWT6vE8eyuB8F+4q klCgv94hNwPulyoTqjddMGkJgv/1B6RVlkpvrk9bM+2RC2Zwh5R5EPM/ldKEA7f1/9BV alZ1/yeL5vPrPi8cdGD/7Azwup2NEGpKpjf20pQZ3Ar0Qml0kQmrqXHY0gxvF1syvGgx 2BznEHI2wxS1VmDz6n7/ALrdztcjnlTYe8gEcc8t+JdiNrbKQpvGBsDNM+UlP4QH92ZX oH7Q8SJ1ocpew3vvnRAfiJSGTHE9BeB80CES4gLUqVhKQ4hh+ob67Aug1zJU3pFT/HQ5 lnPA== X-Gm-Message-State: AOAM531PCwhNWttl+kOLkfoBstKqLIBM03CXljGBb2PgRyKE9PCu71eJ FWlxrgmkqMnue3UwEQ3O81J20oLkYTM= X-Google-Smtp-Source: ABdhPJw4t8Buc/kqWqFeGD/23kSNg8A8IkG9R3zEemI+ICQ7DWb20y2MZCLZsgVnlzNwCRtPY5agVQ== X-Received: by 2002:a0c:f48e:: with SMTP id i14mr2109460qvm.5.1599833273347; Fri, 11 Sep 2020 07:07:53 -0700 (PDT) Received: from [200.10.62.148] ([2001:13c7:7001:2128:8c1b:986d:699e:5eeb]) by smtp.gmail.com with ESMTPSA id z29sm2765948qtj.79.2020.09.11.07.07.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2020 07:07:51 -0700 (PDT) From: "Carlos M. Martinez" To: "Chris Morrow" Cc: sidrops@ietf.org Date: Fri, 11 Sep 2020 11:07:49 -0300 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <9ABF5434-91D5-47D5-9CEB-454374DB931C@gmail.com> In-Reply-To: <87sgbpknov.wl-morrowc@ops-netman.net> References: <87sgbpknov.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Sidrops] Interim Meeting Scheduled - 10/01/2020 - 10am ET / 7am PT / 0am SYD / 10pm HKG 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, 11 Sep 2020 14:07:56 -0000 Hi Chris, I understand these times are 14.00 UTC , correct ? /Carlos On 11 Sep 2020, at 0:16, Chris Morrow wrote: > Howdy folks, > We'd like to have a meeting before the next face-to-face meeting > to sort out: (in no particular order) > o 6486bis work > o onlist discussions / methods > > Ideally these are able to progress to reason in the 2 hours alotted. > If there are other topics we can discussion them after these 2 topics > are sorted. > > See you all there (virtually, I mean). > > Thanks! > -chris > co-chair persona > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Sep 11 08:36:22 2020 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 642273A1262 for ; Fri, 11 Sep 2020 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 uobdyfCGKoqB for ; Fri, 11 Sep 2020 08:36:20 -0700 (PDT) Received: from relay.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5AF3A125F for ; Fri, 11 Sep 2020 08:36:19 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 77E6A3C2217; Fri, 11 Sep 2020 15:36:17 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 5207A2A; Fri, 11 Sep 2020 15:36:17 +0000 (UTC) Date: Fri, 11 Sep 2020 15:36:17 +0000 Message-ID: <87r1r8l40e.wl-morrowc@ops-netman.net> From: Chris Morrow To: "Carlos M. Martinez" Cc: "Chris Morrow" , sidrops@ietf.org In-Reply-To: <9ABF5434-91D5-47D5-9CEB-454374DB931C@gmail.com> References: <87sgbpknov.wl-morrowc@ops-netman.net> <9ABF5434-91D5-47D5-9CEB-454374DB931C@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Interim Meeting Scheduled - 10/01/2020 - 10am ET / 7am PT / 0am SYD / 10pm HKG 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, 11 Sep 2020 15:36:21 -0000 On Fri, 11 Sep 2020 14:07:49 +0000, "Carlos M. Martinez" wrote: > > Hi Chris, > > I understand these times are 14.00 UTC , correct ? that would have been simpler for me to write, yes. :) > > /Carlos > > On 11 Sep 2020, at 0:16, Chris Morrow wrote: > > > Howdy folks, > > We'd like to have a meeting before the next face-to-face meeting > > to sort out: (in no particular order) > > o 6486bis work > > o onlist discussions / methods > > > > Ideally these are able to progress to reason in the 2 hours alotted. > > If there are other topics we can discussion them after these 2 topics > > are sorted. > > > > See you all there (virtually, I mean). > > > > Thanks! > > -chris > > co-chair persona > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Sep 11 09:13:05 2020 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 3865F3A1300; Fri, 11 Sep 2020 09:13:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: morrowc@ops-netman.net, sidrops@ietf.org, warren@kumari.net, sidrops-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159984078276.4548.14560390413931677351@ietfa.amsl.com> Date: Fri, 11 Sep 2020 09:13:03 -0700 Archived-At: Subject: [Sidrops] sidrops - Update to a Meeting Session Request for IETF 109 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, 11 Sep 2020 16:13:03 -0000 An update to a meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: idr rtgwg grow Technology Overlap: opsec, rtgarea Key Participant Conflict: dnsop People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 11 09:25:34 2020 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 3D11B3A0C69; Fri, 11 Sep 2020 09:25:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159984152899.3982.11580485791279965055@ietfa.amsl.com> Date: Fri, 11 Sep 2020 09:25:29 -0700 Archived-At: Subject: [Sidrops] SIDR Operations (sidrops) WG Virtual Meeting: 2020-10-01 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, 11 Sep 2020 16:25:29 -0000 The SIDR Operations (sidrops) WG will hold a virtual interim meeting on 2020-10-01 from 10:00 to 12:00 America/New_York (14:00 to 16:00 UTC). Agenda: o Discuss pending 6486bis document dicussions Information about remote participation: Meetecho if possible, else webex? From nobody Mon Sep 21 13:42:48 2020 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 A20023A09A8 for ; Mon, 21 Sep 2020 13:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVoTDbBwSmuh for ; Mon, 21 Sep 2020 13:42:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F353A09A4 for ; Mon, 21 Sep 2020 13:42:45 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 08LKgdjA068415 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2020 21:42:39 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: "sidrops@ietf.org" Cc: Keyur Patel References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> From: Nick Hilliard Message-ID: Date: Mon, 21 Sep 2020 21:42:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.30 MIME-Version: 1.0 In-Reply-To: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 21 Sep 2020 20:42:48 -0000 Keyur Patel wrote on 10/09/2020 18:27: > The wg chairs extended the call for a week in hopes that we would have a > consensus. Seems like more discussion is needed and so we plan extend > the call for 1 more week. TheWGLCwill now end on September 17, 2020 this comment is coming a bit late in the day, but I think it would be an idea to clarify the behaviour of the receiving bgp side a little better. > A receiving BGPsec enabled router SHOULD use the received BGPsec path > validation state in situations where a locally computed BGPsec > validation result is not currently available. In the absence of the > extended community, the receiving BGPsec enabled router MUST NOT make > any assumption about the validation sate of the UPDATE. The second sentence is a no-op, so it would probably be better to remove it. The draft intends that the bgp receiver treats routes with this extcomm as if they were locally validated by bgpsec. The simplified state outcome is: 1. the receiving bgp implementation has bgpsec enabled, and has computed a local validation result for the incoming prefix 2. the receiving bgp implementation supports bgpsec, but has not computed a local validation result for the incoming prefix 3. the receiving bgp implementation does not support bgpsec. At the moment, the text deals with case #2. Probably what you want to do here is state that local validation takes preference over the community value. Here's some suggested text as a replacement for the paragraph above, which deals with #1 and #2: > A receiving BGPsec enabled router SHOULD use the received BGPsec path > validation state in situations where a locally computed BGPsec > validation result is not currently available. If a locally computed BGPsec > validation result is available, then the received BGPsec path validation > state MUST be ignored. I'm not sure what you intend with state #3. The choices here are: SHOULD implement alternative policy handling mechanism, SHOULD NOT implement alternative policy handling mechanism, or no advice. Some of this behaviour could be synthesised using normal policy hooks in the bgp stack's configuration grammar, but that would need coding and could be messy if there were ever future plans to support bgpsec because then there would be two frameworks, probably incompatible with each other. It would certainly be easier for implementers to state that the draft is not intended for bgp stacks which don't already implement bgpsec. Do the authors have any thoughts on this one? Nick From nobody Mon Sep 21 13:56:59 2020 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 D6C273A09C4 for ; Mon, 21 Sep 2020 13:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 D47pA27inekp for ; Mon, 21 Sep 2020 13:56:57 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043B63A003F for ; Mon, 21 Sep 2020 13:56:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YFTsB1S1sjwCare/2NtCkGm1YlEhPK/uiKJ/nQvoe+aUL2oB4s1eVhrxWyR22ztO+R2WmWTFMZGZeRQTGFEpKmQYn/DIeEhC+oAOaWNz/zp99CldzH/UZni404Z5hDJj5EtKQA+HYcnB8/likAmImYRH9QK/nQ9K5KeTGwSdksKNIQT38WB4IYOFfHiiW8oTMkl9doX2mxIu+IspCbZZ61RECyb85fZI5PGpCjaVHQMtnradKmRqcZkjjatiUC4COcj4D7BPW5bbdsRz6bnl7ukJvCqbUo+re0kbHDRnBZfi4ZeHPsJV854W8WMWbmYYhjwooFWsybQoPzAYGKdoxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fDPivKR81vER+tLhjT/y0Smwx3Ct1cqdZZWzh3gOW4w=; b=dQg2DivQQY3P8ueC5eXwz7IPsWYJSMPgNS64riGyxFXjvtxlvcrMJEDlxIwGm6MTqppzwXe+SXFS585a3cN4WdwKyxycuwnL7qy/LutS9h+MMu+SaJIQ5PhXrEmlAC+XlFcGqdBLJ7q8l3wTU3jBT/CiSTnktJUdwNeaZC32MoyL2Iy5/FKRFwZpKtloC8CuOj1nS1wa/AUEXC0NDN0g4Ka8XmVPg5hQM3Aka2a8P9VFNRcPQTcLxMdAgtIZV5N0I2EYs30j/uj2fyCDu3pzjoSs6OzstNmUdFKkOujMfqD+708X+0h41OjU5eLV9CGNzfJky/1rY9atyQFttYWi7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fDPivKR81vER+tLhjT/y0Smwx3Ct1cqdZZWzh3gOW4w=; b=E21L0d6Cvac0VJ6tj5SxeAa+fCFaTXfA89wsQ+6abu2WPCaxRTdIFEI8PsVF8voBoigqef0Cv86AtZ5vlcQHR/2gl9AVj2QbTkl95IlMoG18gHXLEm6VAS4jxYEifYKVwOZ15unkadyqJF12v1auQGQoknDbagymTvH2A72zszM= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3299.namprd18.prod.outlook.com (2603:10b6:a03:1ac::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Mon, 21 Sep 2020 20:56:55 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d%7]) with mapi id 15.20.3391.011; Mon, 21 Sep 2020 20:56:55 +0000 From: Keyur Patel To: Nick Hilliard , "sidrops@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtualzoEwA//+OpAA= Date: Mon, 21 Sep 2020 20:56:55 +0000 Message-ID: <9D08DEE0-F651-49C1-8BAA-82ACDFC932BD@arrcus.com> References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53b4af09-f574-46b3-5a87-08d85e70df89 x-ms-traffictypediagnostic: BY5PR18MB3299: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WUWJwSCoO63/18uVRKoDpQlYIqrQAKBULoVwM3xdAsLRkv8d55vUmTbnktTJg0Q1nAw5LYvRQUIOMDOe87l9iCp6TNKc+BTh5zGl5Yj2oLkWjrw6ECHxdVmPQXHyX4qEbwPQxY7YWYp0tFLcfbZ0VeDSaggmtxz6LfjD46iXPS3wvq9nExF9V/4dD7urP4JEHNT9kLTvPhfeRHcuXkFI5jKbGyohNBF4AqI5QSPLRq1SXWzTNwNVrYPrtnGR0A058xOzZkGzf0m80rVjDiSKWmpXxkHC4Ya4rdTeW/f+T2VM0RqMwiX4osKCowMzQXbCgJ6MsJBZYwdzMPCMHUJMuVzo6qwZKdFAv+h9+++eb4MHcdJOmlaj/KSIhU3v5RqY x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(376002)(136003)(39830400003)(110136005)(71200400001)(2906002)(36756003)(2616005)(26005)(316002)(66446008)(5660300002)(86362001)(8936002)(186003)(8676002)(66476007)(478600001)(6486002)(83380400001)(66574015)(33656002)(66946007)(6506007)(76116006)(64756008)(66556008)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2tCflDjqadAnATgd8OIPwwY/2XKd0DTX+DIpOucI/cjChkHatA63IMs3SrPvHaDDyzsjmld8Me/qeteleh7ynNzew2dfRDlHWSf2GoYJrx2MTGxkZH1fD+issi0+cZF1TTzysBbA/AOO28Ar/Il+hCA6bPqHLILHjI0B8gLoJ4TrUGdFDIDmyEExnwtfoZk3bTSi0k/pOWDIKlkkEojQ4hTsha+/7WvA5LB32711rrN2NG7SsHhKsTSFC83jLMMfMY56P8gAAau0h/FN/htlPCK08drGT21JvxbbuP8/1P5PvfVd5qM6dFxhgofJOrnfqdTjjEuC3SCgU+kGjtgIlsHuqGxpFdThGlgcY0F8XzHYe7j6VrEaazabA2M2LaIefLlGW+bPZMzzOXmjfc764IFNw19ivw//Jg3gQ95BnhTBYfi8Ub9BWQFH7Q1rV0hSTvoq32S68gzHKxMGjbpK6r1pL/sUVmqfXuUkJmOtwh9hhhBno7H7cYtXyOOpfSymvaGI8PGpqLRYjHyQ+QWa8Kknpog7YfXP6Bf5sx9MSjU5zLrO7yIHiH0Y1U5P4aLzSPHsapcQnWEJQ6ZD/EVCy5fehn6krQoKdJyq7loKJk0sFKOswpMw1Zjh4FyWzPNN+TVx2Ha8rDpYoEn3X8ATIQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <34F6A5EB760D1C4BB9BD71C91AB2BA8E@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53b4af09-f574-46b3-5a87-08d85e70df89 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 20:56:55.1564 (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: YJEXLeQoDJ2DHmS670WjpNRSiGR3Pk/OeFWEi7G45TdXi1utW95V9HWdKAjuZkgTMxkUnhRXPmsIjLwhf2m9TA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3299 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 21 Sep 2020 20:56:59 -0000 VGhhbmtzIGZvciB0aGUgY29tbWVudHMvY2xhcmlmaWNhdGlvbnMgTmljay4gX18NCg0K77u/T24g OS8yMS8yMCwgMTo0MiBQTSwgIk5pY2sgSGlsbGlhcmQiIDxuaWNrQGZvb2Jhci5vcmc+IHdyb3Rl Og0KDQogICAgS2V5dXIgUGF0ZWwgd3JvdGUgb24gMTAvMDkvMjAyMCAxODoyNzoNCiAgICA+IFRo ZSB3ZyBjaGFpcnMgZXh0ZW5kZWQgdGhlIGNhbGwgZm9yIGEgd2VlayBpbiBob3BlcyB0aGF0IHdl IHdvdWxkIGhhdmUgYSANCiAgICA+IGNvbnNlbnN1cy4gU2VlbXMgbGlrZSBtb3JlIGRpc2N1c3Np b24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFuIGV4dGVuZCANCiAgICA+IHRoZSBjYWxsIGZvciAx IG1vcmUgd2Vlay4gVGhlV0dMQ3dpbGwgbm93IGVuZCBvbiBTZXB0ZW1iZXIgMTcsIDIwMjANCg0K ICAgIHRoaXMgY29tbWVudCBpcyBjb21pbmcgYSBiaXQgbGF0ZSBpbiB0aGUgZGF5LCBidXQgSSB0 aGluayBpdCB3b3VsZCBiZSBhbiANCiAgICBpZGVhIHRvIGNsYXJpZnkgdGhlIGJlaGF2aW91ciBv ZiB0aGUgcmVjZWl2aW5nIGJncCBzaWRlIGEgbGl0dGxlIGJldHRlci4NCg0KICAgID4gICAgQSBy ZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgcm91dGVyIFNIT1VMRCB1c2UgdGhlIHJlY2VpdmVkIEJH UHNlYyBwYXRoDQogICAgPiAgICB2YWxpZGF0aW9uIHN0YXRlIGluIHNpdHVhdGlvbnMgd2hlcmUg YSBsb2NhbGx5IGNvbXB1dGVkIEJHUHNlYw0KICAgID4gICAgdmFsaWRhdGlvbiByZXN1bHQgaXMg bm90IGN1cnJlbnRseSBhdmFpbGFibGUuICBJbiB0aGUgYWJzZW5jZSBvZiB0aGUNCiAgICA+ICAg IGV4dGVuZGVkIGNvbW11bml0eSwgdGhlIHJlY2VpdmluZyBCR1BzZWMgZW5hYmxlZCByb3V0ZXIg TVVTVCBOT1QgbWFrZQ0KICAgID4gICAgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIHZhbGlkYXRp b24gc2F0ZSBvZiB0aGUgVVBEQVRFLg0KDQogICAgVGhlIHNlY29uZCBzZW50ZW5jZSBpcyBhIG5v LW9wLCBzbyBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0ZXIgdG8gcmVtb3ZlIGl0Lg0KDQogICAg VGhlIGRyYWZ0IGludGVuZHMgdGhhdCB0aGUgYmdwIHJlY2VpdmVyIHRyZWF0cyByb3V0ZXMgd2l0 aCB0aGlzIGV4dGNvbW0gDQogICAgYXMgaWYgdGhleSB3ZXJlIGxvY2FsbHkgdmFsaWRhdGVkIGJ5 IGJncHNlYy4gIFRoZSBzaW1wbGlmaWVkIHN0YXRlIA0KICAgIG91dGNvbWUgaXM6DQoNCiAgICAx LiB0aGUgcmVjZWl2aW5nIGJncCBpbXBsZW1lbnRhdGlvbiBoYXMgYmdwc2VjIGVuYWJsZWQsIGFu ZCBoYXMgY29tcHV0ZWQgDQogICAgYSBsb2NhbCB2YWxpZGF0aW9uIHJlc3VsdCBmb3IgdGhlIGlu Y29taW5nIHByZWZpeA0KDQogICAgMi4gdGhlIHJlY2VpdmluZyBiZ3AgaW1wbGVtZW50YXRpb24g c3VwcG9ydHMgYmdwc2VjLCBidXQgaGFzIG5vdCANCiAgICBjb21wdXRlZCBhIGxvY2FsIHZhbGlk YXRpb24gcmVzdWx0IGZvciB0aGUgaW5jb21pbmcgcHJlZml4DQoNCiAgICAzLiB0aGUgcmVjZWl2 aW5nIGJncCBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBzdXBwb3J0IGJncHNlYy4NCg0KICAgIEF0 IHRoZSBtb21lbnQsIHRoZSB0ZXh0IGRlYWxzIHdpdGggY2FzZSAjMi4gIFByb2JhYmx5IHdoYXQg eW91IHdhbnQgdG8gDQogICAgZG8gaGVyZSBpcyBzdGF0ZSB0aGF0IGxvY2FsIHZhbGlkYXRpb24g dGFrZXMgcHJlZmVyZW5jZSBvdmVyIHRoZSANCiAgICBjb21tdW5pdHkgdmFsdWUuDQoNCiAgICBI ZXJlJ3Mgc29tZSBzdWdnZXN0ZWQgdGV4dCBhcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgcGFyYWdy YXBoIGFib3ZlLCANCiAgICB3aGljaCBkZWFscyB3aXRoICMxIGFuZCAjMjoNCg0KICAgID4gICAg QSByZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgcm91dGVyIFNIT1VMRCB1c2UgdGhlIHJlY2VpdmVk IEJHUHNlYyBwYXRoDQogICAgPiAgICB2YWxpZGF0aW9uIHN0YXRlIGluIHNpdHVhdGlvbnMgd2hl cmUgYSBsb2NhbGx5IGNvbXB1dGVkIEJHUHNlYw0KICAgID4gICAgdmFsaWRhdGlvbiByZXN1bHQg aXMgbm90IGN1cnJlbnRseSBhdmFpbGFibGUuICBJZiBhIGxvY2FsbHkgY29tcHV0ZWQgQkdQc2Vj DQogICAgPiAgICB2YWxpZGF0aW9uIHJlc3VsdCBpcyBhdmFpbGFibGUsIHRoZW4gdGhlIHJlY2Vp dmVkIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24NCiAgICA+ICAgIHN0YXRlIE1VU1QgYmUgaWdub3Jl ZC4NCiAgICBJJ20gbm90IHN1cmUgd2hhdCB5b3UgaW50ZW5kIHdpdGggc3RhdGUgIzMuIFRoZSBj aG9pY2VzIGhlcmUgYXJlOiBTSE9VTEQgDQogICAgaW1wbGVtZW50IGFsdGVybmF0aXZlIHBvbGlj eSBoYW5kbGluZyBtZWNoYW5pc20sIFNIT1VMRCBOT1QgaW1wbGVtZW50IA0KICAgIGFsdGVybmF0 aXZlIHBvbGljeSBoYW5kbGluZyBtZWNoYW5pc20sIG9yIG5vIGFkdmljZS4NCg0KICAgIFNvbWUg b2YgdGhpcyBiZWhhdmlvdXIgY291bGQgYmUgc3ludGhlc2lzZWQgdXNpbmcgbm9ybWFsIHBvbGlj eSBob29rcyBpbiANCiAgICB0aGUgYmdwIHN0YWNrJ3MgY29uZmlndXJhdGlvbiBncmFtbWFyLCBi dXQgdGhhdCB3b3VsZCBuZWVkIGNvZGluZyBhbmQgDQogICAgY291bGQgYmUgbWVzc3kgaWYgdGhl cmUgd2VyZSBldmVyIGZ1dHVyZSBwbGFucyB0byBzdXBwb3J0IGJncHNlYyBiZWNhdXNlIA0KICAg IHRoZW4gdGhlcmUgd291bGQgYmUgdHdvIGZyYW1ld29ya3MsIHByb2JhYmx5IGluY29tcGF0aWJs ZSB3aXRoIGVhY2ggDQogICAgb3RoZXIuICBJdCB3b3VsZCBjZXJ0YWlubHkgYmUgZWFzaWVyIGZv ciBpbXBsZW1lbnRlcnMgdG8gc3RhdGUgdGhhdCB0aGUgDQogICAgZHJhZnQgaXMgbm90IGludGVu ZGVkIGZvciBiZ3Agc3RhY2tzIHdoaWNoIGRvbid0IGFscmVhZHkgaW1wbGVtZW50IA0KICAgIGJn cHNlYy4gIERvIHRoZSBhdXRob3JzIGhhdmUgYW55IHRob3VnaHRzIG9uIHRoaXMgb25lPw0KDQog ICAgTmljaw0KDQo= From nobody Mon Sep 21 14:51:11 2020 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 617673A0AE6 for ; Mon, 21 Sep 2020 14:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.244 X-Spam-Level: X-Spam-Status: No, score=-4.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.448, RCVD_IN_MSPIKE_H2=-0.001, 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 tD4sq1cnJLjw for ; Mon, 21 Sep 2020 14:51:06 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2125.outbound.protection.outlook.com [40.107.89.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A4F3A0ADE for ; Mon, 21 Sep 2020 14:51:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a5ll54TCxz5vnNGx5tsD4rBr9OsYgbBcunoBFn9OYViPRZoGCZobg1sBAr0tpTNr2aMDHB0iWJ1Ya1B6k4aVcYUc9LzYgOtoD6osIM+/h9HQEGJENycvUz8NUFe44JTpDFO+10qaQEilGBIDtCLo+5WG1udxwDr4/vHht70VGa9vYrF3Hq+cyz5u1ilXsGdcvmCn8lDnc0Py2USds/F+Vmbegve/0eQ0XBL+G5tTtDJaJsfuNIdwOTiPPJWgeZ6p0dwooWwnMjISn1zO3tdeqC8QNl0LeCyjtwiJKFIHI/45dQIEzVe6/7Jd9QYagcMQmm1WyG122ufgSlWQewhBhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A9hzFsHDlOunkJcYThRfR0m9Ca0beZZZTR5zxesCxNg=; b=mQl4fb+BfG+BNxeA0xhTbnBJ6wmIXL5dLwQKSxZWSai6yKwf4QnBZS+kRF+sUKU6hOe3PnGIwSy6SSQQsulcd3mKJnRUQX6SRAVmPp7EcQIl7SIOVpmLvqu8WNMnlknym1l+hRekp4AWdKEocwJSCrOqDLp3BTk5GR3H9KJIGmFijfJ4hiZYCiXPj1fwrSp6vTDNdFHWSjuTFoUij+EHB0G99erNfqCcaZRMYpTc0ycyhRBrcvwY9mMPRBlUD4k5QCNpXIt3Ww2EFCn52FPZNoO1EwowDGxGfA2GN1pXTYJOuEIW2IGThFEZvCGjzMXwlDP+wk9qCVJ44K/oAdN2MQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A9hzFsHDlOunkJcYThRfR0m9Ca0beZZZTR5zxesCxNg=; b=JnNauJNaPyoh3+252bKHWoLZ0hFei/PdoUogNMwevcM+MXxYvL/3DrdpsoVNZs8dnioXxntmqQ19DHRzCfm1+p1STZiHOixhMPszrgRjgukHm3MfAW8hXG5BpO8LiV4IEO0BcxderC0WEjuS0Jt+uNiUpB310SzLwfaRy0ZijxY= Received: from BLAPR09MB6963.namprd09.prod.outlook.com (2603:10b6:208:289::7) by BLAPR09MB6276.namprd09.prod.outlook.com (2603:10b6:208:2a9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Mon, 21 Sep 2020 21:51:00 +0000 Received: from BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc]) by BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc%6]) with mapi id 15.20.3391.024; Mon, 21 Sep 2020 21:51:00 +0000 From: "Borchert, Oliver (Fed)" To: Nick Hilliard , "sidrops@ietf.org" CC: Keyur Patel , "Borchert, Oliver (Fed)" , "Montgomery, Douglas C. (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtualzoEwA///QC4A= Date: Mon, 21 Sep 2020 21:51:00 +0000 Message-ID: <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:223::56] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f41eb9a2-1530-4a83-2076-08d85e786de4 x-ms-traffictypediagnostic: BLAPR09MB6276: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4mdYJGhvu/KgB7AdQ6AV1ird/tw46Mdl08hDBH8Ivru2zRXqVYqfMCbIzWYhp18YfWRNsADyMEhk/fbuw4tKENTqDU+Uk/LkrEDafMFKyOQ1fP0DemVcSSan+RsPpRTSTcrp07dyzOBCe+QkavBzFGDNLxTkhfNbBhh6pM8VQ5JR2XBB24fQ0KXp2LnY4+sYQCXgyBr/2BstVeE3qvFyzWZ8BpPJm0FzsbHvnh+b1pkAeLFgBmPITyXJ4S5+kybAl4YE9IdCAbgjZx7KkczCsB70I5JITRpGe2N4H11ZEZt6CR2v/wFslxpnyzT6AHLrUKm9+thZgvQDY5LxLAra2w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6963.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(366004)(39860400002)(396003)(107886003)(66446008)(6486002)(33656002)(8676002)(5660300002)(36756003)(6506007)(2616005)(86362001)(76116006)(91956017)(64756008)(66556008)(66476007)(66946007)(71200400001)(4326008)(83380400001)(8936002)(316002)(6512007)(110136005)(66574015)(186003)(478600001)(54906003)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +JO2CbnGGJf6gVtoETI/yO38EIx1YAq0Agw8y3eptRCMrT1hFNePTMe33uMhSd+rkZ01u8vl0N28/q5Eawi8zemKuEPko2geErTbYGUz6czMGqd6ZSDrBRQ7P+6+Z711VSPgrx6bY3EjIKXnpOnZx2bb1WQzZNdiYb+5xZ6NS3bVBfTOkouyUd0lIEh5GEiXC1KZOFAn/LXFxtHpw/e2eeJm8eNCwRYmvE7KfZzP4nqEv0tslt6pldy+tThWs3cnpb7MfflnCDd8zYvo5irH89QogFKGf/mHeqjz5Vwhq2bKHe3HjsarthTV6y8OYoaxJmcAHGdzC3DEYJx/yO3kpr3i3YqThWxaNcvRgI9nXCdSdugdwoNtiV+LJOgqC+xxDiv+4dNYdyeGIjd64LWaetg9z3zaNxNRyeHEm7mQFjDm7kqvYeEZHz1p1M35RCi+1jp/An9Ap/KR29ICOPYL1N1FNQVWI5G7l4RItCrhJnn2GFRdviptF9ryhYD5eBSkf6OAHLD6fEotHb6Ggi2WD2IV+JyaMAXhziFb1xMPj6sPArVjD/s+kwjS/9oE1zbBzKILIUmtere2p7kQ5n/kPjf4F4+di7loHZGM09AbIFvtPd1qJgvtlesXwrm14toUuPieVFbBnZFlhayrDBfVUstVwTJYaRq37tecEvIcjr8= Content-Type: text/plain; charset="utf-8" Content-ID: <853C308EF27DBB4B9299C15DFD2B79B1@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6963.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f41eb9a2-1530-4a83-2076-08d85e786de4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 21:51:00.5031 (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: UBTH4/LHlbnBrtrshbF46meiqEGnZD8DGu8HGzQqMvRZniLUHj/MV1eQv6XkYoN6C3di7V4VQbHLJ9W7Qh5dKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6276 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 21 Sep 2020 21:51:10 -0000 SGkgTmljaywNClBsZWFzZSBzZWUgaW5saW5lLCBJIGFkZGVkIGFuIFtvYl0gaW4gZnJvbnQgb2Yg bXkgYW5zd2Vycy4gDQoNCu+7v09uIDkvMjEvMjAsIDQ6NDMgUE0sICJTaWRyb3BzIG9uIGJlaGFs ZiBvZiBOaWNrIEhpbGxpYXJkIiA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBuaWNrQGZvb2Jhci5vcmc+IHdyb3RlOg0KDQogICAgS2V5dXIgUGF0ZWwgd3JvdGUgb24gMTAv MDkvMjAyMCAxODoyNzoNCiAgICA+IFRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQgdGhlIGNhbGwgZm9y IGEgd2VlayBpbiBob3BlcyB0aGF0IHdlIHdvdWxkIGhhdmUgYSANCiAgICA+IGNvbnNlbnN1cy4g U2VlbXMgbGlrZSBtb3JlIGRpc2N1c3Npb24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFuIGV4dGVu ZCANCiAgICA+IHRoZSBjYWxsIGZvciAxIG1vcmUgd2Vlay4gVGhlV0dMQ3dpbGwgbm93IGVuZCBv biBTZXB0ZW1iZXIgMTcsIDIwMjANCg0KICAgIHRoaXMgY29tbWVudCBpcyBjb21pbmcgYSBiaXQg bGF0ZSBpbiB0aGUgZGF5LCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSBhbiANCiAgICBpZGVhIHRv IGNsYXJpZnkgdGhlIGJlaGF2aW91ciBvZiB0aGUgcmVjZWl2aW5nIGJncCBzaWRlIGEgbGl0dGxl IGJldHRlci4NCg0KICAgID4gICAgQSByZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgcm91dGVyIFNI T1VMRCB1c2UgdGhlIHJlY2VpdmVkIEJHUHNlYyBwYXRoDQogICAgPiAgICB2YWxpZGF0aW9uIHN0 YXRlIGluIHNpdHVhdGlvbnMgd2hlcmUgYSBsb2NhbGx5IGNvbXB1dGVkIEJHUHNlYw0KICAgID4g ICAgdmFsaWRhdGlvbiByZXN1bHQgaXMgbm90IGN1cnJlbnRseSBhdmFpbGFibGUuICBJbiB0aGUg YWJzZW5jZSBvZiB0aGUNCiAgICA+ICAgIGV4dGVuZGVkIGNvbW11bml0eSwgdGhlIHJlY2Vpdmlu ZyBCR1BzZWMgZW5hYmxlZCByb3V0ZXIgTVVTVCBOT1QgbWFrZQ0KICAgID4gICAgYW55IGFzc3Vt cHRpb24gYWJvdXQgdGhlIHZhbGlkYXRpb24gc2F0ZSBvZiB0aGUgVVBEQVRFLg0KDQogICAgVGhl IHNlY29uZCBzZW50ZW5jZSBpcyBhIG5vLW9wLCBzbyBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0 ZXIgdG8gcmVtb3ZlIGl0Lg0KDQpbb2JdIFdlIGFkZGVkIHRoYXQgZXhhY3Qgd29yZGluZyBiZWNh dXNlIGR1cmluZyAxMDgsIGNvbmNlcm5zIHdlcmUgdm9pY2VkIHRoYXQgDQpbb2JdIGltcGxlbWVu dGF0aW9ucyBjb3VsZCBpbnRlcnByZXQgdGhlIGFic2VuY2Ugb2YgdGhlIGNvbW11bml0eSBzdHJp bmcgYXMgYSANCltvYl0gcGFydGljdWxhciB2YWxpZGF0aW9uIHJlc3VsdC4gVG8gcHJldmVudCB0 aGlzIGZyb20gaGFwcGVuaW5nIHRoaXMgYWRkaXRpb24gDQpbb2JdIHdhcyBzcGVjaWZpY2FsbHkg cmVxdWVzdGVkLiANCg0KICAgIFRoZSBkcmFmdCBpbnRlbmRzIHRoYXQgdGhlIGJncCByZWNlaXZl ciB0cmVhdHMgcm91dGVzIHdpdGggdGhpcyBleHRjb21tIA0KICAgIGFzIGlmIHRoZXkgd2VyZSBs b2NhbGx5IHZhbGlkYXRlZCBieSBiZ3BzZWMuICBUaGUgc2ltcGxpZmllZCBzdGF0ZSANCiAgICBv dXRjb21lIGlzOg0KDQogICAgMS4gdGhlIHJlY2VpdmluZyBiZ3AgaW1wbGVtZW50YXRpb24gaGFz IGJncHNlYyBlbmFibGVkLCBhbmQgaGFzIGNvbXB1dGVkIA0KICAgIGEgbG9jYWwgdmFsaWRhdGlv biByZXN1bHQgZm9yIHRoZSBpbmNvbWluZyBwcmVmaXgNCg0KICAgIDIuIHRoZSByZWNlaXZpbmcg YmdwIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGJncHNlYywgYnV0IGhhcyBub3QgDQogICAgY29t cHV0ZWQgYSBsb2NhbCB2YWxpZGF0aW9uIHJlc3VsdCBmb3IgdGhlIGluY29taW5nIHByZWZpeA0K DQogICAgMy4gdGhlIHJlY2VpdmluZyBiZ3AgaW1wbGVtZW50YXRpb24gZG9lcyBub3Qgc3VwcG9y dCBiZ3BzZWMuDQoNCiAgICBBdCB0aGUgbW9tZW50LCB0aGUgdGV4dCBkZWFscyB3aXRoIGNhc2Ug IzIuICBQcm9iYWJseSB3aGF0IHlvdSB3YW50IHRvIA0KICAgIGRvIGhlcmUgaXMgc3RhdGUgdGhh dCBsb2NhbCB2YWxpZGF0aW9uIHRha2VzIHByZWZlcmVuY2Ugb3ZlciB0aGUgDQogICAgY29tbXVu aXR5IHZhbHVlLg0KDQogICAgSGVyZSdzIHNvbWUgc3VnZ2VzdGVkIHRleHQgYXMgYSByZXBsYWNl bWVudCBmb3IgdGhlIHBhcmFncmFwaCBhYm92ZSwgDQogICAgd2hpY2ggZGVhbHMgd2l0aCAjMSBh bmQgIzI6DQoNCiAgICA+ICAgIEEgcmVjZWl2aW5nIEJHUHNlYyBlbmFibGVkIHJvdXRlciBTSE9V TEQgdXNlIHRoZSByZWNlaXZlZCBCR1BzZWMgcGF0aA0KICAgID4gICAgdmFsaWRhdGlvbiBzdGF0 ZSBpbiBzaXR1YXRpb25zIHdoZXJlIGEgbG9jYWxseSBjb21wdXRlZCBCR1BzZWMNCiAgICA+ICAg IHZhbGlkYXRpb24gcmVzdWx0IGlzIG5vdCBjdXJyZW50bHkgYXZhaWxhYmxlLiAgSWYgYSBsb2Nh bGx5IGNvbXB1dGVkIEJHUHNlYw0KICAgID4gICAgdmFsaWRhdGlvbiByZXN1bHQgaXMgYXZhaWxh YmxlLCB0aGVuIHRoZSByZWNlaXZlZCBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uDQogICAgPiAgICBz dGF0ZSBNVVNUIGJlIGlnbm9yZWQuDQogICAgSSdtIG5vdCBzdXJlIHdoYXQgeW91IGludGVuZCB3 aXRoIHN0YXRlICMzLiBUaGUgY2hvaWNlcyBoZXJlIGFyZTogU0hPVUxEIA0KICAgIGltcGxlbWVu dCBhbHRlcm5hdGl2ZSBwb2xpY3kgaGFuZGxpbmcgbWVjaGFuaXNtLCBTSE9VTEQgTk9UIGltcGxl bWVudCANCiAgICBhbHRlcm5hdGl2ZSBwb2xpY3kgaGFuZGxpbmcgbWVjaGFuaXNtLCBvciBubyBh ZHZpY2UuDQoNCltvYl0gUkZDIDgyMDUgY2xlYXJseSBzdGF0ZXMgdGhhdCBhIHJvdXRlciBjYW4g ZGlmZmVyIGxvY2FsIHZhbGlkYXRpb24uIEEgZ29vZA0KW29iXSByZWFzb24gZm9yIHRoYXQgY291 bGQgYmUgYSB0ZW1wb3JhcnkgcmVzb3VyY2Ugc2hvcnRhZ2UuIEluIGJvdGggY2FzZXMgIzEgYW5k DQpbb2JdICMyLCBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBmb2xsb3dz IFJGQyA4MjA1Lg0KDQpbb2JdIE15IHVuZGVyc3RhbmRpbmcgd2FzIGFsd2F5cyB0aGF0IGxvY2Fs IHZhbGlkYXRpb24gdGFrZXMgcHJlY2VkZW5jZSBvdmVyIA0KW29iXSB0aGUgY29tbXVuaXR5IHZh bHVlLiBUaGUgY29tbXVuaXR5IHZhbHVlIGNhbiBiZSB1c2VkIHVudGlsIGxvY2FsIHZhbGlkYXRp b24NCltvYl0gaXMgcGVyZm9ybWVkLiBUaGUgY29tbXVuaXR5IGF0dHJpYnV0ZSBzZXJ2ZXMgdHdv IHB1cnBvc2VzLiBTaWduYWxpbmcgDQpbb2JdIHRoZSB2YWxpZGF0aW9uIHN0YXRlIHdpdGhpbiB0 aGUgYm91bmRhcmllcyBvZiBSRkM0MzYwIHRvICgxKSBhbGxvdyB1c2luZw0KW29iXSBhIHZhbGlk YXRpb24gc3RhdGUgdW50aWwgdGhlIHJvdXRlciBjYW4gcGVyZm9ybSB0aGUgdmFsaWRhdGlvbiBh bmQgKDIpIGZvciANCltvYl0gb3BlcmF0b3JzIHRvIGhhdmUgYSB0b29sIGZvciBkaWFnbm9zaXMu DQoNCltvYl0gSSBhbSBub3QgcmVhbGx5IGNvbmNlcm5lZCB3aXRoIGNhc2UgIzMgYmVjYXVzZSBl dmVuIHdpdGhvdXQgdGhlIGNvbW11bml0eSwNCltvYl0gb3BlcmF0b3JzIGNhbiBjcmVhdGUgYW4g ZXh0LiBjb21tLiB0byBzaWduYWwgdGhlIHZhbGlkYXRpb24gc3RhdGUgdG8gbm9uIA0KW29iXSBC R1BzZWMgc3BlYWtlcnMuIA0KDQogICAgU29tZSBvZiB0aGlzIGJlaGF2aW91ciBjb3VsZCBiZSBz eW50aGVzaXNlZCB1c2luZyBub3JtYWwgcG9saWN5IGhvb2tzIGluIA0KICAgIHRoZSBiZ3Agc3Rh Y2sncyBjb25maWd1cmF0aW9uIGdyYW1tYXIsIGJ1dCB0aGF0IHdvdWxkIG5lZWQgY29kaW5nIGFu ZCANCiAgICBjb3VsZCBiZSBtZXNzeSBpZiB0aGVyZSB3ZXJlIGV2ZXIgZnV0dXJlIHBsYW5zIHRv IHN1cHBvcnQgYmdwc2VjIGJlY2F1c2UgDQogICAgdGhlbiB0aGVyZSB3b3VsZCBiZSB0d28gZnJh bWV3b3JrcywgcHJvYmFibHkgaW5jb21wYXRpYmxlIHdpdGggZWFjaCANCiAgICBvdGhlci4gIEl0 IHdvdWxkIGNlcnRhaW5seSBiZSBlYXNpZXIgZm9yIGltcGxlbWVudGVycyB0byBzdGF0ZSB0aGF0 IHRoZSANCiAgICBkcmFmdCBpcyBub3QgaW50ZW5kZWQgZm9yIGJncCBzdGFja3Mgd2hpY2ggZG9u J3QgYWxyZWFkeSBpbXBsZW1lbnQgDQogICAgYmdwc2VjLiAgRG8gdGhlIGF1dGhvcnMgaGF2ZSBh bnkgdGhvdWdodHMgb24gdGhpcyBvbmU/DQoNCltvYl0gSSBiZWxpZXZlIHRoYXQgdGhpcyBjb21t dW5pdHkgc3RyaW5nIHNlcnZlcyBtdWx0aXBsZSBwdXJwb3NlcyBhcyBleHBsYWluZWQgDQpbb2Jd IGFib3ZlIGFuZCBpZiBzb21lb25lIHJlYWxseSB3YW50cyB0byB1c2UgY29tbXVuaXR5IHN0cmlu Z3MgdG8gc2VuZCBhIA0KW29iXSBCR1BzZWMgdmFsaWRhdGlvbiBzdGF0ZSB0byBhIG5vbiBCR1Bz ZWMgc3BlYWtlciwgdGhleSBjYW4gZG8gc28gYWxyZWFkeSBieQ0KW29iXSBoYW5kIGNyYWZ0aW5n IHRoZWlyIG93biBjb21tdW5pdHkuIEFnYWluIGFzIGl0IHdhcyBtZW50aW9uZWQgZHVyaW5nIHNv bWUgDQpbb2JdIGVtYWlsIGV4Y2hhbmdlIG9uIHRoZSBsaXN0IHNvbWUgdGltZSBhZ28sIHRoZSBh YnNlbmNlIG9mIHRoZSBleHQuIGNvbS4gZG9lcyANCltvYl0gbm90IHByZXZlbnQgb3BlcmF0b3Jz IG9mIHNlbmRpbmcgdmFsaWRhdGlvbiByZXN1bHRzLiANCg0KICAgIE5pY2sNCg0KDQoNCk9saXZl cg0KDQoNCg== From nobody Tue Sep 22 13:34:37 2020 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 4B6873A005E; Tue, 22 Sep 2020 13:34:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160080687226.21149.6964773729064464423@ietfa.amsl.com> Date: Tue, 22 Sep 2020 13:34:32 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-04.txt 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: Tue, 22 Sep 2020 20:34:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Validation State Signaling Authors : Oliver Borchert Doug Montgomery Daniel Kopp Filename : draft-sidrops-bgpsec-validation-signaling-04.txt Pages : 8 Date : 2020-09-22 Abstract: This document defines a new BGP non-transitive extended community to carry the BGPsec path validation state. BGP speakers that receive this community string can use the embedded BGPsec validation state in conjunction with configured local policies to influence their decision process. The ability to accept and act on BGPsec path validation state from a neighbor allows for a reduction of path validation processing load and/or increased resilience in the event that a router is temporarily unable to perform local path validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sidrops-bgpsec-validation-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-04 https://datatracker.ietf.org/doc/html/draft-sidrops-bgpsec-validation-signaling-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-sidrops-bgpsec-validation-signaling-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 22 13:37:20 2020 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 CA0E13A1980 for ; Tue, 22 Sep 2020 13:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.448, 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 ZZhqmPCIHUiD for ; Tue, 22 Sep 2020 13:37:16 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2126.outbound.protection.outlook.com [40.107.89.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A6F3A1985 for ; Tue, 22 Sep 2020 13:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i32tLEUpf1O8za4csV8IBzQmxEfj9atHM1+VfftZjz7dGgIaxxfbPtfCeJkGevtYg3EASp/TBdZh/jM1E8NS9MhCepaUYyC3pXX9CGDysoruXLtWAzjE8tpN81YwSPBkZlEUX6CwsDQwUcz8eUqWu0Z7UCmpfqu/5bEfmYL08YxR6jFirVIXgvApIdYBKhjQ3NJSopfMc6/BI2hpCpbKqz0duEJwZ/NZQz297fhdqbEkhibrf183oNes2BEdgOBmdrVNKXGd9e6uM45KRw66MrVQnPXtV7E5gW4medBtAWEGVy+MDprv+A0UZpKZFqH4Dl5n5hV9zFugXpMM0Lwv/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6953dT+K/V7ET79kq++H51DtroidwUYyuKf09FOwJv4=; b=fuaoaU8SyxWwC1oyVwiWEamwcgKmqW2yHH772/nQg5babGL6jZ/CAdxmy8ctk03k1Q3R1418TwjDjkXeBiSFcPv289TTJTdWfqruiF7ZkQOw3mWC2/ddzer7HEuVBFRWDlgXAFy4kUtZsmRXyxtEbH5Jjo1kg6qkxi7YAwQik6p+BZpa3amWL2PBZdNNYHErKQllWyyEgTiDc/5BMEUgarf/lWtEVvnc6j5hKcFCyPwc3H5u6rU9RbMcsoU5f+WDvyZaSTk5yHgdy1h+waWBB2moasn/LTOAGwuI7adxW0Notu/TayNZSnctFWHqtPIUyhkuQojERhWrCJd7bhfF2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6953dT+K/V7ET79kq++H51DtroidwUYyuKf09FOwJv4=; b=j4m8TyblIHc+c+ggOczyELercawZ7pw8KBRHYNqWhdFvDFvXpaKH/3siXigR7TwCc6ChTNPHsQ+D2AvW4FbXkSEafX+cLuuhRyuZsJLvapAs7jJ50mCyz/xGTMmDb6JSMttp4FcoFReP8imYR7bA6AvSNWjabVUZm8sQu4Hzh7I= Received: from BLAPR09MB6963.namprd09.prod.outlook.com (2603:10b6:208:289::7) by MN2PR09MB5564.namprd09.prod.outlook.com (2603:10b6:208:217::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Tue, 22 Sep 2020 20:37:13 +0000 Received: from BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc]) by BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc%6]) with mapi id 15.20.3412.020; Tue, 22 Sep 2020 20:37:12 +0000 From: "Borchert, Oliver (Fed)" To: Nick Hilliard , "sidrops@ietf.org" CC: Keyur Patel , "Montgomery, Douglas C. (Fed)" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtualzoEwA///QC4CAAX23AA== Date: Tue, 22 Sep 2020 20:37:12 +0000 Message-ID: References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> In-Reply-To: <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:218::58] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9d9a7280-16bc-48af-c78c-08d85f37493f x-ms-traffictypediagnostic: MN2PR09MB5564: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YDpXF/HFLdWxvHpyqt58JfEI4mID1+X3CXfEnH8g13oX9QG05On8UNWN86y+BdBeDUu0MkNDNDkbMXprrB7t7PeTyhxM/keUXKZzRNpJgkowmQ3DTonIVMNvSBKd2rEvBQ0Tsw+J5nz3B0xvGwrJdbTs61/BqGFRY5H6Bv9MW1YK/NZYteYMbbU/oArTNJvUTLUmmGGJHTBGk7bDXNUHxNGbup3JmzLumaoxR4x4Rtsq1bB8h+m0qtydv1f1WUgIy34mYC05gZFvm9R1R2PLTk+UMP8q5Ed73MiNZrFfYVm3UK1v60S7A6XPTeb2ocAS9qRnmH70SvKG7QPSDTLeb9bNpTnqgq4fK3JL8bh7T1BzLyCfc8Htnhin+nwbJ3EkyoAYFxVkFiZhBmLHckVmuw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6963.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39850400004)(136003)(346002)(376002)(66574015)(6512007)(53546011)(33656002)(86362001)(2616005)(478600001)(8936002)(110136005)(71200400001)(5660300002)(54906003)(83380400001)(8676002)(6506007)(4326008)(66946007)(66476007)(66556008)(64756008)(66446008)(76116006)(186003)(107886003)(316002)(966005)(2906002)(36756003)(6486002)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MOHg2wZBbIc4N2YaxCbTUwauWCCXbrPss2NlR5NmXWTMAS1VKh1KOroM8pC0pYyL9O9oYOGhuXPRI1nEp+sAFc8levP/w4FyQRRqt5leQcx/M7mXkb810KLW6jB5rfBIaVQrqL5waOn0O6eZa0TFkM9md2pV7EDw5hGORMaUOXSZrL8eGMscHpbkypbKhQNf469dqqFEF5uKdUrsWYhjX9V9dqz0gLf8sWHUix1I1BF+63RvUnIzCXFGhqmiXXBiEj/ApGNMaH00vKzbk5lbrUGpag6GgtUdzgTmwJ2w02tFTI2StqnIZMNQF6ztNbvxIWmOHULcROuqfq8z7lQXYm8HgUSDAwqF5etdLeklYnl2FOxNhZNIlW/u1GkQH4sP5S5tytZPBq1uGh5diuduSmJ8wnt23CCcjHDbd5QPdXI3e00594yGkQFt71iQkJ7CwSdxnZvzWhWC6M4RHz6V3JjUcif+eQj3dYyLyqifYVFA//tMvXqSaeD8BdUPPgWx/+2jlxEocZSOaXpbABGKpUNidnk/pkoPIv3uCQ1MUgqzKoj/tv9LDwb5PCSFEuD8a3I3/fRhxTTiB+wzMQVdiHhOXGM3rcrFbNyjUX55D9keU/vJaeVO5YSdbKThIrPX31tiPd98pvU8FJL7td7N6cHsiH6c598Ph1DAlxguCQ0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6963.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d9a7280-16bc-48af-c78c-08d85f37493f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 20:37:12.8596 (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: gB9tOFPMu8O4G04Lr3mldEnpV/IJWApn0LHpMCazeLyKS5w/HziLYrRRzQV1s+UyJF5CZCdTizo48sK/IFiw5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5564 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 20:37:19 -0000 SSBqdXN0IHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgaW5jbHVkaW5n IG1vZGlmaWNhdGlvbnMNCk1hZGUgaW4gdGhlIGZvbGxvd2luZyBhcmVhcy4NCg0KSSBoYWQgZGlz Y3Vzc2lvbnMgYXJvdW5kIGV4dGVuZGVkIGNvbW11bml0eSwgZUJHUCwgYW5kIFJGQzQzNjAgaW5j bHVkaW5nIHRoZSANCmxhc3QgZGlzY3Vzc2lvbiwgTmljayBoYXMgYnJvdWdodCB0byB0aGUgbGlz dC4gDQoNClRvZGF5IHdlIG1vZGlmaWVkIHRoZSBkcmFmdCB0ZXh0IGFuZCB1cGxvYWRlZCB0aGUg bmV3ZXN0IHZlcnNpb24uIFRoZSBuZXcgdmVyc2lvbiANCmRvZXMgYWRkcmVzcyB0aGUgaXNzdWVz IHRoYXQgd2VyZSByYWlzZWQgZHVyaW5nIHRoZSBXTEMuIEJlbG93IEkgdHJ5IHRvIGV4cGxhaW4g DQphIGJpdCB0aGUgY2hhbmdlcyBhbmQgdGhlIG1vdGl2YXRpb24uIA0KDQpPZiBjb3Vyc2UgdGhl IHJlZ3VsYXIgZGlmZiB2ZXJzaW9uIGRvZXMgdGhlIHNhbWUgam9iLg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA0 DQoNCg0KVGhhbmtzIHRvIGFsbCBmb3IgdGhlIGRpc2N1c3Npb24gYW5kIGlucHV0LA0KT2xpdmVy DQoNCg0KTW9kaWZpY2F0aW9uIDE6DQo9PT09PT09PT09PT09PT09PQ0KVGhpcyBhZGRyZXNzZXMg dGhlIGlzc3VlIHdpdGggUkZDNDM2MCBhbmQgZUJHUA0KDQpPcmlnaW5hbCBUZXh0Og0KICAgLi4u DQogICBJZiB0aGUgcm91dGVyIHN1cHBvcnRzIHRoZSBleHRlbnNpb24gYXMgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50LCBpdCANCiAgIFNIT1VMRCBhdHRhY2ggdGhlIEJHUHNlYyBwYXRoIHZhbGlk YXRpb24gc3RhdGUgZXh0ZW5kZWQgY29tbXVuaXR5IHRvIA0KICAgQkdQc2VjIFVQREFURSBtZXNz YWdlcyBzZW50IHRvIEJHUCBwZWVycyBieSBtYXBwaW5nIHRoZSBsb2NhbGx5IA0KICAgY29tcHV0 ZWQgdmFsaWRhdGlvbiBzdGF0ZSBpbnRvIHRoZSBsYXN0IG9jdGV0IG9mIHRoZSBleHRlbmRlZCBj b21tdW5pdHkuICANCiAgIFRoaXMgU0hPVUxEIGJlIGRvbmUgYXV0b21hdGljYWxseSBmb3IgaUJH UCBwZWVycyBhbmQgY29uZmlndXJhYmxlIGZvciANCiAgIGVCR1AgcGVlcnMgKHNlZSBiZWxvdyku DQoNClRoZSBsYXN0IFNlbnRlbmNlOg0KICBUaGlzIFNIT1VMRCBiZSBkb25lIGF1dG9tYXRpY2Fs bHkgZm9yIGlCR1AgcGVlcnMgYW5kDQogICBjb25maWd1cmFibGUgZm9yIGVCR1AgcGVlcnMgKHNl ZSBiZWxvdykuDQoNCklzIHJlcGxhY2VkIHdpdGg6DQogICBPcGVyYXRpb25hbCBiZWhhdmlvciBp cyBnb3Zlcm5lZCBieSBTZWN0aW9uIDYgb2YgW1JGQzQzNjBdLg0KDQoNCk1vZGlmaWNhdGlvbiAy Og0KPT09PT09PT09PT09PT09PT0NClRoaXMgbW9kaWZpY2F0aW9uIGFkZHJlc3NlcyBOaWNrcyBj b21tZW50IHJlZ2FyZGluZyB0aGUgYWJzZW5jZSBvZiB0aGUgDQpleHQgY29tbSBhdHRyaWJ1dGUg YW5kIHdoYXQgdGhhdCBtZWFudCByZWdhcmRpbmcgdGhlIHZhbGlkYXRpb24gc3RhdGUgDQpvZiB0 aGUgVVBEQVRFIA0KDQogT3JpZ2luYWwgVGV4dDoNCiAgIEluIHRoZSBhYnNlbmNlIG9mIHRoZSBl eHRlbmRlZCBjb21tdW5pdHksIHRoZSByZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgDQogICByb3V0 ZXIgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgdmFsaWRhdGlvbiBzYXRl IG9mIHRoZSANCiAgIFVQREFURS4NCg0KIFdlIGFkZGVkIHRoZSB3b3JkICJwZWVyJ3MiIGluIGZy b250IG9mIHZhbGlkYXRpb246DQogICBJbiB0aGUgYWJzZW5jZSBvZiB0aGUgZXh0ZW5kZWQgY29t bXVuaXR5LCB0aGUgcmVjZWl2aW5nIEJHUHNlYyBlbmFibGVkIA0KICAgcm91dGVyIE1VU1QgTk9U IG1ha2UgYW55IGFzc3VtcHRpb24gYWJvdXQgdGhlIHBlZXIncyB2YWxpZGF0aW9uIHN0YXRlIA0K ICAgb2YgdGhlIFVQREFURS4NCg0KDQpNb2RpZmljYXRpb24gMzoNCj09PT09PT09PT09PT09PT09 DQpUaGlzIGFkZHJlc3NlcyBOaWNrcyBjb21tZW50IHJlZ2FyZGluZyB0aGUgbG9jYWwgdmFsaWRh dGlvbiB2cy4gcmVjZWl2ZWQgDQp2YWxpZGF0aW9uLiBXZSBhZGRlZCB0aGUgZm9sbG93aW5nIHNl bnRlbmNlIHRvIHRoZSBwYXJhZ3JhcGggb2YgTW9kaWZpY2F0aW9uIDINCg0KQWRkZWQgc2VudGVu Y2U6DQogICBBIGxvY2FsbHkgY29tcHV0ZWQgdmFsaWRhdGlvbiBzdGF0ZSBmb3IgYW4gVVBEQVRF IHRha2VzIHByZWNlZGVuY2Ugb3Zlcg0KICAgdGhlIHJlY2VpdmVkIHZhbGlkYXRpb24gc3RhdGUu DQoNCg0KTW9kaWZpY2F0aW9uIDQ6DQo9PT09PT09PT09PT09PT09PQ0KVGhpcyBtb2RpZmljYXRp b24gcmVtb3ZlZCB0aGUgbWVudGlvbiBvZiBlQkdQIGFuZCBvdGhlciBoYW5kbGluZ3Mgb2YgdGhl IA0KZXh0IGNvbS4gSXQgaXMgZ2VuZXJhbGx5IGhhbmRsZWQgaW4gUkZDNDM2MC4gV2UgYWxzbyBh ZGRyZXNzZWQgY2FzZSAjMyBvZiBOaWNrDQp3aGVyZSBhIG5vbi1CR1BzZWMgc3BlYWtlciBpcyBp bnZvbHZlZC4NCg0KT3JpZ2luYWwgVGV4dDogDQogICBCeSBkZWZhdWx0LCByb3V0ZXJzIFNIT1VM RCBlbmFibGUgdXNlIG9mIHRoaXMgY29tbXVuaXR5IG9uIGFsbCBpQkdQIHNlc3Npb25zIA0KICAg YW5kIHJvdXRlcnMgU0hPVUxEIGRpc2FibGUgdGhlIHVzZSBvZiB0aGlzIGNvbW11bml0eSBvbiBh bGwgZUJHUCBzZXNzaW9ucy4NCiAgIEltcGxlbWVudGF0aW9ucyBNVVNUIE5PVCBzZW5kIG1vcmUg dGhhbiBvbmUgaW5zdGFuY2Ugb2YgdGhlIG9yaWdpbiB2YWxpZGF0aW9uIA0KICAgc3RhdGUgZXh0 ZW5kZWQgY29tbXVuaXR5IGFuZCBNVVNUIGRyb3AgKHdpdGhvdXQgcHJvY2Vzc2luZykgdGhlIEJH UHNlYyBwYXRoIA0KICAgdmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkgaWYgcmVj ZWl2ZWQgb3ZlciBhbiBFeHRlcm5hbCBCR1AgKGVCR1ApIA0KICAgcGVlcmluZyBzZXNzaW9uIHRo YXQgaGFzIG5vdCBiZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZW5hYmxlIHByb2Nlc3Npbmcu DQoNCk5ldyBUZXh0Og0KICBCeSBkZWZhdWx0LCByb3V0ZXJzIFNIT1VMRCBlbmFibGUgdXNlIG9m IHRoaXMgY29tbXVuaXR5IA0KICBvbiBhbGwgaUJHUCBzZXNzaW9ucy4gIEltcGxlbWVudGF0aW9u cyBNVVNUIE5PVCBzZW5kIG1vcmUgdGhhbiBvbmUgaW5zdGFuY2UgDQogIG9mIHRoZSBCR1BzZWMg dmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkuIEltcGxlbWVudGF0aW9ucyBNVVNU IE5PVCANCiAgc2VuZCB0aGUgZXh0ZW5kZWQgY29tbXVuaXR5IGlmIG5vdCBpbiBhIEJHUHNlYyBV UERBVEUuIA0KDQogIEltcGxlbWVudGF0aW9ucyBNVVNUIGRyb3AgKHdpdGhvdXQgcHJvY2Vzc2lu ZykgdGhlIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24gDQogIHN0YXRlIGV4dGVuZGVkIGNvbW11bml0 eSBpZiByZWNlaXZlZCBvdmVyIGEgcGVlcmluZyBzZXNzaW9uIHdoZXJlIGVpdGhlciANCiAgdGhl IHVzYWdlIGlzIG5vdCBlbmFibGVkIG9yIGl0IGlzIG5vdCBwYXJ0IG9mIGEgQkdQc2VjIFVQREFU RS4NCg0KDQoNCg0KDQoNCk9saXZlcg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpOYXRp b25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQoNCu+7v09uIDkvMjEv MjAsIDU6NTEgUE0sICJCb3JjaGVydCwgT2xpdmVyIChGZWQpIiA8b2xpdmVyLmJvcmNoZXJ0QG5p c3QuZ292PiB3cm90ZToNCg0KICAgIEhpIE5pY2ssDQogICAgUGxlYXNlIHNlZSBpbmxpbmUsIEkg YWRkZWQgYW4gW29iXSBpbiBmcm9udCBvZiBteSBhbnN3ZXJzLiANCg0KICAgIE9uIDkvMjEvMjAs IDQ6NDMgUE0sICJTaWRyb3BzIG9uIGJlaGFsZiBvZiBOaWNrIEhpbGxpYXJkIiA8c2lkcm9wcy1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNrQGZvb2Jhci5vcmc+IHdyb3RlOg0KDQog ICAgICAgIEtleXVyIFBhdGVsIHdyb3RlIG9uIDEwLzA5LzIwMjAgMTg6Mjc6DQogICAgICAgID4g VGhlIHdnIGNoYWlycyBleHRlbmRlZCB0aGUgY2FsbCBmb3IgYSB3ZWVrIGluIGhvcGVzIHRoYXQg d2Ugd291bGQgaGF2ZSBhIA0KICAgICAgICA+IGNvbnNlbnN1cy4gU2VlbXMgbGlrZSBtb3JlIGRp c2N1c3Npb24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFuIGV4dGVuZCANCiAgICAgICAgPiB0aGUg Y2FsbCBmb3IgMSBtb3JlIHdlZWsuIFRoZVdHTEN3aWxsIG5vdyBlbmQgb24gU2VwdGVtYmVyIDE3 LCAyMDIwDQoNCiAgICAgICAgdGhpcyBjb21tZW50IGlzIGNvbWluZyBhIGJpdCBsYXRlIGluIHRo ZSBkYXksIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGFuIA0KICAgICAgICBpZGVhIHRvIGNsYXJp ZnkgdGhlIGJlaGF2aW91ciBvZiB0aGUgcmVjZWl2aW5nIGJncCBzaWRlIGEgbGl0dGxlIGJldHRl ci4NCg0KICAgICAgICA+ICAgIEEgcmVjZWl2aW5nIEJHUHNlYyBlbmFibGVkIHJvdXRlciBTSE9V TEQgdXNlIHRoZSByZWNlaXZlZCBCR1BzZWMgcGF0aA0KICAgICAgICA+ICAgIHZhbGlkYXRpb24g c3RhdGUgaW4gc2l0dWF0aW9ucyB3aGVyZSBhIGxvY2FsbHkgY29tcHV0ZWQgQkdQc2VjDQogICAg ICAgID4gICAgdmFsaWRhdGlvbiByZXN1bHQgaXMgbm90IGN1cnJlbnRseSBhdmFpbGFibGUuICBJ biB0aGUgYWJzZW5jZSBvZiB0aGUNCiAgICAgICAgPiAgICBleHRlbmRlZCBjb21tdW5pdHksIHRo ZSByZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgcm91dGVyIE1VU1QgTk9UIG1ha2UNCiAgICAgICAg PiAgICBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgdmFsaWRhdGlvbiBzYXRlIG9mIHRoZSBVUERB VEUuDQoNCiAgICAgICAgVGhlIHNlY29uZCBzZW50ZW5jZSBpcyBhIG5vLW9wLCBzbyBpdCB3b3Vs ZCBwcm9iYWJseSBiZSBiZXR0ZXIgdG8gcmVtb3ZlIGl0Lg0KDQogICAgW29iXSBXZSBhZGRlZCB0 aGF0IGV4YWN0IHdvcmRpbmcgYmVjYXVzZSBkdXJpbmcgMTA4LCBjb25jZXJucyB3ZXJlIHZvaWNl ZCB0aGF0IA0KICAgIFtvYl0gaW1wbGVtZW50YXRpb25zIGNvdWxkIGludGVycHJldCB0aGUgYWJz ZW5jZSBvZiB0aGUgY29tbXVuaXR5IHN0cmluZyBhcyBhIA0KICAgIFtvYl0gcGFydGljdWxhciB2 YWxpZGF0aW9uIHJlc3VsdC4gVG8gcHJldmVudCB0aGlzIGZyb20gaGFwcGVuaW5nIHRoaXMgYWRk aXRpb24gDQogICAgW29iXSB3YXMgc3BlY2lmaWNhbGx5IHJlcXVlc3RlZC4gDQoNCiAgICAgICAg VGhlIGRyYWZ0IGludGVuZHMgdGhhdCB0aGUgYmdwIHJlY2VpdmVyIHRyZWF0cyByb3V0ZXMgd2l0 aCB0aGlzIGV4dGNvbW0gDQogICAgICAgIGFzIGlmIHRoZXkgd2VyZSBsb2NhbGx5IHZhbGlkYXRl ZCBieSBiZ3BzZWMuICBUaGUgc2ltcGxpZmllZCBzdGF0ZSANCiAgICAgICAgb3V0Y29tZSBpczoN Cg0KICAgICAgICAxLiB0aGUgcmVjZWl2aW5nIGJncCBpbXBsZW1lbnRhdGlvbiBoYXMgYmdwc2Vj IGVuYWJsZWQsIGFuZCBoYXMgY29tcHV0ZWQgDQogICAgICAgIGEgbG9jYWwgdmFsaWRhdGlvbiBy ZXN1bHQgZm9yIHRoZSBpbmNvbWluZyBwcmVmaXgNCg0KICAgICAgICAyLiB0aGUgcmVjZWl2aW5n IGJncCBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBiZ3BzZWMsIGJ1dCBoYXMgbm90IA0KICAgICAg ICBjb21wdXRlZCBhIGxvY2FsIHZhbGlkYXRpb24gcmVzdWx0IGZvciB0aGUgaW5jb21pbmcgcHJl Zml4DQoNCiAgICAgICAgMy4gdGhlIHJlY2VpdmluZyBiZ3AgaW1wbGVtZW50YXRpb24gZG9lcyBu b3Qgc3VwcG9ydCBiZ3BzZWMuDQoNCiAgICAgICAgQXQgdGhlIG1vbWVudCwgdGhlIHRleHQgZGVh bHMgd2l0aCBjYXNlICMyLiAgUHJvYmFibHkgd2hhdCB5b3Ugd2FudCB0byANCiAgICAgICAgZG8g aGVyZSBpcyBzdGF0ZSB0aGF0IGxvY2FsIHZhbGlkYXRpb24gdGFrZXMgcHJlZmVyZW5jZSBvdmVy IHRoZSANCiAgICAgICAgY29tbXVuaXR5IHZhbHVlLg0KDQogICAgICAgIEhlcmUncyBzb21lIHN1 Z2dlc3RlZCB0ZXh0IGFzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBwYXJhZ3JhcGggYWJvdmUsIA0K ICAgICAgICB3aGljaCBkZWFscyB3aXRoICMxIGFuZCAjMjoNCg0KICAgICAgICA+ICAgIEEgcmVj ZWl2aW5nIEJHUHNlYyBlbmFibGVkIHJvdXRlciBTSE9VTEQgdXNlIHRoZSByZWNlaXZlZCBCR1Bz ZWMgcGF0aA0KICAgICAgICA+ICAgIHZhbGlkYXRpb24gc3RhdGUgaW4gc2l0dWF0aW9ucyB3aGVy ZSBhIGxvY2FsbHkgY29tcHV0ZWQgQkdQc2VjDQogICAgICAgID4gICAgdmFsaWRhdGlvbiByZXN1 bHQgaXMgbm90IGN1cnJlbnRseSBhdmFpbGFibGUuICBJZiBhIGxvY2FsbHkgY29tcHV0ZWQgQkdQ c2VjDQogICAgICAgID4gICAgdmFsaWRhdGlvbiByZXN1bHQgaXMgYXZhaWxhYmxlLCB0aGVuIHRo ZSByZWNlaXZlZCBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uDQogICAgICAgID4gICAgc3RhdGUgTVVT VCBiZSBpZ25vcmVkLg0KICAgICAgICBJJ20gbm90IHN1cmUgd2hhdCB5b3UgaW50ZW5kIHdpdGgg c3RhdGUgIzMuIFRoZSBjaG9pY2VzIGhlcmUgYXJlOiBTSE9VTEQgDQogICAgICAgIGltcGxlbWVu dCBhbHRlcm5hdGl2ZSBwb2xpY3kgaGFuZGxpbmcgbWVjaGFuaXNtLCBTSE9VTEQgTk9UIGltcGxl bWVudCANCiAgICAgICAgYWx0ZXJuYXRpdmUgcG9saWN5IGhhbmRsaW5nIG1lY2hhbmlzbSwgb3Ig bm8gYWR2aWNlLg0KDQogICAgW29iXSBSRkMgODIwNSBjbGVhcmx5IHN0YXRlcyB0aGF0IGEgcm91 dGVyIGNhbiBkaWZmZXIgbG9jYWwgdmFsaWRhdGlvbi4gQSBnb29kDQogICAgW29iXSByZWFzb24g Zm9yIHRoYXQgY291bGQgYmUgYSB0ZW1wb3JhcnkgcmVzb3VyY2Ugc2hvcnRhZ2UuIEluIGJvdGgg Y2FzZXMgIzEgYW5kDQogICAgW29iXSAjMiwgSSB3b3VsZCBhc3N1bWUgdGhhdCB0aGUgaW1wbGVt ZW50YXRpb24gZm9sbG93cyBSRkMgODIwNS4NCg0KICAgIFtvYl0gTXkgdW5kZXJzdGFuZGluZyB3 YXMgYWx3YXlzIHRoYXQgbG9jYWwgdmFsaWRhdGlvbiB0YWtlcyBwcmVjZWRlbmNlIG92ZXIgDQog ICAgW29iXSB0aGUgY29tbXVuaXR5IHZhbHVlLiBUaGUgY29tbXVuaXR5IHZhbHVlIGNhbiBiZSB1 c2VkIHVudGlsIGxvY2FsIHZhbGlkYXRpb24NCiAgICBbb2JdIGlzIHBlcmZvcm1lZC4gVGhlIGNv bW11bml0eSBhdHRyaWJ1dGUgc2VydmVzIHR3byBwdXJwb3Nlcy4gU2lnbmFsaW5nIA0KICAgIFtv Yl0gdGhlIHZhbGlkYXRpb24gc3RhdGUgd2l0aGluIHRoZSBib3VuZGFyaWVzIG9mIFJGQzQzNjAg dG8gKDEpIGFsbG93IHVzaW5nDQogICAgW29iXSBhIHZhbGlkYXRpb24gc3RhdGUgdW50aWwgdGhl IHJvdXRlciBjYW4gcGVyZm9ybSB0aGUgdmFsaWRhdGlvbiBhbmQgKDIpIGZvciANCiAgICBbb2Jd IG9wZXJhdG9ycyB0byBoYXZlIGEgdG9vbCBmb3IgZGlhZ25vc2lzLg0KDQogICAgW29iXSBJIGFt IG5vdCByZWFsbHkgY29uY2VybmVkIHdpdGggY2FzZSAjMyBiZWNhdXNlIGV2ZW4gd2l0aG91dCB0 aGUgY29tbXVuaXR5LA0KICAgIFtvYl0gb3BlcmF0b3JzIGNhbiBjcmVhdGUgYW4gZXh0LiBjb21t LiB0byBzaWduYWwgdGhlIHZhbGlkYXRpb24gc3RhdGUgdG8gbm9uIA0KICAgIFtvYl0gQkdQc2Vj IHNwZWFrZXJzLiANCg0KICAgICAgICBTb21lIG9mIHRoaXMgYmVoYXZpb3VyIGNvdWxkIGJlIHN5 bnRoZXNpc2VkIHVzaW5nIG5vcm1hbCBwb2xpY3kgaG9va3MgaW4gDQogICAgICAgIHRoZSBiZ3Ag c3RhY2sncyBjb25maWd1cmF0aW9uIGdyYW1tYXIsIGJ1dCB0aGF0IHdvdWxkIG5lZWQgY29kaW5n IGFuZCANCiAgICAgICAgY291bGQgYmUgbWVzc3kgaWYgdGhlcmUgd2VyZSBldmVyIGZ1dHVyZSBw bGFucyB0byBzdXBwb3J0IGJncHNlYyBiZWNhdXNlIA0KICAgICAgICB0aGVuIHRoZXJlIHdvdWxk IGJlIHR3byBmcmFtZXdvcmtzLCBwcm9iYWJseSBpbmNvbXBhdGlibGUgd2l0aCBlYWNoIA0KICAg ICAgICBvdGhlci4gIEl0IHdvdWxkIGNlcnRhaW5seSBiZSBlYXNpZXIgZm9yIGltcGxlbWVudGVy cyB0byBzdGF0ZSB0aGF0IHRoZSANCiAgICAgICAgZHJhZnQgaXMgbm90IGludGVuZGVkIGZvciBi Z3Agc3RhY2tzIHdoaWNoIGRvbid0IGFscmVhZHkgaW1wbGVtZW50IA0KICAgICAgICBiZ3BzZWMu ICBEbyB0aGUgYXV0aG9ycyBoYXZlIGFueSB0aG91Z2h0cyBvbiB0aGlzIG9uZT8NCg0KICAgIFtv Yl0gSSBiZWxpZXZlIHRoYXQgdGhpcyBjb21tdW5pdHkgc3RyaW5nIHNlcnZlcyBtdWx0aXBsZSBw dXJwb3NlcyBhcyBleHBsYWluZWQgDQogICAgW29iXSBhYm92ZSBhbmQgaWYgc29tZW9uZSByZWFs bHkgd2FudHMgdG8gdXNlIGNvbW11bml0eSBzdHJpbmdzIHRvIHNlbmQgYSANCiAgICBbb2JdIEJH UHNlYyB2YWxpZGF0aW9uIHN0YXRlIHRvIGEgbm9uIEJHUHNlYyBzcGVha2VyLCB0aGV5IGNhbiBk byBzbyBhbHJlYWR5IGJ5DQogICAgW29iXSBoYW5kIGNyYWZ0aW5nIHRoZWlyIG93biBjb21tdW5p dHkuIEFnYWluIGFzIGl0IHdhcyBtZW50aW9uZWQgZHVyaW5nIHNvbWUgDQogICAgW29iXSBlbWFp bCBleGNoYW5nZSBvbiB0aGUgbGlzdCBzb21lIHRpbWUgYWdvLCB0aGUgYWJzZW5jZSBvZiB0aGUg ZXh0LiBjb20uIGRvZXMgDQogICAgW29iXSBub3QgcHJldmVudCBvcGVyYXRvcnMgb2Ygc2VuZGlu ZyB2YWxpZGF0aW9uIHJlc3VsdHMuIA0KDQogICAgICAgIE5pY2sNCg0KDQoNCiAgICBPbGl2ZXIN Cg0KDQoNCg== From nobody Fri Sep 25 05:06:54 2020 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 CFCC83A13BC for ; Fri, 25 Sep 2020 05:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 sZvf-Msspl9T for ; Fri, 25 Sep 2020 05:06:51 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0723A3A0997 for ; Fri, 25 Sep 2020 05:06:50 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 08PC6dYW032220 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Sep 2020 13:06:39 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: "Borchert, Oliver (Fed)" Cc: "sidrops@ietf.org" , Keyur Patel , "Montgomery, Douglas C. (Fed)" References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> From: Nick Hilliard Message-ID: Date: Fri, 25 Sep 2020 13:06:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.30 MIME-Version: 1.0 In-Reply-To: <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 25 Sep 2020 12:06:53 -0000 Borchert, Oliver (Fed) wrote on 21/09/2020 22:51: > Hi Nick, > Please see inline, I added an [ob] in front of my answers. > > On 9/21/20, 4:43 PM, "Sidrops on behalf of Nick Hilliard" wrote: > > A receiving BGPsec enabled router SHOULD use the received BGPsec path > > validation state in situations where a locally computed BGPsec > > validation result is not currently available. In the absence of the > > extended community, the receiving BGPsec enabled router MUST NOT make > > any assumption about the validation sate of the UPDATE. > > The second sentence is a no-op, so it would probably be better to remove it. > > [ob] We added that exact wording because during 108, concerns were voiced that > [ob] implementations could interpret the absence of the community string as a > [ob] particular validation result. To prevent this from happening this addition > [ob] was specifically requested. right, noted. I missed the discussion about this in the ietf 108 sidrops session. > [ob] RFC 8205 clearly states that a router can differ local validation. A good > [ob] reason for that could be a temporary resource shortage. In both cases #1 and > [ob] #2, I would assume that the implementation follows RFC 8205. > > [ob] My understanding was always that local validation takes precedence over > [ob] the community value. Ben Maddison brought up implementation differences at the ietf108 session. You're right that it's probably obvious to anyone on the SIDROPS WG that native BGPsec evaluation should take precedence, but developers or other people reading the specs may make different decisions because they're going to approach the document from a different point of view. It would be clearer to make this explicit, e.g. to add a single sentence in the Deployment Considerations section to say: "If the received validation state of a route differs from a BGPsec validation state locally computed according to [RFC8205], then the locally computed BGPsec validation state MUST be used and the received validation state MUST be ignored". On a separate thing, getting back to ebgp stuff, the Deployment Considerations section says: > Furthermore, one can envision that the operator of a BGPsec router > decides to defer local BGPsec validation when a validation state > value is learned via iBGP or a trusted eBGP peer. This needs to be reworded because there is no concept of "trusted eBGP" in rfc4360. Maybe reword as "... when a validation state value is learned via BGP", and just revert to the default behaviour from 4360? also nit: > Implementations MUST drop (without processing) the BGPsec path > validation state extended community if received over a peering > session where either the usage is not enabled or it is not part of a > BGPsec UPDATE. s/peering session/BGP session/ Nick From nobody Fri Sep 25 11:15:25 2020 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 623953A1141 for ; Fri, 25 Sep 2020 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.448, 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 QC4psqu5gSB5 for ; Fri, 25 Sep 2020 11:15:22 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2111.outbound.protection.outlook.com [40.107.91.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084BC3A0AF3 for ; Fri, 25 Sep 2020 11:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c8FVTfhQtIp9Zu/zPisHKiV9b2BnQ1E5qk+bSPnmPkJkqWS1YA6g2iAsUWF0ict0o7em2y9LzKSde/3GXYN8Y+lXEZH215BDarJVlwXLzhCympe0TYKukdlVlWLr6FJDsDQ0tff1w6pf53RAOfh2aXEJarKnlLpRfQqP8EM7hVO3uVwC5jIlwKJJ4/MgP2zIfHnOuIKLCR2B8TiqLjZAJpgUmje2hcc4PqmufeU4zyX96IW8sYQQkpb7E6qaCTxSfnn89V/NpnZlo97koYEHm0z3uvWskkSFRjGEep2axllpf+R9LP7pm+0JKLd8N0T61eTh83EhaOteX8sqnZFDtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EEckLcL+UaL1fgtOnRLC3KEhtNejhPhAG/H88jB3iuY=; b=Jp69wIfkbKWhbLFfR1FHXCt8GZajJe3XPSdT2mt4Tb7gHbCCgIT6UjJ+YPsYbqKEmqvGCahSn37O53xGEkEJ2USMOi1WFJEW3BCIUTN/B5dLUXcFNuRLUHmqinBoPmgdJbNQihm1Osz0IreocDqDiZTJDyzjNPiGpqxm68W9J3x08JZyG9JeX+ddWbcLVwVqGdOpeCQDJGjI61uE7CiCFP3gCpulb6uakVBUNsVJjTQUEbCow8hc8pTl18zU+PuGWl/m9gVZRoPF8hOMWSgusZ/fm11Z5bUnDLKodUxsw66Cf+YQvj9Ni69GY/lxyCjVQ62s3XppNKJ9GTVq6OI+WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EEckLcL+UaL1fgtOnRLC3KEhtNejhPhAG/H88jB3iuY=; b=BDgEBr1DWhOIfWHfE6bFIOt/bi7b0ObrDdcYC6ChnNHGQQsakrWcnv9RR4TyZBKaVtSfpX8f0rBihhkZ0upBf+ZM/hrCD95mdu2HDT0CxvgT3Jjtwtjo2R+Ns8TioZ3rwued64ogShvBKvCidMDqJpdoQv7AGU7STcQT3IXngW4= Received: from DM8PR09MB6967.namprd09.prod.outlook.com (2603:10b6:5:2e1::23) by DM6PR09MB5704.namprd09.prod.outlook.com (2603:10b6:5:266::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.13; Fri, 25 Sep 2020 18:15:20 +0000 Received: from DM8PR09MB6967.namprd09.prod.outlook.com ([fe80::453b:8416:ceed:8f5f]) by DM8PR09MB6967.namprd09.prod.outlook.com ([fe80::453b:8416:ceed:8f5f%6]) with mapi id 15.20.3412.022; Fri, 25 Sep 2020 18:15:20 +0000 From: "Borchert, Oliver (Fed)" To: Nick Hilliard CC: "sidrops@ietf.org" , Keyur Patel , "Montgomery, Douglas C. (Fed)" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtualzoEwA///QC4CABekhgIAAI/GA Date: Fri, 25 Sep 2020 18:15:19 +0000 Message-ID: References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:152::a3] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e41caaa9-ca9a-4aa8-80bc-08d8617ef66d x-ms-traffictypediagnostic: DM6PR09MB5704: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q7ITnJb62Pjr9EZ0XFs2uWf20BH0mnpxAhoLtzOexHG6CDiQQdo4bgduNW5+vlPQEuOEmuOTexk8xjP4FKsML82bZfApQIIJotLhYlDKpnapoyli7XmDMR4v5lQTgToyHWY2XopYkGtf0JsTcZFlDpetZoVf/WGXAPnlD0+woaVK78bEKQ6cCYuDRKw1mWy1+YQrcAzL5ScdAgn7pI5N7ziysIFB+8YErvnlhCu+e5h7Rgv3nhU5I9qj8rI2GLiSuzR8AsE11VtXVmTBCvVBVTwAxqcIUAfrOyTRmDl3sLkd1Crb6A0xKlWl9yb5fNqFTMh/ihhdL7PYxs7pb7J+Kg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR09MB6967.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(2616005)(71200400001)(86362001)(478600001)(66574015)(6486002)(33656002)(186003)(83380400001)(54906003)(6512007)(5660300002)(36756003)(64756008)(107886003)(66476007)(66556008)(76116006)(4326008)(66946007)(6506007)(8936002)(316002)(91956017)(8676002)(66446008)(53546011)(2906002)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: E+2W8OMutvmDuY3MCyUwMEtiiRyzeTVXACG4zHFIesXdhO0niAi+pI25US3N0Dn7qnFQhsX9yCusnolDrh/+7bTrRpGQehtJQ7VyNdDC+twEp7FMlOwZ73feuZ2m0jUHOZoVhcDn29atEv0OwjjvxVcnDkZvMWW/8tTOeM6d5Umzt4UM3iQTMAnkIuku67E/wTti4qNeO2ZYrxFODla+hJjdxb34E8XuUhVt/8091B9PC7RBKnzIon6It9lxQ2NNWB4r7Fzp0LaMC99kI6SO6QkWW5lwSoh//nuSwHN7n3NSRykhkLP7X1Q52hyL1a2nrpiu5kh/tckWPYR5rNfve2RnDc4fxeArVcaCXC0d/HX2rJ8w8ArqWGol6QbUFB1WoqYp3d3If3RWKwItET1AFH73eLh+j/jNEuWwhDZynUFLCc2C02n4UWqcZ7XXO6Rj5y7deLhB/erI4l2qvY2OZ96rQM1KfQj77PFBqVTjzY9DX42KB1rYrYeB39usHIpa6U3dBTxv1cHpU2fuTfDpYF+RktTLZ3keCqmC8qfIt2e4ktka0U62WYPfKRje6hjJ6pVwMW6+38f1CKTTI69czkvOOXIPgKs0e2DLkIE6ZUtnQoWuK680Og9z9uwzNsirI0DF1/fKChwgKpo2FAUkNH2uIAItLpMAC6u4cI5EM6A= Content-Type: text/plain; charset="utf-8" Content-ID: <85514D4E1088764D9BDEC30F58740C33@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR09MB6967.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e41caaa9-ca9a-4aa8-80bc-08d8617ef66d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 18:15:19.9765 (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: rDZbNcDohGQHE9AwT8u33XdURpFGOHVgpTesvp1Gu+67hsrA7CEQtb0PJNappwxB/7mRcqPt6cZ3raa2jwHyIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB5704 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020 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, 25 Sep 2020 18:15:23 -0000 SGkgTmljaywNCg0KSSdsbCBnbyBpbmxpbmUgYWdhaW4sIEknbGwgcG9zdCBhbiB1cGRhdGUgbGF0 ZXIgdG9kYXksDQoNCk9saXZlcg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdA0KTmF0 aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KKE9mZmljZSkgKzEu MzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcNCiANCg0K77u/T24gOS8yNS8y MCwgODowNyBBTSwgIk5pY2sgSGlsbGlhcmQiIDxuaWNrQGZvb2Jhci5vcmc+IHdyb3RlOg0KDQog ICAgQm9yY2hlcnQsIE9saXZlciAoRmVkKSB3cm90ZSBvbiAyMS8wOS8yMDIwIDIyOjUxOg0KICAg ID4gSGkgTmljaywNCiAgICA+IFBsZWFzZSBzZWUgaW5saW5lLCBJIGFkZGVkIGFuIFtvYl0gaW4g ZnJvbnQgb2YgbXkgYW5zd2Vycy4NCiAgICA+IA0KICAgID4gT24gOS8yMS8yMCwgNDo0MyBQTSwg IlNpZHJvcHMgb24gYmVoYWxmIG9mIE5pY2sgSGlsbGlhcmQiIDxzaWRyb3BzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIG5pY2tAZm9vYmFyLm9yZz4gd3JvdGU6DQogICAgPiAgICAgID4g ICAgQSByZWNlaXZpbmcgQkdQc2VjIGVuYWJsZWQgcm91dGVyIFNIT1VMRCB1c2UgdGhlIHJlY2Vp dmVkIEJHUHNlYyBwYXRoDQogICAgPiAgICAgID4gICAgdmFsaWRhdGlvbiBzdGF0ZSBpbiBzaXR1 YXRpb25zIHdoZXJlIGEgbG9jYWxseSBjb21wdXRlZCBCR1BzZWMNCiAgICA+ICAgICAgPiAgICB2 YWxpZGF0aW9uIHJlc3VsdCBpcyBub3QgY3VycmVudGx5IGF2YWlsYWJsZS4gIEluIHRoZSBhYnNl bmNlIG9mIHRoZQ0KICAgID4gICAgICA+ICAgIGV4dGVuZGVkIGNvbW11bml0eSwgdGhlIHJlY2Vp dmluZyBCR1BzZWMgZW5hYmxlZCByb3V0ZXIgTVVTVCBOT1QgbWFrZQ0KICAgID4gICAgICA+ICAg IGFueSBhc3N1bXB0aW9uIGFib3V0IHRoZSB2YWxpZGF0aW9uIHNhdGUgb2YgdGhlIFVQREFURS4N CiAgICA+IA0KICAgID4gICAgICBUaGUgc2Vjb25kIHNlbnRlbmNlIGlzIGEgbm8tb3AsIHNvIGl0 IHdvdWxkIHByb2JhYmx5IGJlIGJldHRlciB0byByZW1vdmUgaXQuDQogICAgPiANCiAgICA+IFtv Yl0gV2UgYWRkZWQgdGhhdCBleGFjdCB3b3JkaW5nIGJlY2F1c2UgZHVyaW5nIDEwOCwgY29uY2Vy bnMgd2VyZSB2b2ljZWQgdGhhdA0KICAgID4gW29iXSBpbXBsZW1lbnRhdGlvbnMgY291bGQgaW50 ZXJwcmV0IHRoZSBhYnNlbmNlIG9mIHRoZSBjb21tdW5pdHkgc3RyaW5nIGFzIGENCiAgICA+IFtv Yl0gcGFydGljdWxhciB2YWxpZGF0aW9uIHJlc3VsdC4gVG8gcHJldmVudCB0aGlzIGZyb20gaGFw cGVuaW5nIHRoaXMgYWRkaXRpb24NCiAgICA+IFtvYl0gd2FzIHNwZWNpZmljYWxseSByZXF1ZXN0 ZWQuDQoNCiAgICByaWdodCwgbm90ZWQuICBJIG1pc3NlZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0 aGlzIGluIHRoZSBpZXRmIDEwOCANCiAgICBzaWRyb3BzIHNlc3Npb24uDQoNCiAgICA+IFtvYl0g UkZDIDgyMDUgY2xlYXJseSBzdGF0ZXMgdGhhdCBhIHJvdXRlciBjYW4gZGlmZmVyIGxvY2FsIHZh bGlkYXRpb24uIEEgZ29vZA0KICAgID4gW29iXSByZWFzb24gZm9yIHRoYXQgY291bGQgYmUgYSB0 ZW1wb3JhcnkgcmVzb3VyY2Ugc2hvcnRhZ2UuIEluIGJvdGggY2FzZXMgIzEgYW5kDQogICAgPiBb b2JdICMyLCBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBmb2xsb3dzIFJG QyA4MjA1Lg0KICAgID4gDQogICAgPiBbb2JdIE15IHVuZGVyc3RhbmRpbmcgd2FzIGFsd2F5cyB0 aGF0IGxvY2FsIHZhbGlkYXRpb24gdGFrZXMgcHJlY2VkZW5jZSBvdmVyDQogICAgPiBbb2JdIHRo ZSBjb21tdW5pdHkgdmFsdWUuDQoNCiAgICBCZW4gTWFkZGlzb24gYnJvdWdodCB1cCBpbXBsZW1l bnRhdGlvbiBkaWZmZXJlbmNlcyBhdCB0aGUgaWV0ZjEwOCANCiAgICBzZXNzaW9uLiBZb3UncmUg cmlnaHQgdGhhdCBpdCdzIHByb2JhYmx5IG9idmlvdXMgdG8gYW55b25lIG9uIHRoZSANCiAgICBT SURST1BTIFdHIHRoYXQgbmF0aXZlIEJHUHNlYyBldmFsdWF0aW9uIHNob3VsZCB0YWtlIHByZWNl ZGVuY2UsIGJ1dCANCiAgICBkZXZlbG9wZXJzIG9yIG90aGVyIHBlb3BsZSByZWFkaW5nIHRoZSBz cGVjcyBtYXkgbWFrZSBkaWZmZXJlbnQgDQogICAgZGVjaXNpb25zIGJlY2F1c2UgdGhleSdyZSBn b2luZyB0byBhcHByb2FjaCB0aGUgZG9jdW1lbnQgZnJvbSBhIA0KICAgIGRpZmZlcmVudCBwb2lu dCBvZiB2aWV3LiAgSXQgd291bGQgYmUgY2xlYXJlciB0byBtYWtlIHRoaXMgZXhwbGljaXQsIA0K ICAgIGUuZy4gdG8gYWRkIGEgc2luZ2xlIHNlbnRlbmNlIGluIHRoZSBEZXBsb3ltZW50IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24gDQogICAgdG8gc2F5Og0KDQogICAgIklmIHRoZSByZWNlaXZlZCB2 YWxpZGF0aW9uIHN0YXRlIG9mIGEgcm91dGUgZGlmZmVycyBmcm9tIGEgQkdQc2VjIA0KICAgIHZh bGlkYXRpb24gc3RhdGUgbG9jYWxseSBjb21wdXRlZCBhY2NvcmRpbmcgdG8gW1JGQzgyMDVdLCB0 aGVuIHRoZSANCiAgICBsb2NhbGx5IGNvbXB1dGVkIEJHUHNlYyB2YWxpZGF0aW9uIHN0YXRlIE1V U1QgYmUgdXNlZCBhbmQgdGhlIHJlY2VpdmVkIA0KICAgIHZhbGlkYXRpb24gc3RhdGUgTVVTVCBi ZSBpZ25vcmVkIi4NCg0KW29iXQ0KW29iXSBTb3VuZHMgZ29vZCwgSSdsbCBhZGQgdGhhdCB0byB0 aGUgZW5kIG9mIHRoZSAiZGVwbG95bWVudCBjb25zaWRlcmF0aW9uIg0KW29iXQ0KDQogICAgT24g YSBzZXBhcmF0ZSB0aGluZywgZ2V0dGluZyBiYWNrIHRvIGViZ3Agc3R1ZmYsIHRoZSBEZXBsb3lt ZW50IA0KICAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2F5czoNCg0KICAgID4gICAgRnVydGhl cm1vcmUsIG9uZSBjYW4gZW52aXNpb24gdGhhdCB0aGUgb3BlcmF0b3Igb2YgYSBCR1BzZWMgcm91 dGVyDQogICAgPiAgICBkZWNpZGVzIHRvIGRlZmVyIGxvY2FsIEJHUHNlYyB2YWxpZGF0aW9uIHdo ZW4gYSB2YWxpZGF0aW9uIHN0YXRlDQogICAgPiAgICB2YWx1ZSBpcyBsZWFybmVkIHZpYSBpQkdQ IG9yIGEgdHJ1c3RlZCBlQkdQIHBlZXIuDQoNCiAgICBUaGlzIG5lZWRzIHRvIGJlIHJld29yZGVk IGJlY2F1c2UgdGhlcmUgaXMgbm8gY29uY2VwdCBvZiAidHJ1c3RlZCBlQkdQIiANCiAgICBpbiBy ZmM0MzYwLiAgTWF5YmUgcmV3b3JkIGFzICIuLi4gd2hlbiBhIHZhbGlkYXRpb24gc3RhdGUgdmFs dWUgaXMgDQogICAgbGVhcm5lZCB2aWEgQkdQIiwgYW5kIGp1c3QgcmV2ZXJ0IHRvIHRoZSBkZWZh dWx0IGJlaGF2aW91ciBmcm9tIDQzNjA/DQoNCltvYl0NCltvYl0gQWdyZWVkLiBJdCBub3cgd2ls bCByZWFkOg0KW29iXQ0KW29iXSAgRnVydGhlcm1vcmUsIG9uZSBjYW4gZW52aXNpb24gdGhhdCB0 aGUgb3BlcmF0b3Igb2YgYSBCR1BzZWMgcm91dGVyIGRlY2lkZXMgDQpbb2JdICB0byBkZWZlciBs b2NhbCBCR1BzZWMgdmFsaWRhdGlvbiB3aGVuIGEgdmFsaWRhdGlvbiBzdGF0ZSB2YWx1ZSBpcyBs ZWFybmVkIA0KW3BiXSAgdmlhIEJHUC4NCltvYl0NCg0KICAgIGFsc28gbml0Og0KDQogICAgPiAg ICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBkcm9wICh3aXRob3V0IHByb2Nlc3NpbmcpIHRoZSBCR1Bz ZWMgcGF0aA0KICAgID4gICAgdmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkgaWYg cmVjZWl2ZWQgb3ZlciBhIHBlZXJpbmcNCiAgICA+ICAgIHNlc3Npb24gd2hlcmUgZWl0aGVyIHRo ZSB1c2FnZSBpcyBub3QgZW5hYmxlZCBvciBpdCBpcyBub3QgcGFydCBvZiBhDQogICAgPiAgICBC R1BzZWMgVVBEQVRFLg0KDQogICAgcy9wZWVyaW5nIHNlc3Npb24vQkdQIHNlc3Npb24vDQoNCltv Yl0NCltvYl0gQWdyZWVkLg0KW29iXQ0KDQogICAgTmljaw0KDQo= From nobody Fri Sep 25 16:46:37 2020 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 CA12F3A0BEE; Fri, 25 Sep 2020 16:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 aAAb4RQSJwGV; Fri, 25 Sep 2020 16:46:32 -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 BFCDA3A0BDB; Fri, 25 Sep 2020 16:46:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A96AFF40766; Fri, 25 Sep 2020 16:46:20 -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: <20200925234620.A96AFF40766@rfc-editor.org> Date: Fri, 25 Sep 2020 16:46:20 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8893_on_Resource_Public_Key_Infrastructu?= =?utf-8?q?re_=28RPKI=29_Origin_Validation_for_BGP_Export?= 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, 25 Sep 2020 23:46:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8893 Title: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export Author: R. Bush, R. Volk, J. Heitz Status: Standards Track Stream: IETF Date: September 2020 Mailbox: randy@psg.com, ietf@rewvolk.de, jheitz@cisco.com Pages: 5 Updates: RFC 6811 I-D Tag: draft-ietf-sidrops-ov-egress-04.txt URL: https://www.rfc-editor.org/info/rfc8893 DOI: 10.17487/RFC8893 A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. This document updates RFC 6811. 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 Fri Sep 25 19:19:19 2020 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 CF4DB3A0EA2; Fri, 25 Sep 2020 19:19:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <160108675080.9506.12588124331364773763@ietfa.amsl.com> Date: Fri, 25 Sep 2020 19:19:10 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt 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: Sat, 26 Sep 2020 02:19:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Validation State Signaling Authors : Oliver Borchert Doug Montgomery Daniel Kopp Filename : draft-sidrops-bgpsec-validation-signaling-05.txt Pages : 8 Date : 2020-09-25 Abstract: This document defines a new BGP non-transitive extended community to carry the BGPsec path validation state. BGP speakers that receive this community string can use the embedded BGPsec validation state in conjunction with configured local policies to influence their decision process. The ability to accept and act on BGPsec path validation state from a neighbor allows for a reduction of path validation processing load and/or increased resilience in the event that a router is temporarily unable to perform local path validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sidrops-bgpsec-validation-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05 https://datatracker.ietf.org/doc/html/draft-sidrops-bgpsec-validation-signaling-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-sidrops-bgpsec-validation-signaling-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 27 21:38:34 2020 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 1CA543A0E02; Sun, 27 Sep 2020 21:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LIo8fvga7fRr; Sun, 27 Sep 2020 21:38:31 -0700 (PDT) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831873A0DF7; Sun, 27 Sep 2020 21:38:31 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id D2F9A3C2224; Mon, 28 Sep 2020 04:38:29 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id A99D123D; Mon, 28 Sep 2020 04:38:29 +0000 (UTC) Date: Mon, 28 Sep 2020 04:38:29 +0000 Message-ID: <87imbybjne.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org,sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) 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, 28 Sep 2020 04:38:33 -0000 Howdy, Please consider this the start of a WG Adoption call for the subject draft, the abstract of which is: "This document defines a method for transferring RPKI validated cache update information in JSON object format over HTTPs." The URL of which is: https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 Please give this a read-through and consider if the work is appropriate for the WG to work on. thanks! -chris co-chair-persona From nobody Tue Sep 29 07:55:04 2020 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 096963A0E98 for ; Tue, 29 Sep 2020 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=nlnetlabs.nl 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 MfGf5inEZuPU for ; Tue, 29 Sep 2020 07:55:00 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8EB3A0E96 for ; Tue, 29 Sep 2020 07:55:00 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184] (unknown [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D5DEC1F448; Tue, 29 Sep 2020 16:54:58 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1601391298; bh=xtdC6Q/NY/1J7w+qFuKkdQredmfg5+Ujz8dhNpkl3jM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aDr08IfbiAs9G2epaK2dQdQpkvZcGwUbFtDjAH02NW1JcogAqCU+oq+pyPH6douDk mfUqFx4uBhQuX+4mwH0RTyt18yTOJvwP+fS8BQxvTTIsNJXcrZ1c/rvWdzR9tYc9IF BvkRJYYCK4tqJGtikUqHwyK6Ba3ZlMmiszZthVEo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> Date: Tue, 29 Sep 2020 16:54:58 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> To: Stephen Kent X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 14:55:02 -0000 Hi, On 7 Sep 2020, at 13:17, Tim Bruijnzeels wrote: >=20 >>>=20 >>> If we do go down this road then I think that we should also look at = the manifest object itself, and let it convey which object (types) are = critical (and while we are at it, we can specify types instead of using = filename extensions). That way future object types could introduced more = easily perhaps - this obviously needs more discussion but it could even = allow for semantics like: 1) new object please test, don't use, 2) new = objects, use if you can, 3) new objects, critical - fail if you don't = understand. >>=20 >> One could combine the new SIA URI and a revised manifest, in which = the manifest contains the per-object flag, rather than redefining the = basic object format to accommodate the flag. That would reduce the = number of RFCs that need to change. Good idea. >=20 > Upon reflection I realised that even the introduction of an SIA in the = issuing CA certificate will lead to issues. RPs would reject the CA = certificate, and as a result the whole PP of the parent CA. This means = that the SIA cannot be deployed without leaving a significant number of = RP installations behind. E.g. if I run a delegated CA under an RIR which = wants to adopt ASPA, and I get a new CA certificate with the additional = SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be = rejected. I have done some testing on this. Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for CA = certificates can be expected and can be ignored. And indeed it seems = that all current RP software will accept (and ignore) additional SIAs. At least that's the result from adding an extra SIA in a Krill branch = and running the end to end tests using the following validator versions: fortvalidator 1.4.0 OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700) rcynic version believed to be buildbot-1.0.1544679302 routinator 0.7.1 rpkiclient 6.7p1 rpkivalidator3 3.1-2020.08.06.14.39 I am still not very happy about the overhead that this approach implies: Additional publication points which need to be maintained, which may be = out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can = lead to serious operational impact if an announcement would be valid = under one, but not the other. It would also require much more fundamental code changes for producing = CAs - one cannot just support a new object type. One has to support an = additional publication model. Parent CAs have to be willing to include = the new SIAs as well affecting the ability to deploy for delegated CAs. But, at least it seems that it can be introduced without breaking things = immediately for existing deployed validators. Tim= From nobody Tue Sep 29 17:12:10 2020 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 79D0C3A142A for ; Tue, 29 Sep 2020 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, 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=verizon.net 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 6MBfyifY202s for ; Tue, 29 Sep 2020 17:12:07 -0700 (PDT) Received: from sonic301-1.consmr.mail.bf2.yahoo.com (sonic301-1.consmr.mail.bf2.yahoo.com [74.6.129.40]) (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 438B73A141C for ; Tue, 29 Sep 2020 17:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1601424726; bh=eBBMqUi7t/qhBHw6YKJr2sUH5fj3sj2NtoZ/YSBQZv8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=d/xAUMsIQfcf8tkMl7w25U4SHbFN1JMxB/zaOzSG7542iTB4W2NcMIFFXUvJLRHPTfCqcPHe/iqFqp+CBhlm3mveZDYEpw7BEtEbEt/8geP5ljYNO/mLdyO0SeIx0aMAl6a8vUHT5pBLKSnXvtAoihzUxALRBGhcdZw6z9QFE2YTGefmbuAOtDFfIhu/ufQmiCSVz732cMqzB4+xnC4mGISIXV3bpKkICKaDrZ56tiggl4QOw8kWaKhvXQyJQ+Lg+plsoHSz5k/1vld9VMGN4OWj3fygIpFQbvOJbSqMTCNBx/cor6NsACrxiEVuYRIIiDmomq2N6MNXHSVnjiyahg== X-YMail-OSG: cmQwGTIVM1nTbSa59vA3it6CnNYcMOaZxsEJiO1siaeEBk.OSjhzlqY8jPJl6TG Ray777OBlWJXHrwbGTdwJYZBgCjT1lOgHKvPPOFrPd_0M1t_FOGsOJxUoTA8rcHewRZ3JPqnVKXJ 4o1xWHVy0mEOzclvswp6.WcMAzdgJsh0yw2uOHv9.eE3YgysKd9NN3vGgw1o3O5j06MkdsJcwEci A3PHwqxSrofsIlt.sK9A8O_ZzJr5gmDLroLuD5ypDi_GAhzBfkszh9pxFrDKJFLPl6KTngKiTEmh vLX9sAbc1C6zMCmbACBelgkbpOoMWj_aWiESWokQechhP5yHsWZyQEdRF1DyVRhHfN6_lQziuXVb 20JaDDnv9sAUm930F.kVWWwHaDaxvWCgFHNzSuBQu5Y7yywmVvHy6jCd_DRlYBEnHaGG9OsRgPJO i9GlJDDTiz0pkERg0F8N.sOZbx7UzQaKzWYbN0pIdo8IIG6JiifuNXctWY9tnNdDcKFzMI6Zf.mK 6sUthfSz.Ckvla9uozrZC2_NMycNSsyMsJUCYEqBIsptMmmEaMoZwA2Z_.o7ZA4WesmfDu2LFoKM AffuUC1EjIlvvJqTwLKquqhMunUZLzIdZZKD2BSmoI.iD_NKzzqV69Qppi0hW7KX0PLkm50aDh8p rBRuBpCwQlb.Hnlzio0g0Kr8lV7hbOpGWxhOPkpRCmI2Ra0x1tXCbtn7oEceW6dkoqsx.THZG62N n6C0CwcRcRalLXdBUctyf5rJ0ZOL50bQemtRi43hRWefwiLt.3XIYgR.AFqPq.lu5XnmY3db7W.v n74q7csijvyT1ZyfjmboiOjLXmlKU_5G9C9oN95szfHTlyetXr3eQI9rPRZ4J1R9_ZP7trCRXCoE jelwDvDpDPnTLIZ5qQU0fDpsGS4m6xaUx65X7A0s0xYjpAfmLSHRHvkAUX7mphlYGe8Bl8cvqj5E 2ytqTXabXieq2MUwRdVH7Q5YhxrP2v05EDVVVmfO__eWBDwCqbo6HE_bnl1MyY8hmiPlxX3czxzY 7uwq_QJDkm7FV3_x_xILMmXebBDx9E2t6pqYT4PhPDN79liyTycO00zEuX3GyJw5VDEoqQ2crHnL AKnoVk.oYB.fq_vODhpsN5uZbQxrHXxA0miL9vAfsTvnQ812j6f3LO_5sj6kqkOAcKck5holySK6 QBO6mmz01ITJTtGxSR.4ZsBKQ0N0SbWzyxrXVCa87XiVzu1mQX3HQ7TKXkyqPIj9jgPauzIiWOx3 cA8iGpE9CsSumeTFluwZDqwxGZNehEx7xenRJ6G3V_nlFNwrnPhZn_7_5f_hCw_shoZxGikMAlT. 1E6uXWp4j1gZzB7Gl4hdCxOj6YnJ6lWFVdTEVEKSlu60pJTHgVZ88Q67uOfpo3CPSdHnZTD8mRUP GV4PBIGvLlrn89f_TXEq6QMTj2_jt1rzxlkr2z3bmTJFh1tGxuTHTXRzQL.5VXgDxsXbwAZrxPft _dAxklzwSRvwOFLSJvXPPnkY6hPtenU5hDKvFSmdXHRtjspFWuURUm.FOxbdQL9HaobVY_Si6O_Q XAVSxmFS8nEHlgfi.lEJO4Zb8UNknonXVbvnhS9ySQUxhrHP9KGmiHbTSWgYwz6B.Ce3L Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 30 Sep 2020 00:12:06 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 431e8c080fda51ece16e5ff2d143cdd5; Wed, 30 Sep 2020 00:12:02 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Tue, 29 Sep 2020 20:12:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16718 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 30 Sep 2020 00:12:09 -0000 Tim, Thanks for investigating the new SIA option. I'm not wedded to an alternate directory solution. A change to the Manifest structure to indicate how to process each named entry might be a good alternative. But, either approach will require a complex transition strategy that will take considerable effort to design and document. The WG needs to decide if the highest priority is to remove ambiguities from the current spec, or to pursue a new, substantially different spec. Hopefully the Thursday telecon will help clarify the priorities. Steve From nobody Tue Sep 29 20:32:26 2020 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 0117E3A0EFD; Tue, 29 Sep 2020 20:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5ygeboN8fDKc; Tue, 29 Sep 2020 20:32:16 -0700 (PDT) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF133A0F00; Tue, 29 Sep 2020 20:32:13 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 73A3E3C210A; Wed, 30 Sep 2020 03:32:12 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 4BB6F23D; Wed, 30 Sep 2020 03:32:12 +0000 (UTC) Date: Wed, 30 Sep 2020 03:32:12 +0000 Message-ID: <87h7rg3poj.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] Meeting Materials / WebEx linkage for tomorrow's meeting 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, 30 Sep 2020 03:32:25 -0000 Howdy folks! For some reason: https://ietf.webex.com/meet/sidrops didn't get included in the datatracker meeting info, I believe this will work fine for us, if not we'll organize a replacement via the mailing-list. Meeting materials should be updated shortly with the singular presentation. Hope to see you all tomorrow :) I hope we can move forward with teh -bis document discussion and return our discussion level back to a more respectful state. -chris From nobody Tue Sep 29 20:45:40 2020 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 A81DF3A0D4A; Tue, 29 Sep 2020 20:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 UMtvfwRkZ-YZ; Tue, 29 Sep 2020 20:45:36 -0700 (PDT) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500C23A0D41; Tue, 29 Sep 2020 20:45:36 -0700 (PDT) Received: from mail.ops-netman.net (mail.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 64E5E3C2197; Wed, 30 Sep 2020 03:45:35 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 223B123D; Wed, 30 Sep 2020 03:45:35 +0000 (UTC) Date: Wed, 30 Sep 2020 03:45:35 +0000 Message-ID: <87ft703p28.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org In-Reply-To: <87h7rg3poj.wl-morrowc@ops-netman.net> References: <87h7rg3poj.wl-morrowc@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Meeting Materials / WebEx linkage for tomorrow's meeting 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, 30 Sep 2020 03:45:38 -0000 On Wed, 30 Sep 2020 03:32:12 +0000, Christopher Morrow wrote: > > > Howdy folks! > For some reason: > https://ietf.webex.com/meet/sidrops > > didn't get included in the datatracker meeting info, I believe > this will work fine for us, if not we'll organize a replacement > via the mailing-list. > > Meeting materials should be updated shortly with the singular > presentation. > > Hope to see you all tomorrow :) I hope we can move forward phew! thursday I mean, which 'technically' is tomorrow :) I'll see if the datatracker page can get updated now to include webex linkage. -chris > with teh -bis document discussion and return our discussion > level back to a more respectful state. > > -chris From nobody Tue Sep 29 23:55:57 2020 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 D0EC73A1277 for ; Tue, 29 Sep 2020 23:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 QYmhMe3v2BmR for ; Tue, 29 Sep 2020 23:55:54 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 990403A1225 for ; Tue, 29 Sep 2020 23:55:54 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id d1so409669qtr.6 for ; Tue, 29 Sep 2020 23:55:54 -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 :content-transfer-encoding; bh=zmOIMYX6ldYOfW3B1BVxkF4DNtxzw8H5+Uz0Lq31J6Y=; b=VO481/DrcZv7Gnzftd3W+Uui1cOLiCUUNoVSXUVbh0442au+mLkQEptHbmhcmWD/U5 sLeUlXbNJXs1oI0N87zGudllWGF4JZMIJRQjBCoTOCfy/jl2mNijhWr8dq9U6MvhoE3w c6CS3MUlgqCjH2jud7tt5e2rqOkAZXZr1YMR66O8hI+N/UWXFCPJNuaLPPYgUshg/D+r GoIVZ2D1DQsmUqUHfOn4GTMzh5Y0EDcb2f0V8gOt4YVNPGKLpHd8iu5Qk5nrDa3M0nk2 gzjbiOWolIZvC49+PgF9zO2aGbEwuk6QM0t6tWCWZps5hFgXQ9q7uyCG2RkpS6fYkR0C Bsog== 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:content-transfer-encoding; bh=zmOIMYX6ldYOfW3B1BVxkF4DNtxzw8H5+Uz0Lq31J6Y=; b=Zoisd2ZlHFc1iNtIk3DTx0TG1hm+vDMlj9209W1lRYUwokt4XX8+j0Y9v+bKlt5RRm vzlsDbwDiOgUmRDpKk64FmMSqZoGoBOZCoGojgStaNVxondRrvA8Mg5DZEsqQpivDHTu LfOfQq/0xUnjHmiO4tligUZ3Rt2sLwfxYsEmNfxs5LRgHYZh9FzrvlHd9PIUzYZE8YH1 WVov/IBymeNTiMiY6/T396L+oBBzBLw2qRAypJJZTPGWRhnvJn1RLX/G8gjZXykWKylO qjmWpYy5t+ZEk2jf1QdZhM5nChjMgCg6VlnE2luakqlGwp/evJvXGoSkxf5ad8j1HBJ8 lvlQ== X-Gm-Message-State: AOAM532yoWFXg6lSCSQywFsMRGlwHKQhKIya3kHEvn3rwEkGDMGnwIak avmyGptatBSMSPKYFI2AA7DMcLwxYKC4cShx3tsMLMK11Os= X-Google-Smtp-Source: ABdhPJxVXvNdKexWOFG8tQQZtsfEyeJUOP+iFqQbM0kO0t1VuyQ/5FiH/oQ2HC/oDoZwd/Jyc3oDCOcDmIjMQuly/VQ= X-Received: by 2002:ac8:19a6:: with SMTP id u35mr769783qtj.315.1601448953275; Tue, 29 Sep 2020 23:55:53 -0700 (PDT) MIME-Version: 1.0 References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> In-Reply-To: <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> From: Christopher Morrow Date: Wed, 30 Sep 2020 02:55:42 -0400 Message-ID: To: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 30 Sep 2020 06:55:57 -0000 First, thanks! having some tested results on an optional path (for newly added types) seems cool. it's at least informed some of the conversation, which seemed to go a bit outside the original point of order (in my re-re-reading anyway) I think the salient points in the discussion are really (happy to be corrected, of course): 1) the -bis is proposing a simpler handling of publication point collecti= on. this simplicity is a bit at odds with some Internet principals (robustness principal), but trades this for very clear behaviors in the RP software. operations folk (myself, job, mikael though I missed his mail... others) were a bit concerned with the different flavors of 'correct' that can pop out the RP :( and see that being simpler about the flavors/options may make all/MOST RP get the same set of answers... predictability / consistency are nice. 2) the CA software and operations have to be very clear now about what is/not published, keeping in mind that mistakes in the CA Publication Point will have repercussions. Perhaps these need to be clearly articulated in the -bis draft? (more clearly?) This will, I think, clearly have impact on both CA / PP software and on operations of the CA / PP. I think this is good, actually as we're (sidrops folks i mean) attempting to push for: o closer compliance to consistency o more reliance upon the whole system o better overall security for the routing system 3) With the proposed simplicity/strictness comes some potential problems, at least: o problems in a CA / PP mean that CA / PP may not have their most updated information (routing intent) available o continual problems will lead to fallback to 'unknown' in the routing system o adding new object types seems difficult (just my reading so far) particularly there's a note about 'people won't upgrade their RP software' I think that the simplicity is a goal I would like to see achieved, specifically because inconsistent results in the RP set is problematic longer term. If we can get to more consistency before we roll a bunch more out we'll be able to course correct better/faster (I think). I think the idea that people won't upgrade... sure? maybe? Also: "Do you like killing kittens? because not managing your business critical systems a great way to kill kittens." We've been able to push more people into RPKI and better routing-intent hygiene, I don't see why we can't keep doing that and get folk to treat part of the routing system as critical to their business. We should not shy away from a solution just because we may have to convince people to upgrade. I look forward to the discussion tomorrow/thurs. -chris On Tue, Sep 29, 2020 at 10:55 AM Tim Bruijnzeels wrote: > > Hi, > > On 7 Sep 2020, at 13:17, Tim Bruijnzeels wrote: > > > >>> > >>> If we do go down this road then I think that we should also look at t= he manifest object itself, and let it convey which object (types) are criti= cal (and while we are at it, we can specify types instead of using filename= extensions). That way future object types could introduced more easily per= haps - this obviously needs more discussion but it could even allow for sem= antics like: 1) new object please test, don't use, 2) new objects, use if y= ou can, 3) new objects, critical - fail if you don't understand. > >> > >> One could combine the new SIA URI and a revised manifest, in which the= manifest contains the per-object flag, rather than redefining the basic ob= ject format to accommodate the flag. That would reduce the number of RFCs t= hat need to change. Good idea. > > > > Upon reflection I realised that even the introduction of an SIA in the = issuing CA certificate will lead to issues. RPs would reject the CA certifi= cate, and as a result the whole PP of the parent CA. This means that the SI= A cannot be deployed without leaving a significant number of RP installatio= ns behind. E.g. if I run a delegated CA under an RIR which wants to adopt A= SPA, and I get a new CA certificate with the additional SIA from my parent,= then 1000s (RIPE NCC >12k) other CAs will also be rejected. > > > I have done some testing on this. > > Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for CA = certificates can be expected and can be ignored. And indeed it seems that a= ll current RP software will accept (and ignore) additional SIAs. > > At least that's the result from adding an extra SIA in a Krill branch and= running the end to end tests using the following validator versions: > > fortvalidator 1.4.0 > OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700) > rcynic version believed to be buildbot-1.0.1544679302 > routinator 0.7.1 > rpkiclient 6.7p1 > rpkivalidator3 3.1-2020.08.06.14.39 > > I am still not very happy about the overhead that this approach implies: > > Additional publication points which need to be maintained, which may be o= ut of sync. What if MFT A has a certain ROA and MFT B doesn't? This can lea= d to serious operational impact if an announcement would be valid under one= , but not the other. > > It would also require much more fundamental code changes for producing CA= s - one cannot just support a new object type. One has to support an additi= onal publication model. Parent CAs have to be willing to include the new SI= As as well affecting the ability to deploy for delegated CAs. > > But, at least it seems that it can be introduced without breaking things = immediately for existing deployed validators. > > Tim > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Sep 30 07:10:44 2020 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 78F713A09EF for ; Wed, 30 Sep 2020 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0r8faZ13BTjt for ; Wed, 30 Sep 2020 07:10:40 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592033A09EC for ; Wed, 30 Sep 2020 07:10:40 -0700 (PDT) Received: from bench.sobornost.net (sobornost.connected.by.freedominter.net [45.155.156.99]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id CE46F22012E; Wed, 30 Sep 2020 14:10:38 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id af600535; Wed, 30 Sep 2020 14:10:36 +0000 (UTC) Date: Wed, 30 Sep 2020 14:10:36 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20200930141036.GD13264@bench.sobornost.net> References: <160108675080.9506.12588124331364773763@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160108675080.9506.12588124331364773763@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-sidrops-bgpsec-validation-signaling-05.txt 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, 30 Sep 2020 14:10:42 -0000 Dear all, I have reviewed the document and would like to offer some feedback. The title probably should read "BGPsec Validation State Signaling via Internal BGP" Furthermore the document probably benefits replacing "BGP neighbor" with "IBGP neighbor", similarly "BGP peer" and "peer" should be replaced with "IBGP neighbor" and "neighbor" for more consistent reading. Emphasis on IBGP is important as this document outlines non-transitive extended communities. (Let's park discussion about EBGP vs CONFED vs IBGP for the sake of progressing conversation about the substance of this draft) Internal inconsistency in draft-sidrops-bgpsec-validation-signaling ------------------------------------------------------------------- RFC 8205 section 5.1 states "BGPsec validation need only be performed at the eBGP edge.", and also "a BGPsec speaker MAY temporarily defer validation of incoming UPDATE messages." With the above in mind, in section 4 of draft-sidrops-bgpsec-validation-signaling the first paragraph references an EBGP speaker that received a BGPsec UPDATE from a neighbor outside the administrative domain. If one follows the logical outcomes of temporarily deferment of validation, the EBGP node was unable to perform BGPsec path validation, thus MUST set validation state 'Unverified'. Consequently the BGP UPDATE is distributed to IBGP speakers, which all have to perform full BGPsec path validation in order to confirm that the validation state is indeed "Unverified". One might as well not attach any community at all because speaker A doesn't signal of note - because it doesn't know. If the EBGP edge device that (temporarily or forever) is unable to do BGPsec validation, it will for the duration of that event be unable to set the appropriate community, as it cannot validate. Whatever communities it sets, other nodes in the network still need to verify whether or not the community is true. As such, the communities are merely overhead. Imagine a two node network (ascii art, mind your MUA): +--------+ |AS 65123| +----+---+ | +------+----+ +--EBGP1---+ AS 650001 +----------------EBGP2------+ | +-----------+ | | | | +-----------------------------------+ | | | AS 65666 running draft-signaling | | | | | | | | +---------------+ | | +----------+ BGP speaker A |****IBGP | | | +---------------+ * | | | * | | | +-------*-------+ | | | | BGP Speaker B +---------+ | +---------------+ | | | +-----------------------------------+ If BGP speaker A cannot perform BGPsec validation on EBGP1, it can't confirm whether _65001_65123$ is a valid BGPSec_PATH or not. But whatever conclusion speaker A draws, speaker B receives the _650001_65123$ path via its own EBGP2 session with 650001. Whatever validation (and signaling) happens via the IBGP session, it does not in any way positively impact speaker B's decisions, as speaker B can't use IBGP information as input into its decision making process regarding the BGP UPDATE received via EBGP2. Draft-sidrops-bgpsec-validation-signaling is not a replacement or alternative to the RPKI-To-Router protocol. If the meaning of the 'unverified' state is 'maybe I will do validation later, maybe not', I don't see any practical application. If the meaning of 'valid' is to be taken at face value, again, there is no value in a standardized community, see RFC 3514. If the meaning of 'invalid' is that following BGPsec path validation the route is deemed invalid, then why was it propagated in the first place? If Speaker B is not able to do Path Validation, whatever 'invalid' signal it receives on its IBGP session does not and cannot override or influence what was received via EBGP2. The text in the abstract and introduction about 'temporarily deferment of validation' should probably be removed as it is hard to see how in the situation of temporarily deferment the existence of these communities makes sense. Undeployability --------------- An architectural choice to use BGP communities for any purpose oftentimes stems from an operator's ability to deploy 'a new thing' in a network where (part of) the nodes have not yet been upgraded. Good useful examples of this mechanism are GRACEFUL_SHUTDOWN and NO_EXPORT. The document states in section 3 "If the router supports the extension as defined in this document" ... which implies that all nodes in an administrative domain must be upgraded, which in turn somewhat nullifies the justification to use communities in the first place. This doesn't allow a brownfield upgrade! Section 3.1 "Error Handling at Peers" reads as a simple paragraph, but is brittle and error-prone to implement in routing policy. Most network operators are accustomed to implementing a 'test & branch' procedure by positive community matching and then taking some action. RFC 1997 defines communities as "A community is a group of destinations which share some common property." The implication is that when multiple communities are attached to a route, the route simply has multiple properties. However, this document outlines a mechanism where specific combinations of communities are invalid input: "(0x43,TBD,0) ∩ (0x43,TBD,1)", or "(0x43,TBD,1) ∩ (0x43,TBD,2)", or "(0x43,TBD,2) ∩ (0x43,TBD,0)". In currently available commercial|free-of-the-shelf BGP implementations implementing adequate error handling is error-prone. RFC 8097 shares this weakness. The Introduction proposes that a reduction of path validation processing load can be achieved, however Section 4 states that if there is a discrepancy between the locally computed validation state and the community, the locally computed state takes precedence. Thus, no load processing reduction can be achieved because a BGPsec capable node must compute the validation state before it can compare it to the community. Not analogous to RFC 8097 ------------------------- To many this draft may appear as 'for sure, we need something similar for bgpsec as we have for route origin validation' - but I think no such equivalence exists, or needs to exist. RFC 8097 defines a set of BGP communities which can optionally be associated with a prefix *after* the Origin Validation procedure (RFC 6811) *successfully* is executed. This in contrast to draft-bgpsec-validation-signaling, where a node is *unable* to path validation, thus can never set the appropriate communities. RFC 8097 does not describe a situation where Origin Validation is temporarily deferred. Reject don't tag (do, don't talk about doing it) ------------------------------------------------ If a route is considered invalid (for whatever reason, beauty is in the eye of the beholder), the route should be rejected. Merely tagging an invalid route with a specific community and propagating it further, is a useless excercise. Such designs hampers deployment of actual security measures. If an operator wants to tag invalid routes for analytical purposes, they can easily do so and can choose from milions of values using any of the flavors of communities that are available. If you *are* propagating an invalid route, you are propagating an invalid route - in which case it does not matter whatever communities are attached to it. Conclusion ---------- At this point in time I don't think this draft can proceed to publication, from the document itself it is not clear to me what benefits can be achieved and how this benefits Internet operations. The draft requires new code on devices in addition to what a BGPsec capable implementation would require. And in today's world there aren't off-the-shelf BGPsec implementations to start with, so piling on additional code requirements is too early in the innovation cycle anyhow. Using communities is no substitute for BGPsec validation or for RTR, this document may subtly lead people to believe otherwise. It is possible I misunderstood things, I look forward to feedback from the group. Kind regards, Job ps. nitpick: one of the author's company names seems misspelled. On Fri, Sep 25, 2020 at 07:19:10PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : BGPsec Validation State Signaling > Authors : Oliver Borchert > Doug Montgomery > Daniel Kopp > Filename : draft-sidrops-bgpsec-validation-signaling-05.txt > Pages : 8 > Date : 2020-09-25 > > Abstract: > This document defines a new BGP non-transitive extended community to > carry the BGPsec path validation state. BGP speakers that receive > this community string can use the embedded BGPsec validation state in > conjunction with configured local policies to influence their > decision process. The ability to accept and act on BGPsec path > validation state from a neighbor allows for a reduction of path > validation processing load and/or increased resilience in the event > that a router is temporarily unable to perform local path validation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-sidrops-bgpsec-validation-signaling/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05 > https://datatracker.ietf.org/doc/html/draft-sidrops-bgpsec-validation-signaling-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-sidrops-bgpsec-validation-signaling-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Sep 30 07:36:01 2020 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 B53D63A09F1 for ; Wed, 30 Sep 2020 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 nvrDskpWYdKq for ; Wed, 30 Sep 2020 07:35:57 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2054.outbound.protection.outlook.com [40.107.236.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64F23A0972 for ; Wed, 30 Sep 2020 07:35:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TS2Qs7bjy3luQIl6yGSniNOZEydykkH6pSIAYrXJHbnylH1sno1nkCoT2GKlM2h83MYU0UJI5S45QGJ+Zct8fNjXNIiTQPyFbCA/8Vnc9ciAPpRXEpRcob3lleRrU2ks1EYSvk2rEusILpAwq38SpmJFpMVNdG2OlzhcfPo7sJJi3Jn0X8ZdLhnsEUlj+EbkzXzdVgM1cDTkKH3qiGqlewC8gCiK0HPKUsjWQW/uVSHpp3YcixveeEfPXzDXK8TlLeJj4+KXI2YVJxB9zgZRPcqEHeGFJfsXhoT8jvOYWA2TL91hwdIpMlJ0yLbEgdpVOtFHjREB1p1jAaZxGPu3zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v5+iy+n0hGr6U88S5MUvrDtbbG6nQ0cAaP3HFZrcTKM=; b=A53Y8oEYJxqtabHkTL0snIHI/l98CXydtX3ZafI2ZlaIo9R4xPA8DW/4Eq08e3kY3VRUxEj6kh7hJb6q/pVTohVUq1Sk0ygq0fAavldI8jUqoRQtkkc3c/wWZpaHme3Ntz8eCydShxqaZEvPXE3evqJxVVN+J4dO6OB6FMzb7u1L0uouUnWeIfulAFP6uQMoY9W38En2CGiqyhzIgdFm0WhPmeaBqJAbcZhSHMoldPdLvL/y496N++7abjM0YGZKT18q7txv++v481YW93BG308+isib8vz9vNCxIGFXB5zNixWMjMiPUnfdbM6chIVmtOY+7eNRGoOkW4K3Euw3uw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v5+iy+n0hGr6U88S5MUvrDtbbG6nQ0cAaP3HFZrcTKM=; b=O/1jdMEfcRgN+vXFBhkV2iZWM5e6I3pHYOVbGGU6nWrh5XEBeMAg5zJ+nxa65AAowHZBMZKSzDXe2Acey4L26yMJnyN3QRjp5XLQS044aQ/6r01vzrLRLeG5tiYG2tGVp8TSHaflDKCuT0HTkeM+PwJcG8DK6vu8w7RcP5KTUQM= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2757.namprd18.prod.outlook.com (2603:10b6:a03:105::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.25; Wed, 30 Sep 2020 14:35:49 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::8d49:9af8:4eb:4e2d%7]) with mapi id 15.20.3412.029; Wed, 30 Sep 2020 14:35:49 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - ends 7/October/2020 Thread-Index: AQHWlzb95DC7OptzsUa+NCnFxWBrKA== Date: Wed, 30 Sep 2020 14:35:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10da71ae-f298-4f74-6526-08d8654e204b x-ms-traffictypediagnostic: BYAPR18MB2757: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +kwlCi8YaltrQy9neIX+7lhH0E1Hgz2fWmfpCnHgEsYE6InJk/Eb1r3Pyhv7XVwhGs6A3e1XslRXa93QOH+s08mm4pp/iq2PDddaiNppGQYmywTdDmNWJFU/mf0JtVoci2jRKqDK5oOAqQGVvMFahcJAYsufNsbqpJmIzQ4ILI1zY+KS2TOf66u5UWPp7YxjbP6cjFGoHz5I3mv7v9oJs9xYMRjJkUDhMr6tluTYIhkzPMWCCHY/KThsQXgFw1v3bjjOB4QqS8aCBq9TfyH8Yjbyp+/Ol7J9nf0EY00vG0I9PAoblCEtcNOx8VNCpRnU/qWc1s/iLG3MlN3OuutBkOT1VnORz99hkMkAGcjbH3/5cwwXhReW0H2AIR/NrWFyOOWPa0MIp4megGrgTHxYJNvkVrGXFfuOeyjOGPs2pvz1IfUc+zRukseoW0hsilAD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(366004)(396003)(376002)(346002)(136003)(6486002)(8936002)(5660300002)(53546011)(26005)(66476007)(66446008)(64756008)(66556008)(6506007)(6916009)(71200400001)(8676002)(36756003)(66946007)(2906002)(76116006)(9326002)(316002)(186003)(2616005)(478600001)(966005)(86362001)(6512007)(83380400001)(166002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZbLBQBB5fASTdJMtbliGu8m2ZsybA9rDeeW8sxgd9906ETAOelpXNm2wFwdwKap1iQSkzadSM0zBq4/nSjQA8A1Gep88x5okpZZnerixU26e7yr3k9eGmaWGYQyhicFQjyH8gkqVE/cmsGNhRzZ6HCsnZIA63tyF28d6EM6Uc9gumpNiMfCe7S700iMnpPjkdZ8L4kP8kH8TDKeZEGGaLeFUc1xHNNM+HXHFPlUxnCcX4Gx4y4h3MSfCIg9OFNBblq9hQTweWEQHD+JpoEisFkOlZAkvMWRGlJEwt4q1uNli0dpKOCtvLY1GcpIHZNfSdELgyk8Pr6GnbfAxKyZ5Xzx4KqV4Zz76sl+yWlljOmG+gdi3mlxyGT6k6YOWSEn/KrvmR3YzcuGJ69TXSOll/fNGpYV2UfqaD/8ShLT2YsNtKWEuqeNIIUaKWdizJxMbncIg8sGLU0JoR/rfbO5DmqFjbykEdNrfveqNFZvIpbwSxPe7N3jhSz2dlUGAyxvMEev0sgezYRh2WcWXDpeWr0caQWmeLympz8zsxIPubVuR+CAo5ikWUpSsrU58qo+j9k3TrJQDywo3F3ob+PbmChk80jS0FMWTvDrDtEF/LGtJyvw0smAlJM2Zyrxb5WPA+9mhqBlCdFnQ2sg+Lrx08Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A61CD822F9EF48E9817723D16970DBADarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10da71ae-f298-4f74-6526-08d8654e204b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2020 14:35:49.4073 (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: WIfRDQdxFYI+Z/FSZiXQ13jY4ROsKwdGTBULaKgNH9Z1UTQ5srB5IL3OmjGOiIeoIhlz6Xq//spRz5z8B7lMrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2757 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - ends 7/October/2020 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, 30 Sep 2020 14:35:59 -0000 --_000_A61CD822F9EF48E9817723D16970DBADarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClRoZSB1cGRhdGUgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaW5jb3Jwb3JhdGlu ZyBhbGwgdGhlIHByZXZpb3VzIGNvbW1lbnRzIHdhcyBwdWJsaXNoZWQgdG9kYXkgYW5kIGNhbiBi ZSBmb3VuZCBhdDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdw c2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1LiBUaGUgd2cgY2hhaXJzIGV4dGVuZGVkIHRoZSBj YWxsIGZvciBhIHdlZWsuIFRoZSBXR0xDIHdpbGwgbm93IGVuZCBvbiBPY3RvYmVyIDcsIDIwMjAu DQoNCkJlc3QgUmVnYXJkcywNCktleXVyDQoNCkZyb206IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPg0K RGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciAxMCwgMjAyMCBhdCAxMDoyNyBBTQ0KVG86ICJzaWRy b3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbU2lkcm9wc10g W1dHTENdIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIC0gZW5k cyAxNy9TZXB0ZW1iZXIvMjAyMA0KDQpIaSBGb2xrcywNCg0KVGhlIHdnIGNoYWlycyBleHRlbmRl ZCB0aGUgY2FsbCBmb3IgYSB3ZWVrIGluIGhvcGVzIHRoYXQgd2Ugd291bGQgaGF2ZSBhIGNvbnNl bnN1cy4gU2VlbXMgbGlrZSBtb3JlIGRpc2N1c3Npb24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFu IGV4dGVuZCB0aGUgY2FsbCBmb3IgMSBtb3JlIHdlZWsuIFRoZSBXR0xDIHdpbGwgbm93IGVuZCBv biBTZXB0ZW1iZXIgMTcsIDIwMjANCg0KQmVzdCBSZWdhcmRzLA0KS2V5dXINCg0KRnJvbTogS2V5 dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRlOiBUdWVzZGF5LCBBdWd1c3QgMTEsIDIw MjAgYXQgMTE6NDUgQU0NClRvOiAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxp bmctMDMgLSBlbmRzIDI1L0F1Z3VzdC8yMDIwDQoNCkhpIEZvbGtzOg0KDQpBIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtc2lkcm9wcy1iZ3BzZWMt dmFsaWRhdGlvbi1zaWduYWxpbmctMDMsIOKAnEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25h bGluZ+KAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhl IFdHTEMgd2lsbCBlbmQgb24gQXVndXN0IDI1LCAyMDIwLg0KDQpUaGUgZHJhZnQgY2FuIGJlIGZv dW5kIGF0OiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2Vj LXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzLiAgQXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRp bmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBi ZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCktleXVyDQoNCg== --_000_A61CD822F9EF48E9817723D16970DBADarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZvbGtzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgdXBkYXRlIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGluY29ycG9yYXRpbmcgYWxs IHRoZSBwcmV2aW91cyBjb21tZW50cyB3YXMgcHVibGlzaGVkIHRvZGF5IGFuZCBjYW4gYmUgZm91 bmQgYXQ6DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9w cy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUiIHRpdGxlPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss c2VyaWY7Y29sb3I6Ymx1ZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJv cHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1PC9zcGFuPjwvYT4uPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+VGhlIHdnIGNoYWlycyBleHRlbmRlZCB0aGUgY2Fs bCBmb3IgYSB3ZWVrLg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGU8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53aWxsIG5vdyBlbmQgb24gT2N0b2JlciA3 LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V5dXI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlNpZHJvcHMgJmx0O3NpZHJvcHMtYm91bmNlc0BpZXRm Lm9yZyZndDsgb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDIwIGF0IDEwOjI3 IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRy b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1NpZHJvcHNdIFtXR0xD XSBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyAtIGVuZHMgMTcv U2VwdGVtYmVyLzIwMjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZvbGtzLDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQg dGhlIGNhbGwgZm9yIGEgd2VlayBpbiBob3BlcyB0aGF0IHdlIHdvdWxkIGhhdmUgYSBjb25zZW5z dXMuIFNlZW1zIGxpa2UgbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZCBhbmQgc28gd2UgcGxhbiBl eHRlbmQgdGhlIGNhbGwgZm9yIDEgbW9yZSB3ZWVrLg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5UaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V0dM QzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53aWxsIG5v dyBlbmQgb24gU2VwdGVtYmVyIDE3LCAyMDIwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXl1 cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5LZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgQXVndXN0IDExLCAyMDIwIGF0IDExOjQ1IEFNPGJyPg0KPGI+VG86 IDwvYj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRh dGlvbi1zaWduYWxpbmctMDMgLSBlbmRzIDI1L0F1Z3VzdC8yMDIwPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRy YWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzLCDigJxCR1BzZWMgVmFs aWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRo IHlvdXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPndpbGwNCiBlbmQgb24gQXVndXN0IDI1LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxp ZGF0aW9uLXNpZ25hbGluZy0wMyIgdGl0bGU9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5n LTAzPC9hPjwvc3Bhbj4uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5n IHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVl biBkaXNjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A61CD822F9EF48E9817723D16970DBADarrcuscom_-- From nobody Wed Sep 30 09:51:07 2020 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 480063A0CDF for ; Wed, 30 Sep 2020 09:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.20150623.gappssmtp.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 oaGlaccxK4xM for ; Wed, 30 Sep 2020 09:50:58 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 E8B813A0D1E for ; Wed, 30 Sep 2020 09:50:56 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id w7so1576745pfi.4 for ; Wed, 30 Sep 2020 09:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mAcKQ0psNZe+lbS+lFho3YIcchh9/I5QM1oZeBLI3UA=; b=Ekx6FVN/ZVD2WQ9YauOHooQvx8RCSUwMUIMem1YgWWIVlT9NGsHp/etYO2BaHbuiie PZbq0uleHnRWG4IB8TLiM/SANc3kFt41t7T2sWlcWfP1BKP7b6jKEEwVRAbSquK4Q308 X3fjYNfh2Bab5yXdzIlMqrA6leGftPq9hQYsOq/yL613lQFj5Sg+6hTyxnJsaKXyBFQ5 3Kzvoko6BcsfDIXYeDfXW6HEKJdmkQQAHyBJuWfLZMoWh3koGTK0MFU1WaJ66ONa17KA Ru+WumcfWUK/A7TxmHTP+fUOkxrq58ZV7EFg0gjciWBKNcTYBuouWJNu6kdlNMNG19G8 BRZQ== 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=mAcKQ0psNZe+lbS+lFho3YIcchh9/I5QM1oZeBLI3UA=; b=ejd1jV7WuO90cmLc7EcB8C/oIraTQL4Tu52zqhWpIww43L5EitaLLBw5xjjy/WXAd0 3i9mAQJcyoyA8uH5WZi89HOrkxPyoxzYHM1VM8dDdbuxVj4ewkqULGXpEG5gYG0XWwDP sEx8lgJXOwnolWJe1GNdaKKiDmYQSlo4kUchire2jPVf6fP10nRu0vnhu8Idj6HyoYUE sQUzCuTyf0risItxI2pMsSetnPE4HOWz27T9k0v+EwCyHB/cwgI9iyb0uTPvu3twgHrW VzQK3faPQlConzA9BClf/03c62tUpYBwtiUo0tHxmy/j//bI3SipjMHguQdiBqybdpyx yhxQ== X-Gm-Message-State: AOAM530LSnVPnAbzl5s7vWuqWRVzOcJ19WFqd97+OhqTv66CO7flSuCX yGyZHeBMiHXVG5L5mLNM/pxAamn1GyM8davCeQs3fw== X-Google-Smtp-Source: ABdhPJw1/W+ZZXXLD+Fw+QPBSVGIPrV8wmi7r4Mil0u1mKhwk6HOGAxVul1lLHpwSRPI2EV0M8Sbm8dvbSc7GjXxhYY= X-Received: by 2002:aa7:9ad6:0:b029:142:2501:3975 with SMTP id x22-20020aa79ad60000b029014225013975mr3360109pfp.58.1601484656073; Wed, 30 Sep 2020 09:50:56 -0700 (PDT) MIME-Version: 1.0 References: <87imbybjne.wl-morrowc@ops-netman.net> In-Reply-To: <87imbybjne.wl-morrowc@ops-netman.net> From: Melchior Aelmans Date: Wed, 30 Sep 2020 18:50:45 +0200 Message-ID: To: Chris Morrow Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="00000000000009f0f305b08ab4ce" Archived-At: Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th) 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, 30 Sep 2020 16:51:07 -0000 --00000000000009f0f305b08ab4ce Content-Type: text/plain; charset="UTF-8" As a co-author I support adoption by the WG. THanks! Melchior On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow wrote: > > Howdy, > > Please consider this the start of a WG Adoption call for the subject > draft, the abstract of which is: > > "This document defines a method for transferring RPKI validated cache > update information in JSON object format over HTTPs." > > The URL of which is: > https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02 > > Please give this a read-through and consider if the work is appropriate > for the WG to work on. > > thanks! > -chris > co-chair-persona > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000009f0f305b08ab4ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a co-author I support adoption by the = WG.

THanks!
Melchior

On Mon, Sep 28, 2020 at 6:3= 8 AM Chris Morrow <morrowc@ops= -netman.net> wrote:

Howdy,

Please consider this the start of a WG Adoption call for the subject
draft, the abstract of which is:

=C2=A0 "This document defines a method for transferring RPKI validated= cache
=C2=A0 =C2=A0update information in JSON object format over HTTPs."

The URL of which is:
=C2=A0 https://datatracker.ietf.org/= doc/html/draft-madi-sidrops-rush-02

Please give this a read-through and consider if the work is appropriate
for the WG to work on.

thanks!
-chris
co-chair-persona

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000009f0f305b08ab4ce-- From nobody Wed Sep 30 13:51:18 2020 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 22FB63A0B8C for ; Wed, 30 Sep 2020 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.998, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 ayCSdjY3AzBX for ; Wed, 30 Sep 2020 13:51:13 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2116.outbound.protection.outlook.com [40.107.89.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68CF3A0BAE for ; Wed, 30 Sep 2020 13:51:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mj+FcEAqLQqlb9utH7mPUUkqscx8UK+EGtn1OLMa7VhN0bn/+v83FYzwRkONGmDcD+8czpFyMlo2mpC/ht7QeSIhrcQiWmpzdU5DiCezTgL8vxc/lwTMDUIm1tcadl6cOtQ6BA9oo4BTQXzT59BQJY3JQir8p7g8WSbQ4RMw+upV/XxIeGAnxJS9a49HXbwok7VD7putcf8eTVnZlxq6a1b1f7WMbrq6otp9OcGzzhoIRyXzDvzuCvGZetNikGTlc0BWHkWbZg+k4HjYg+viAyk5tS4RSZU+GnOIM3LDw/ajmkFsIVJT8hl2jdiCHT00TmWrOeuqu0MnoqTEFXoB/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tryMUnUsTpVk3XNW836rG3i9UmnBSjPZWa5fJxBf/Jg=; b=oXXd2pMCdlsSgWCibro+wFtWh6Y+/HgtP6hyfZGvTlAdVdrRK+Lg8p6h9nxC2yexTJXklQW2lB3ZB9JwwJZWQ51nwp5z8zB8p6RbSS/C/FcPZKDRdm4yeLEwk7bSJXZQLVnkLkgoMXQyJMrs1RM1N6ShqHjbOBBGFiw4KJqrTF2W9BAuS99hsCPVRCeT3qpABJCbFb0dlnCTYYYeZc0aAMynPp9pqlSZYi2EUxbsHe6B2a1rNKsG2LR5u0U1pVXbxwOyeLdEv6sEsW5PdmeBlLZaYKGvJT/lfOND1C4XZupWpHHlGbECzYnyegTQmyuT+WWG2hlGyFwe0pCvrJWBNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tryMUnUsTpVk3XNW836rG3i9UmnBSjPZWa5fJxBf/Jg=; b=tlrNaWzhkAuSqt13VT1yDjzjTL+9t1wZQ3FiuY4hPoHR3j/HMu7ChBGBWzr8vbwZWFJSPP/bjDvEqyJrJeK7AyCaNSjFjiJ6hVlfVCrzThNclg1xQlij9E5XDiTT3sD7e1K5rdNtbFfUrdnbBFIVnBUy8Yu1bZtvuTielA49b1Q= Received: from DM8PR09MB6967.namprd09.prod.outlook.com (2603:10b6:5:2e1::23) by DM8PR09MB6550.namprd09.prod.outlook.com (2603:10b6:5:2f0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Wed, 30 Sep 2020 20:51:10 +0000 Received: from DM8PR09MB6967.namprd09.prod.outlook.com ([fe80::453b:8416:ceed:8f5f]) by DM8PR09MB6967.namprd09.prod.outlook.com ([fe80::453b:8416:ceed:8f5f%6]) with mapi id 15.20.3433.032; Wed, 30 Sep 2020 20:51:10 +0000 From: "Borchert, Oliver (Fed)" To: Keyur Patel , "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - ends 7/October/2020 Thread-Index: AQHWlzb95DC7OptzsUa+NCnFxWBrKKmBZV0A Date: Wed, 30 Sep 2020 20:51:10 +0000 Message-ID: <430A30DA-D664-4A27-B5CE-E405A372724B@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [96.231.25.2] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2f8bbc1e-72f8-4950-9ba5-08d865828ff7 x-ms-traffictypediagnostic: DM8PR09MB6550: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ACR0LJv8a46u5ofXPyKNuvpq0xZxAjbf4UwhRg/UhViMeeao44copjbQBg4SzoIocXrajksdrRpO3ImJ+AOeRhxD1Md/dRw9utaUIzlHZi0vf/smo+OaPrxIVsQBLA8WMfBpSiw6PX2CPEgvzd1nMIe0HTLZlGC0eH29Tyum76VZD9U+Xa6rYkJzESZcp8MdlHmi9Dkhj66WYSC1KIO7BUZFuMITCRXbA8Z1wFi2h8QlIEm26K3LySqZOtbfYG8oUGdfZCujpzB5XUpBYKAgR8Y7nS7iXGleHglxvmDpPAWZR/jCJcrbG1nwTLUpUnWap0AX+8sioI3rHP/i0eW4zLZNJt+W2Iquz+XCguRRixFOOlkoNfBLoVTTWJL+ztnLhcFJDaKSEi7sOJsVVtISL/S6SdiFbRq1X3uNrWSDqbSxaGyJGbgzlBYZiue/C/xk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR09MB6967.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(166002)(2906002)(107886003)(6512007)(966005)(6486002)(71200400001)(66556008)(86362001)(66446008)(66476007)(64756008)(4326008)(83380400001)(36756003)(8936002)(186003)(76116006)(91956017)(66946007)(316002)(6506007)(2616005)(26005)(33656002)(110136005)(53546011)(478600001)(8676002)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: pBcb9iNjelbzRsd4kvf7btxoLZDZImhYiit5lVatlpq0jaR4UrZFTZaRK2ZhDkZmDw8qyJX2Vxzm+6IeyiFZG9TmXsXzxKyBCmzCL3K/buvUGgGdq15HHraY4axx1/C068FLOshQbjCAWayuHp2LuAOKa09YcCw0HiCq+KxKA2I1yXIEbIsFt1MI+USxv47116mYX6V/rnKXkwVHyqxWzo5sCjUDgteXj5KO4bdMvKPLtdKdXQmGD1sYvs/NzlqCG0QFez6y7sVxKNT96r1dm1W5XCBpGpj0n+EhFzkrkdEUUT7manPd0l5htiu9DdKnYBnl7ZhzJdKnlLqTY3XZ9lAVJLJV0ABqNmTxIhX+8/yoFoInsdDKq0a2XAhGdzF/jTmxXkMxq5QoRutjQggihCInZyxrL+o7Y7AWJ0pthSrvly6FLIpvfGZEYHTnshKsbsc2ytf6HmanCZpEwalImGrv/ZBxLChClV6Y3AKDV4XitsovvQMsw7tVMt0KIzJOp5gsvkOog7o2MEHKbftE+EI3Wdd0aVCwIXXHdaZWDxhJhBlK9Soi217IPYad5TSeO5H2FMNfcPmXdHEV7YnWMe7hitlonMfVi4ybfRW42yKw688fkQhdF5Otus4F4XEM//kO6AqZLgdPF4KwCyxB0g== Content-Type: multipart/alternative; boundary="_000_430A30DAD6644A27B5CEE405A372724Bnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR09MB6967.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f8bbc1e-72f8-4950-9ba5-08d865828ff7 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2020 20:51:10.6974 (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: LDKXe3GMKfCE+SvcPcPTCj4+gv6ii3UZZUp4AlnHANt0ki3r0oOyrsaHGzZIkvnB7NjYZi30mJFl6Y43XIRhkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR09MB6550 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - ends 7/October/2020 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, 30 Sep 2020 20:51:17 -0000 --_000_430A30DAD6644A27B5CEE405A372724Bnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2V5dXIsDQpUaGFua3MsIEkgcGxhbiB0byBhdHRlbmQgdG9tb3Jyb3figJlzIGludGVyaW0gaW4g Y2FzZSBzb21lb25lIGhhcyBmdXJ0aGVyIHF1ZXN0aW9ucywNCg0KT2xpdmVyDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQs IENvbXB1dGVyIFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQg VGVjaG5vbG9neQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4 LjQxMTcNCg0KDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDMwLCAyMDIwIGF0IDEwOjM2IEFNDQpUbzogInNpZHJvcHNAaWV0Zi5vcmciIDxz aWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBbV0dMQ10gZHJhZnQtc2lk cm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUgLSBlbmRzIDcvT2N0b2Jlci8yMDIw DQoNCkhpIEZvbGtzLA0KDQpUaGUgdXBkYXRlIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGluY29ycG9y YXRpbmcgYWxsIHRoZSBwcmV2aW91cyBjb21tZW50cyB3YXMgcHVibGlzaGVkIHRvZGF5IGFuZCBj YW4gYmUgZm91bmQgYXQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3Bz LWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wNTxodHRwczovL2djYzAyLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wNSZkYXRh PTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3Q2IyNTNhOTU4Y2E5ZjQ2NTUz OTc3MDhkODY1NGUyZGE4JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdD MSU3QzYzNzM3MDczMzc0ODI3NjIwNyZzZGF0YT0zU0hybnplR3l3eCUyQlBrcXd1cHM5Y3lPMW1N UENpNklQV254YjJKdEdBUzAlM0QmcmVzZXJ2ZWQ9MD4uIFRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQg dGhlIGNhbGwgZm9yIGEgd2Vlay4gVGhlIFdHTEMgd2lsbCBub3cgZW5kIG9uIE9jdG9iZXIgNywg MjAyMC4NCg0KQmVzdCBSZWdhcmRzLA0KS2V5dXINCg0KRnJvbTogU2lkcm9wcyA8c2lkcm9wcy1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5j b20+DQpEYXRlOiBUaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDIwIGF0IDEwOjI3IEFNDQpUbzog InNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTaWRy b3BzXSBbV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMg LSBlbmRzIDE3L1NlcHRlbWJlci8yMDIwDQoNCkhpIEZvbGtzLA0KDQpUaGUgd2cgY2hhaXJzIGV4 dGVuZGVkIHRoZSBjYWxsIGZvciBhIHdlZWsgaW4gaG9wZXMgdGhhdCB3ZSB3b3VsZCBoYXZlIGEg Y29uc2Vuc3VzLiBTZWVtcyBsaWtlIG1vcmUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQgYW5kIHNvIHdl IHBsYW4gZXh0ZW5kIHRoZSBjYWxsIGZvciAxIG1vcmUgd2Vlay4gVGhlIFdHTEMgd2lsbCBub3cg ZW5kIG9uIFNlcHRlbWJlciAxNywgMjAyMA0KDQpCZXN0IFJlZ2FyZHMsDQpLZXl1cg0KDQpGcm9t OiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEF1Z3VzdCAx MSwgMjAyMCBhdCAxMTo0NSBBTQ0KVG86ICJzaWRyb3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFtXR0xDXSBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNp Z25hbGluZy0wMyAtIGVuZHMgMjUvQXVndXN0LzIwMjANCg0KSGkgRm9sa3M6DQoNCkEgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1zaWRyb3BzLWJn cHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMywg4oCcQkdQc2VjIFZhbGlkYXRpb24gU3RhdGUg U2lnbmFsaW5n4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRz LiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBBdWd1c3QgMjUsIDIwMjAuDQoNClRoZSBkcmFmdCBjYW4g YmUgZm91bmQgYXQ6ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1i Z3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDM8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMmZGF0YT0w MiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0NiMjUzYTk1OGNhOWY0NjU1Mzk3 NzA4ZDg2NTRlMmRhOCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzEl N0M2MzczNzA3MzM3NDgyNzYyMDcmc2RhdGE9SkpiMTBhVE5PQll6aVE2aUNmTkdEMnRNaW55UWEz WDc5S09XTGRxUW43cyUzRCZyZXNlcnZlZD0wPi4gIEF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRp Y2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNu J3QgYmVlbiBkaXNjbG9zZWQuDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQo= --_000_430A30DAD6644A27B5CEE405A372724Bnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDsN CglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDb3VyaWVyOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9InB1cnBsZSIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+ S2V5dXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoYW5rcywgSSBwbGFuIHRvIGF0dGVuZCB0b21v cnJvd+KAmXMgaW50ZXJpbSBpbiBjYXNlIHNvbWVvbmUgaGFzIGZ1cnRoZXIgcXVlc3Rpb25zLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+T2xpdmVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJp ZXI7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPk9saXZlciBCb3JjaGVydCwg Q29tcHV0ZXIgU2NpZW50aXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPk5hdGlv bmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjpibGFjayI+KE9mZmljZSkgKzEuMzAxLjk3NS40ODU2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv dXJpZXI7Y29sb3I6YmxhY2siPihHVm9pY2UpICsxLjI0MC42NjguNDExNzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlNpZHJvcHMgJmx0O3NpZHJvcHMtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJj dXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIFNlcHRlbWJlciAzMCwgMjAy MCBhdCAxMDozNiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2lkcm9wc0BpZXRmLm9yZyZxdW90 OyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtTaWRy b3BzXSBbV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUg LSBlbmRzIDcvT2N0b2Jlci8yMDIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SGkgRm9sa3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHVwZGF0ZSB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBpbmNvcnBvcmF0aW5nIGFsbCB0aGUgcHJldmlvdXMgY29tbWVudHMgd2Fz IHB1Ymxpc2hlZCB0b2RheSBhbmQgY2FuIGJlIGZvdW5kIGF0Og0KPGEgaHJlZj0iaHR0cHM6Ly9n Y2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1z aWduYWxpbmctMDUmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292 JTdDYjI1M2E5NThjYTlmNDY1NTM5NzcwOGQ4NjU0ZTJkYTglN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkz ZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MzcwNzMzNzQ4Mjc2MjA3JmFtcDtzZGF0YT0zU0hy bnplR3l3eCUyQlBrcXd1cHM5Y3lPMW1NUENpNklQV254YjJKdEdBUzAlM0QmYW1wO3Jlc2VydmVk PTAiIHRpdGxlPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3Bz ZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6Ymx1ZSI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5n LTA1PC9zcGFuPjwvYT4uPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+VGhl IHdnIGNoYWlycyBleHRlbmRlZCB0aGUgY2FsbCBmb3IgYSB3ZWVrLg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj53aWxsIG5vdyBlbmQgb24gT2N0b2JlciA3LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+S2V5dXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlNpZHJvcHMgJmx0O3NpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDIwIGF0IDEwOjI3IEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1NpZHJvcHNdIFtXR0xDXSBkcmFmdC1zaWRyb3BzLWJn cHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyAtIGVuZHMgMTcvU2VwdGVtYmVyLzIwMjA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgRm9s a3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHdnIGNoYWlycyBleHRlbmRlZCB0aGUgY2FsbCBmb3Ig YSB3ZWVrIGluIGhvcGVzIHRoYXQgd2Ugd291bGQgaGF2ZSBhIGNvbnNlbnN1cy4gU2VlbXMgbGlr ZSBtb3JlIGRpc2N1c3Npb24gaXMgbmVlZGVkIGFuZCBzbyB3ZSBwbGFuIGV4dGVuZCB0aGUgY2Fs bCBmb3IgMSBtb3JlIHdlZWsuDQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpbGwgbm93IGVuZCBvbiBTZXB0 ZW1iZXIgMTcsIDIwMjA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmVzdCBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PktleXVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5LZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgQXVndXN0IDExLCAyMDIwIGF0IDExOjQ1IEFNPGJyPg0KPGI+VG86 IDwvYj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRh dGlvbi1zaWduYWxpbmctMDMgLSBlbmRzIDI1L0F1Z3VzdC8yMDIwPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5I aSBGb2xrczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFs aWRhdGlvbi1zaWduYWxpbmctMDMsIOKAnEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25hbGlu Z+KAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhlPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldHTEM8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2lsbA0KIGVuZCBvbiBB dWd1c3QgMjUsIDIwMjAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRyYWZ0 IGNhbiBiZSBmb3VuZCBhdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJG ZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMmYW1wO2RhdGE9MDIl N0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDYjI1M2E5NThjYTlmNDY1NTM5Nzcw OGQ4NjU0ZTJkYTglN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdD NjM3MzcwNzMzNzQ4Mjc2MjA3JmFtcDtzZGF0YT1KSmIxMGFUTk9CWXppUTZpQ2ZOR0QydE1pbnlR YTNYNzlLT1dMZHFRbjdzJTNEJmFtcDtyZXNlcnZlZD0wIiB0aXRsZT0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAz Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRh dGlvbi1zaWduYWxpbmctMDM8L2E+PC9zcGFuPi48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXV0aG9ycywgcGxlYXNlIHJl cGx5IGluZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0 aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluO2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktl eXVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_430A30DAD6644A27B5CEE405A372724Bnistgov_--