From nobody Thu Jan 3 14:36:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBB513133D for ; Thu, 3 Jan 2019 14:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, 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 0QW7wNdDb9hO for ; Thu, 3 Jan 2019 14:35:59 -0800 (PST) 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 E7E50131340 for ; Thu, 3 Jan 2019 14:35:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gfBan-0002wu-7Z for sidrops@ietf.org; Thu, 03 Jan 2019 22:35:57 +0000 Resent-Message-Id: Resent-From: Randy Bush Resent-Date: Thu, 03 Jan 2019 14:35:55 -0800 Resent-To: sidrops@ietf.org Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gfAxY-0002q6-JK for randy@ran.psg.com; Thu, 03 Jan 2019 21:55:24 +0000 Received: from [4.31.198.44] (helo=mail.ietf.org) by psg.com with esmtps (TLSv1.2:AECDH-AES256-SHA:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1gfAxX-0009J3-Pz for randy@psg.com; Thu, 03 Jan 2019 21:55:23 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90229131313 for ; Thu, 3 Jan 2019 13:55:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Randy Bush" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154655252358.29720.14776196809698513499.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2019 13:55:23 -0800 Archived-At: Subject: [Sidrops] New Version Notification for draft-ymbk-sidrops-ov-egress-00.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, 03 Jan 2019 22:36:01 -0000 A new version of I-D, draft-ymbk-sidrops-ov-egress-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-sidrops-ov-egress Revision: 00 Title: BGP RPKI-Based Origin Validation on Export Document date: 2019-01-03 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-ymbk-sidrops-ov-egress-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-sidrops-ov-egress/ Htmlized: https://tools.ietf.org/html/draft-ymbk-sidrops-ov-egress-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-ov-egress Abstract: It is useful fpr RPKI-based Origin Validation to classify and mark prefixes for all ingress, redistribution, and egress policies. For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. 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. The IETF Secretariat From nobody Thu Jan 3 15:53:35 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC22131341 for ; Thu, 3 Jan 2019 15:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xmAxGRJ9xOfz for ; Thu, 3 Jan 2019 15:53:31 -0800 (PST) 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 B72C2129A87 for ; Thu, 3 Jan 2019 15:53:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gfCnp-0003Bq-3Z for sidrops@ietf.org; Thu, 03 Jan 2019 23:53:29 +0000 Date: Thu, 03 Jan 2019 15:53:28 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: [Sidrops] Lowering Legal Barriers to RPKI Adoption 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, 03 Jan 2019 23:53:34 -0000 Yoo, Christopher S. and Wishnick, David, Lowering Legal Barriers to RPKI Adoption (December 31, 2018). U of Penn Law School, Public Law Research Paper No. 19-02. Available at SSRN: https://ssrn.com/abstract=3308619 Across the Internet, mistaken and malicious routing announcements impose significant costs on users and network operators. To make routing announcements more reliable and secure, Internet coordination bodies have encouraged network operators to adopt the Resource Public Key Infrastructure ($B!H(BRPKI$B!I(B) framework. Despite this encouragement, RPKI$B!G(Bs adoption rates are low, especially in North America. This report presents the results of a year-long investigation into the hypothesis$B!=(Bwidespread within the network operator community$B!=(Bthat legal issues pose barriers to RPKI adoption and are one cause of the disparities between North America and other regions of the world. On the basis of interviews and analysis of the legal framework governing RPKI, the report evaluates the issues raised by community members and proposes a number of strategies to reduce or circumvent the barriers that are material. The report also describes substantial action taken this year by the American Registry for Internet Numbers ($B!H(BARIN$B!I(B) and other private organizations in light of public dialogue about RPKI. From nobody Thu Jan 3 17:17:35 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8591313B4; Thu, 3 Jan 2019 17:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60xES64r4iTf; Thu, 3 Jan 2019 17:17:32 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 10E7813133D; Thu, 3 Jan 2019 17:17:32 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id b5so45087076iti.2; Thu, 03 Jan 2019 17:17:32 -0800 (PST) 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=iHzZt39VjMsiJmr9iczo590l+ntfuwiPMahHXOREwh8=; b=NjQ14U71QVeR8EqiRvaXzsC8l1nvDSZyDwgBFCbawQURXHk675onabXXAlL1+I/Luk 5c+X+liWa8z08ueLC06t7W13CeGJCzBbFTpvU7CE3vuMNGDb/kJEbIds8GuNZhNVdtP1 o3t67YyGf7+sBEnhV8v389M/sJkXJCCN+gh/ody4Yp4PhVKXTnEM5xcI6JTkSKP9yBEh ER5T8EOEWy9jP3zqDCyt+jym++iG941eIUmv5xGwdoQ8NYrHCmx9y67aGmQe5L/EYZUJ lbZfXRiTqJ9HPiuo0nyLhiG7vqVZm+3rEQ5j4G+t/6yzYx8NjDWzIU8PULZoGm9ElXl+ 2WCg== 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=iHzZt39VjMsiJmr9iczo590l+ntfuwiPMahHXOREwh8=; b=Uh3JKv9NbDDugyhwQp9rUGfuyPXM8ynWVCEzBSBNGoePV5xMjuX1cYdWJFBe9Jr0ed z+FRggK5vdT+f3X6/cXc/cTPZDnkmvHAeqbkRzXfJOr5eckeLzFSe0l/7ZSkBhLbhk5H lBM7ux2LmYKL8jztRJ7jpEF78W4iDQVIfvEx4cvffOZwU11nvx8pn4mVPjbKvuqTycEu tktpu51pIeeesqNAOTMbAVf/DoJxWCJTFVCVxPYu55dPqqrIQp9bHMZVV2kDPhZ6ODhX oyzyOGlcP82rvmn5l9ydekAFWEQEYocA/fmn7AEtWpBGJ3N/IO4UatM4fzBb623bjbGz ItFw== X-Gm-Message-State: AJcUukdU2yUmNDXmuvMrGjVBSxANeA811zsqlcg7IAuG1rp+OUZx9kFD ylBQxA/kLXxnu4BeoLq2zpnsRpmw28aWqWVhH9WZtQ== X-Google-Smtp-Source: ALg8bN7gpmkW7eHTOoXFmainAyNSw56vXel0iC5kfi/q39yvtd8GqbAD2jD1ssU6wYvsrTUGUMirI7WczJpixJx5Z5I= X-Received: by 2002:a24:f607:: with SMTP id u7mr31791893ith.89.1546564650933; Thu, 03 Jan 2019 17:17:30 -0800 (PST) MIME-Version: 1.0 References: <153840850028.21705.1054738696332918389@ietfa.amsl.com> In-Reply-To: <153840850028.21705.1054738696332918389@ietfa.amsl.com> From: Christopher Morrow Date: Thu, 3 Jan 2019 20:17:20 -0500 Message-ID: To: sidrops@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000a423d4057e97a43d" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-04.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 Jan 2019 01:17:34 -0000 --000000000000a423d4057e97a43d Content-Type: text/plain; charset="UTF-8" There was a WGLC, which seemed to go off without much comment or fanfare... (in april, actually). Let's move this on, there was ALSO review/etc LC in sidr before the document was sent over the hill to sidrops. I'll send north the request to publish. On Mon, Oct 1, 2018 at 11:42 AM 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 : Use Cases for Localized Versions of the RPKI > Author : Randy Bush > Filename : draft-ietf-sidrops-lta-use-cases-04.txt > Pages : 5 > Date : 2018-10-01 > > Abstract: > There are a number of critical circumstances where a localized > routing domain needs to augment or modify its view of the Global > RPKI. This document attempts to outline a few of them. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases-04 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-lta-use-cases-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-lta-use-cases-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/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000a423d4057e97a43d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There was a WGLC, which seemed to go off without much comm= ent or fanfare... (in april, actually).

Let's move t= his on, there was ALSO review/etc LC in sidr before the document was sent o= ver the hill to sidrops.

I'll send north the r= equest to publish.

On Mon, Oct 1, 2018 at 11:42 AM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Use Cases for Localized Versions of the RPKI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rand= y Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-lta-use-cases-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-01

Abstract:
=C2=A0 =C2=A0There are a number of critical circumstances where a localized=
=C2=A0 =C2=A0routing domain needs to augment or modify its view of the Glob= al
=C2=A0 =C2=A0RPKI.=C2=A0 This document attempts to outline a few of them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-sidrops-lta-use-cases/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-sidrops-lta-use-cases-04
https://datatracker.ietf.or= g/doc/html/draft-ietf-sidrops-lta-use-cases-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-sidrops-lta-use-cases-04


Please note that it may take a couple of minutes from the time of submissio= n
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<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000a423d4057e97a43d-- From nobody Thu Jan 3 17:42:56 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DD4128D09; Thu, 3 Jan 2019 17:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60YX9odBrpwO; Thu, 3 Jan 2019 17:42:53 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 67AA61274D0; Thu, 3 Jan 2019 17:42:53 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id m62so47950760ith.5; Thu, 03 Jan 2019 17:42:53 -0800 (PST) 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=4AFpTZ265PnBxro5mNaIzgg0vuTVgtjrpj5ZhhziJDY=; b=AHsURpg7N43/PwlydRjuEqlYPisG32XW/adfxQCmQW1EGbSOWqr+uLpN57Wnw8wJKZ kDmrW6NLRbdcpOnzMvqJ1+2PU4XnZPcMRAihP+OxB9Czx2HWQdwc72Dux13sO6ooNJba NE2rKid1o120/kb1gocepEq/bsrrT+2wFf7a9TkMnzxE9+krZ/VrWZwx8nVozii5S2pd 6g45VxcHBhu5T99T6IfvKxX+RAfIMJlciSs8JUBbA2TiNB8oYJ3Eti3PVbtdB+Jw3TyG t4E5iqPci/8C86XVE66k5u80mKLcwN718Wk1R0JgdJtL0bjaPMAQHkt2eor2Tl+rAb43 Z5Ug== 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=4AFpTZ265PnBxro5mNaIzgg0vuTVgtjrpj5ZhhziJDY=; b=lxv9737HvnAxSXgDCcjVHdzy0ANWTDim9V/afmptkRi9lreKLrDBuCx/ndgvaAQcWr LMo+gn6CdPM8//6j5XGFn1/IANK64GA0Vjt6tWoMoxN7D5Uh+xfdj0PCCUFyXtHKxQ7S GOKCqITEKZqRXgza/4TnehYwT26ygPrE2JtyqZBnmuGeSI2S9WjX5SXjCK5GaA5SKRj0 QomUy1qbIA6O64/UXUk/u9x/4uhzO/hIozN6gWMnbdHK4aDbcc9BgG8S3DZN8HfvxG9u rXizwDaOI80ltICSUqE3X/fGotHFxqviceQ3lxmJvTVyhedMSJtu2q+f25KHU/3Cdgof 0ZrQ== X-Gm-Message-State: AJcUukegxJ+VnBgFu/7X/0epu1lvHc1SGzCgu6hu5LAaIkPPFgjyvqnU dr2EHkVPKOVawxQHQqwbnflkJW6zdIKYr+DIho1Nf3gj X-Google-Smtp-Source: ALg8bN5Y8WqTQwcipJwkn4+FXTEG69yOymclUuY5dEk6Io6dKXU5fpgQzykpKd8F/einvPaoZ5ipVTTX0ncdiC5r6qk= X-Received: by 2002:a24:9d1:: with SMTP id 200mr35227510itm.53.1546566171996; Thu, 03 Jan 2019 17:42:51 -0800 (PST) MIME-Version: 1.0 References: <153840850028.21705.1054738696332918389@ietfa.amsl.com> In-Reply-To: From: Christopher Morrow Date: Thu, 3 Jan 2019 20:42:40 -0500 Message-ID: To: sidrops@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000004db977057e97ff2e" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-04.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 Jan 2019 01:42:56 -0000 --0000000000004db977057e97ff2e Content-Type: text/plain; charset="UTF-8" Note there are a few id-Nits things to deal with, but of them the most egregious seems to be: == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 On Thu, Jan 3, 2019 at 8:17 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > There was a WGLC, which seemed to go off without much comment or > fanfare... (in april, actually). > > Let's move this on, there was ALSO review/etc LC in sidr before the > document was sent over the hill to sidrops. > > I'll send north the request to publish. > > On Mon, Oct 1, 2018 at 11:42 AM 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 : Use Cases for Localized Versions of the RPKI >> Author : Randy Bush >> Filename : draft-ietf-sidrops-lta-use-cases-04.txt >> Pages : 5 >> Date : 2018-10-01 >> >> Abstract: >> There are a number of critical circumstances where a localized >> routing domain needs to augment or modify its view of the Global >> RPKI. This document attempts to outline a few of them. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-lta-use-cases-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-lta-use-cases-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/ >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >> > --0000000000004db977057e97ff2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note there are a few id-Nits things to de= al with, but of them the most egregious seems to be:
=C2=A0

=C2=A0 =3D=3D Outdated reference: A later version (-08) exists of
=C2=A0 =C2=A0 =C2=A0draft-ietf-sidr-bgpsec-overview-02
<= /div>
On Thu, Jan 3, 2019 at= 8:17 PM Christopher Morrow <christopher.morrow@gmail.com> wrote:
There was a WGLC, which s= eemed to go off without much comment or fanfare... (in april, actually).
Let's move this on, there was ALSO review/etc LC in si= dr before the document was sent over the hill to sidrops.

I'll send north the request to publish.

On Mon, Oct 1, 2018 at 11:42 AM <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Use Cases for Localized Versions of the RPKI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rand= y Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-lta-use-cases-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-01

Abstract:
=C2=A0 =C2=A0There are a number of critical circumstances where a localized=
=C2=A0 =C2=A0routing domain needs to augment or modify its view of the Glob= al
=C2=A0 =C2=A0RPKI.=C2=A0 This document attempts to outline a few of them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-sidrops-lta-use-cases/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-sidrops-lta-use-cases-04
https://datatracker.ietf.or= g/doc/html/draft-ietf-sidrops-lta-use-cases-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-sidrops-lta-use-cases-04


Please note that it may take a couple of minutes from the time of submissio= n
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<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000004db977057e97ff2e-- From nobody Thu Jan 3 17:43:57 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB442130E7F; Thu, 3 Jan 2019 17:43:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow Message-ID: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2019 17:43:55 -0800 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 04 Jan 2019 01:43:56 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-lta-use-cases-04 as Informational on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ From nobody Thu Jan 3 17:44:22 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E79130E98; Thu, 3 Jan 2019 17:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqhGCF8pXH9i; Thu, 3 Jan 2019 17:44:18 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 7A371130E6C; Thu, 3 Jan 2019 17:44:18 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id p197so45161060itp.0; Thu, 03 Jan 2019 17:44:18 -0800 (PST) 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=aGnXuydlrK27iqEDKJzB4R2W9Masl/ND7WDEIbQwDt0=; b=LKZ9/0sXQKkYYXfr/LT5hIOi2ntsm4jlHYQnvxceQ4e2M0mReU51v07QG8v2rgUXSM henoxXpx/NahFTsTD/9MOLLk6ejT9b7m1ahFiqgzeXHBkdlhdOXK/Ukk/tRtlTEYRJZL o3ipsnPv+4A0BM5Vr6XCT08gAKB45KO2qFC2wftTmR3Z7KRYcLStQzr9dRbNTUJwQ+47 SDBpE7AM18QL4/yg8Eg68DRc511o789Fxu2s5fiLtiIocWsbRRDpOLbi7FP/QtYH0pt4 Si42uMU/oQ/nIGqoy60HZTlK7uE/+OlGw0RhSkPV6lEcT/qUaeFwoTnvrgTN/atT5TBY A81g== 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=aGnXuydlrK27iqEDKJzB4R2W9Masl/ND7WDEIbQwDt0=; b=OqKPPf1qgra1FynDPiIHnjDzluS3J5zl+4kCsd/7LUOkrBJ4zGmOWEY0mr1entJNsO 0dGuy86tUlOZiy+9EggRuI7G4Fx7jmj0RCSC+JGQv8MKqMXUzl19fU6Y0sk0k3H6VQbl tPUvvIw7WtBByg+6fpmZVSL46l5TVjuFoFDT9eIq0RBIIqVYqWzctXZIieSIl9yB6ggm 4OAmAjtxNBotaYeKO19ogxq8TusOliMFueT/ROEpSzWtZPOsUcezDgiLO6+S6mRdIZ1u eVLaS27ViXwM0oib6yZVtP8IC9I/5IQpeSW97S3PQiYwVQIKLL5/ZCqrBdu1wBIlPrfY FNWQ== X-Gm-Message-State: AJcUuke1OCLS5nT3HyfSmecbfIhN36mNLa2DGHKYxjcYzFRF58o+GSW+ az7XKZ/OkWTTElmpW78ekCweBjOAdvc7pYaSTEJtqnpI X-Google-Smtp-Source: ALg8bN5RNHSs1y/sG2XlCNXcGZVN7+7IHpssXLCl9LJZHyPdrFpfyl0Pl6SgrzeocvaQXifWenpI+wOYztx3sKDs9rs= X-Received: by 2002:a24:f607:: with SMTP id u7mr31833126ith.89.1546566257474; Thu, 03 Jan 2019 17:44:17 -0800 (PST) MIME-Version: 1.0 References: <153840850028.21705.1054738696332918389@ietfa.amsl.com> In-Reply-To: From: Christopher Morrow Date: Thu, 3 Jan 2019 20:44:06 -0500 Message-ID: To: sidrops@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000660372057e9804f8" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-04.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 Jan 2019 01:44:21 -0000 --000000000000660372057e9804f8 Content-Type: text/plain; charset="UTF-8" Email was sent at 2019-01-03 17:43:55 PST8PDT Subject: Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 To: Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow On Thu, Jan 3, 2019 at 8:42 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > Note there are a few id-Nits things to deal with, but of them the most > egregious seems to be: > > > == Outdated reference: A later version (-08) exists of > draft-ietf-sidr-bgpsec-overview-02 > > On Thu, Jan 3, 2019 at 8:17 PM Christopher Morrow < > christopher.morrow@gmail.com> wrote: > >> There was a WGLC, which seemed to go off without much comment or >> fanfare... (in april, actually). >> >> Let's move this on, there was ALSO review/etc LC in sidr before the >> document was sent over the hill to sidrops. >> >> I'll send north the request to publish. >> >> On Mon, Oct 1, 2018 at 11:42 AM 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 : Use Cases for Localized Versions of the RPKI >>> Author : Randy Bush >>> Filename : draft-ietf-sidrops-lta-use-cases-04.txt >>> Pages : 5 >>> Date : 2018-10-01 >>> >>> Abstract: >>> There are a number of critical circumstances where a localized >>> routing domain needs to augment or modify its view of the Global >>> RPKI. This document attempts to outline a few of them. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sidrops-lta-use-cases-04 >>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-lta-use-cases-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-lta-use-cases-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/ >>> >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>> >> --000000000000660372057e9804f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Email was sent at 2019-01-03 17:43:55 PST8PDT
Subject: Publ= ication has been requested for draft-ietf-sidrops-lta-use-cases-04
To: <warren@kumari.net>

On Thu, Jan= 3, 2019 at 8:42 PM Christopher Morrow <christopher.morrow@gmail.com> wrote:
Note there are a few id-Nits things to deal with, but of them the most e= gregious seems to be:
=C2=A0

=C2=A0 =3D=3D Outdated r= eference: A later version (-08) exists of
=C2=A0 =C2=A0 =C2=A0dra= ft-ietf-sidr-bgpsec-overview-02

On Thu, Jan 3, 2019 at 8:17 PM Christopher Morrow <= ;christop= her.morrow@gmail.com> wrote:
There was a WGLC, which seemed to go o= ff without much comment or fanfare... (in april, actually).

<= div>Let's move this on, there was ALSO review/etc LC in sidr before the= document was sent over the hill to sidrops.

I'= ;ll send north the request to publish.

On Mon, Oct 1, 2018 at 11:42 AM <internet-drafts@ietf.org&= gt; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Use Cases for Localized Versions of the RPKI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rand= y Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-lta-use-cases-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-01

Abstract:
=C2=A0 =C2=A0There are a number of critical circumstances where a localized=
=C2=A0 =C2=A0routing domain needs to augment or modify its view of the Glob= al
=C2=A0 =C2=A0RPKI.=C2=A0 This document attempts to outline a few of them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-sidrops-lta-use-cases/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-sidrops-lta-use-cases-04
https://datatracker.ietf.or= g/doc/html/draft-ietf-sidrops-lta-use-cases-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-sidrops-lta-use-cases-04


Please note that it may take a couple of minutes from the time of submissio= n
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<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000660372057e9804f8-- From nobody Thu Jan 3 17:50:25 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8911130ED6; Thu, 3 Jan 2019 17:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Xyh5rd66UIWm; Thu, 3 Jan 2019 17:50:22 -0800 (PST) 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 B4C64130ED0; Thu, 3 Jan 2019 17:50:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gfEcu-0003QG-AL; Fri, 04 Jan 2019 01:50:20 +0000 Date: Thu, 03 Jan 2019 17:50:19 -0800 Message-ID: From: Randy Bush To: Christopher Morrow Cc: sidrops@ietf.org, i-d-announce@ietf.org In-Reply-To: References: <153840850028.21705.1054738696332918389@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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] I-D Action: draft-ietf-sidrops-lta-use-cases-04.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 Jan 2019 01:50:24 -0000 > Note there are a few id-Nits things to deal with, but of them the most > egregious seems to be: > > > == Outdated reference: A later version (-08) exists of > draft-ietf-sidr-bgpsec-overview-02 want an -05 now or after various parties are heard? From nobody Thu Jan 3 18:10:07 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F986130ED0; Thu, 3 Jan 2019 18:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0AlWmxdKQj0; Thu, 3 Jan 2019 18:10:04 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 21497130E98; Thu, 3 Jan 2019 18:10:04 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id x124so232089itd.1; Thu, 03 Jan 2019 18:10:04 -0800 (PST) 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=dlwQnk1N22Jn1XqvAOL+l+SvtKE3jeGmdpP/ZBaewVY=; b=XFt3H/AQbPZABxR/XREmRUW4qxFj00EdJ8JS1u6FV3FikLQsd0M579ASjqwPUzFOEK jV5xuignAoFYu4nE3DNvyzou+Ex5yegePoqDmyCn9AiAQ4mh42a/QEgwk7fjnn9Ybxsv TiACcVGi2kHv+85X3HAmoWnzRMYFdRS9e29uTlyBdd7evf5zhD10jt3AMz3SOzmRbqJv 0AB8NQReenKt78y0IxnKAz+q1MeT7Gi9y8DrMlmL+NrVNQzGTi91g4NoZga+ulc7sP9/ TV9gIg7WnKklHxv8tVEC28c/5YmJtFs0Q5/lhEHukf28Qhxy7rUsRrGoFkhQ8D3Auk+g fRIQ== 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=dlwQnk1N22Jn1XqvAOL+l+SvtKE3jeGmdpP/ZBaewVY=; b=PhPTpgOrFfi4KZgGOPGmJfwtJ8vYPxRAzM5WOzBLHqXrtotJXzbYIkOq8B0iEf/wc7 lUH4fTSjp/GJ9uAmMTD7CTiZshoVxaZl8vyn89JrYU70jFBm4ZidwGwsMbISaAZwbEKK owu1lf5rKrOSiPIvflFRhZ1zwpGfZv/DfSEuSSJKz04i1Zng7UV14t3Ty+rID+C+RCsk AVzQpDTnSjO8uNbfqrAFR3A0NnKEHKfvFS+9jx1YrPBUsyEdxLHcu6tbrIKQDqfPZ1Ri csE7OsmLsddTvxgOlv2GBmJZIJzZyvojDF+o8PjzoDKnJ6LqwgtcQKoyWkzwhZTdwX6i 9f9Q== X-Gm-Message-State: AJcUukf4c9Bi07bp+iJMl23YGI67X50uV6DseAxh/F0yBbLQy1TtvVQ0 8ombJhkEUMbLTLk/q7GOuXjIQsIStAk3HyjcqeA= X-Google-Smtp-Source: ALg8bN6a4zE0C2PKY0xCGhL0eIqR1X7dm5KaEPTvs+URUDlw8MhlYu5Q2PB3CZyJxMagYkFEiQLr5hbaZ+u5duLUza0= X-Received: by 2002:a24:32c5:: with SMTP id j188mr31854773ita.139.1546567803088; Thu, 03 Jan 2019 18:10:03 -0800 (PST) MIME-Version: 1.0 References: <153840850028.21705.1054738696332918389@ietfa.amsl.com> In-Reply-To: From: Christopher Morrow Date: Thu, 3 Jan 2019 21:09:51 -0500 Message-ID: To: Randy Bush Cc: sidrops@ietf.org, i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="00000000000086359f057e986052" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-lta-use-cases-04.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 Jan 2019 02:10:06 -0000 --00000000000086359f057e986052 Content-Type: text/plain; charset="UTF-8" I imagine there will be other issues, people love them some arm-hair-removal[0], so let's just aggregate for later :) -chris 0: https://www.npr.org/2014/11/17/364760847/whats-with-all-of-the-hairy-arms-in-graphic-design On Thu, Jan 3, 2019 at 8:50 PM Randy Bush wrote: > > Note there are a few id-Nits things to deal with, but of them the most > > egregious seems to be: > > > > > > == Outdated reference: A later version (-08) exists of > > draft-ietf-sidr-bgpsec-overview-02 > > want an -05 now or after various parties are heard? > --00000000000086359f057e986052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I imagine there will be other issues, peo= ple love them some arm-hair-removal[0], so let's just aggregate for lat= er :)

-chris

On Thu, Jan 3, 2019 at 8:50 PM Randy Bush <randy@psg.com> wrote:
> Note there are a few id-Nits things t= o deal with, but of them the most
> egregious seems to be:
>
>
>=C2=A0 =C2=A0=3D=3D Outdated reference: A later version (-08) exists of=
>=C2=A0 =C2=A0 =C2=A0 draft-ietf-sidr-bgpsec-overview-02

want an -05 now or after various parties are heard?
--00000000000086359f057e986052-- From nobody Fri Jan 4 05:53:47 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1B5128CF2 for ; Fri, 4 Jan 2019 05:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1ThF6-Co1AG for ; Fri, 4 Jan 2019 05:53:43 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8DB12958B for ; Fri, 4 Jan 2019 05:53:42 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x04DreFl084558 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2019 13:53:40 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: "sidrops@ietf.org" Cc: Randy Bush References: <154655252358.29720.14776196809698513499.idtracker@ietfa.amsl.com> From: Nick Hilliard Message-ID: Date: Fri, 4 Jan 2019 13:53:38 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.9 MIME-Version: 1.0 In-Reply-To: <154655252358.29720.14776196809698513499.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-sidrops-ov-egress-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 Jan 2019 13:53:45 -0000 internet-drafts@ietf.org wrote on 03/01/2019 21:55: > It is useful fpr RPKI-based Origin Validation to classify and mark > prefixes for all ingress, redistribution, and egress policies. For > egress policy, it is important that the classification uses the > effective origin AS of the processed route, which may specifically be > altered by the commonly available knobs such as removing private ASs, > confederation handling, and other modifications of the origin AS. good point. Are there any bgp stacks which currently implement this? Nick From nobody Fri Jan 4 07:08:25 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080A812EB11 for ; Fri, 4 Jan 2019 07:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 g20uQqQFyOIn for ; Fri, 4 Jan 2019 07:08:22 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.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 28EEF12DD85 for ; Fri, 4 Jan 2019 07:08:22 -0800 (PST) Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id B8A79277DE; Fri, 4 Jan 2019 16:08:18 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1546614498; bh=f/yt1dIPOL+f6YDd9z/N+y2+M8GaQh2TqAoIJHFtr+U=; h=Subject:From:In-Reply-To:Date:References:To; b=uZ6EyyakzSGXFVPCvV7PXwzshruk8inI/mxLqeASVbKjLqJmrZxf8yTeDff3lQ6SW jICITWjADKUyMePsIzgvS2R4KpdUOljZQw9/efgovPtcLwQs3iOT7RddBW4XYYgeSk CmKsmCsZegh2HSLZN/xKSGAULMd8F9WG8+yKX5ak= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <20181220160248.204fa146@glaurung.nlnetlabs.nl> Date: Fri, 4 Jan 2019 16:08:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> <20181220160248.204fa146@glaurung.nlnetlabs.nl> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) 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 Jan 2019 15:08:24 -0000 Hi all, Any objections to me making the following changes? * remove the blank line after the comments * no longer allow data to be used when TLS verification fails (MUST = NOT..) I would really appreciate some voices pro / con, and then spin a = hopefully final version asap that I can ask last call on, again. Tim > On 20 Dec 2018, at 16:02, Martin Hoffmann = wrote: >=20 > Tim Bruijnzeels wrote: >> On 17 Dec 2018, at 17:14, Job Snijders wrote: >>>=20 >>> Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we >>> are the IETF =20 >>=20 >> So, the machines will most likely ignore this anyway. I guess that >> UTF-8 should be okay, provided we restrict the allowed line breaks to >> or for these lines as well. So maybe rephrase: >>=20 >> Current: >>=20 >> 1. an optional comment section consisting of one or more lines >> starting with the '#' character, containing human readable >> informational ASCII text, followed by an empty line using a >> "" or "" line break only. >>=20 >> New: >>=20 >> 1. an optional comment section consisting of one or more lines >> starting with the '#' character, containing human readable >> informational UTF-8 text, and ending with a "" or=20 >> "" line break. Followed by an empty line using a >> "" or "" line break only. >=20 > I don=E2=80=99t quite see why the empty line after the comment is = necessary at > all. Since all the comment lines start with a hash, the end of the > comment section can be identified by the first line not starting with = a > hash. >=20 > Kind regards, > Martin >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Jan 4 07:17:04 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBA9130DC1 for ; Fri, 4 Jan 2019 07:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XewI2LDzo8UN for ; Fri, 4 Jan 2019 07:17:00 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15876130934 for ; Fri, 4 Jan 2019 07:16:59 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from [IPv6:2a02:8084:2861:d680:9858:87dc:9299:2d6d] ([IPv6:2a02:8084:2861:d680:9858:87dc:9299:2d6d]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x04FGoFj094286 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2019 15:16:57 GMT (envelope-from nick@foobar.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Nick Hilliard X-Mailer: iPhone Mail (16C101) In-Reply-To: Date: Fri, 4 Jan 2019 15:16:50 +0000 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3D9C4CAD-5D82-4E6C-A28F-C2444E6DCC7A@foobar.org> References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> <20181220160248.204fa146@glaurung.nlnetlabs.nl> To: Tim Bruijnzeels Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) 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 Jan 2019 15:17:03 -0000 No objection. Nick Sent from my iWotsit. > On 4 Jan 2019, at 15:08, Tim Bruijnzeels wrote: >=20 > Hi all, >=20 > Any objections to me making the following changes? > * remove the blank line after the comments > * no longer allow data to be used when TLS verification fails (MUST NOT..)= >=20 > I would really appreciate some voices pro / con, and then spin a hopefully= final version asap that I can ask last call on, again. >=20 > Tim >=20 >=20 >> On 20 Dec 2018, at 16:02, Martin Hoffmann wrote:= >>=20 >> Tim Bruijnzeels wrote: >>>> On 17 Dec 2018, at 17:14, Job Snijders wrote: >>>>=20 >>>> Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we >>>> are the IETF =20 >>>=20 >>> So, the machines will most likely ignore this anyway. I guess that >>> UTF-8 should be okay, provided we restrict the allowed line breaks to >>> or for these lines as well. So maybe rephrase: >>>=20 >>> Current: >>>=20 >>> 1. an optional comment section consisting of one or more lines >>> starting with the '#' character, containing human readable >>> informational ASCII text, followed by an empty line using a >>> "" or "" line break only. >>>=20 >>> New: >>>=20 >>> 1. an optional comment section consisting of one or more lines >>> starting with the '#' character, containing human readable >>> informational UTF-8 text, and ending with a "" or=20 >>> "" line break. Followed by an empty line using a >>> "" or "" line break only. >>=20 >> I don=E2=80=99t quite see why the empty line after the comment is necessa= ry at >> all. Since all the comment lines start with a hash, the end of the >> comment section can be identified by the first line not starting with a >> hash. >>=20 >> Kind regards, >> Martin >>=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 From nobody Fri Jan 4 07:34:57 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCA4131012 for ; Fri, 4 Jan 2019 07:34:55 -0800 (PST) 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] 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 P4NUjEVY2IXv for ; Fri, 4 Jan 2019 07:34:52 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.nic.dtag.de [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id A82DA1310E2 for ; Fri, 4 Jan 2019 07:32:04 -0800 (PST) Received: from x59.NIC.DTAG.DE (x59.nic.dtag.de [194.25.1.154]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id QAA01323; Fri, 4 Jan 2019 16:31:54 +0100 (MET) To: Nick Hilliard cc: "sidrops@ietf.org" , Randy Bush From: Ruediger Volk In-Reply-To: Your message of "Fri, 04 Jan 2019 13:53:38 GMT." Date: Fri, 04 Jan 2019 16:31:54 +0100 Message-ID: <7284.1546615914@x59.NIC.DTAG.DE> Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-sidrops-ov-egress-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 Jan 2019 15:34:55 -0000 Nick Hilliard wrote: > internet-drafts@ietf.org wrote on 03/01/2019 21:55: > > It is useful fpr RPKI-based Origin Validation to classify and mark > > prefixes for all ingress, redistribution, and egress policies. For > > egress policy, it is important that the classification uses the > > effective origin AS of the processed route, which may specifically be > > altered by the commonly available knobs such as removing private ASs, > > confederation handling, and other modifications of the origin AS. > > good point. Are there any bgp stacks which currently implement this? all implementations relevant for my network (NOT an empty set) do NOT conform. I guess the better question is: which implementation actually do the right thing? (congrats to the implementor!) (and the next: what are the planned fixes?) The draft does not change ROV, it just asks that application in certain circumstance MUST be correct - that seem to be very easy to neglect. Most thinking about ROV application (and controlling correctnes of route announcements) tends to focus on ingress policy. I started late to seriously look at the egress - but I take the robustnes principle serious - and in security matters essentially the "be conservative" part applies. When I started to consider requirements for my egress filtering I hit the interesting cases, and immediately thought "implementors most likely are missing these [corner?] cases" Ruediger From nobody Fri Jan 4 10:53:26 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959D5130E7C for ; Fri, 4 Jan 2019 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 x3Xf2A_tCfAi for ; Fri, 4 Jan 2019 10:53:24 -0800 (PST) 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 5C867130E7A for ; Fri, 4 Jan 2019 10:53:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gfUaw-0006Uj-7f; Fri, 04 Jan 2019 18:53:22 +0000 Date: Fri, 04 Jan 2019 10:53:21 -0800 Message-ID: From: Randy Bush To: Nick Hilliard Cc: "sidrops@ietf.org" In-Reply-To: References: <154655252358.29720.14776196809698513499.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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] New Version Notification for draft-ymbk-sidrops-ov-egress-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 Jan 2019 18:53:25 -0000 >> It is useful fpr RPKI-based Origin Validation to classify and mark >> prefixes for all ingress, redistribution, and egress policies. For >> egress policy, it is important that the classification uses the >> effective origin AS of the processed route, which may specifically be >> altered by the commonly available knobs such as removing private ASs, >> confederation handling, and other modifications of the origin AS. > > good point. Are there any bgp stacks which currently implement this? there are three i believe are working on it now randy From nobody Fri Jan 4 10:59:42 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFAC130E8B for ; Fri, 4 Jan 2019 10:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwVeYQQe7G_e for ; Fri, 4 Jan 2019 10:59:37 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 5542C130E85 for ; Fri, 4 Jan 2019 10:59:37 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gfUgy-0006Ds-6B (job@us.ntt.net) for sidrops@ietf.org; Fri, 04 Jan 2019 18:59:37 +0000 Received: by mail-oi1-f178.google.com with SMTP id i6so31114895oia.6 for ; Fri, 04 Jan 2019 10:59:35 -0800 (PST) X-Gm-Message-State: AJcUukcINy7/VZbnXuMXDfjI87ceC8X4SAkPJo+E8Mxlb2HZihKZRaiL bf6ViyoKda06amiEkdpSx7KfkufXVV1pLLgD4URQ5g== X-Google-Smtp-Source: ALg8bN6ltgXO03Y6NKy+8pMd7RqkdgtON21GPhyFjbUWML1hVahXyelgvacOxuqEGf8f6HTsDJQQYM53c6ms18lRzXM= X-Received: by 2002:a54:4393:: with SMTP id u19mr1685331oiv.99.1546628375120; Fri, 04 Jan 2019 10:59:35 -0800 (PST) MIME-Version: 1.0 References: <7284.1546615914@x59.NIC.DTAG.DE> In-Reply-To: <7284.1546615914@x59.NIC.DTAG.DE> From: Job Snijders Date: Fri, 4 Jan 2019 21:59:24 +0300 X-Gmail-Original-Message-ID: Message-ID: To: Ruediger Volk Cc: Nick Hilliard , Randy Bush , "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e630d4057ea67aa8" Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-sidrops-ov-egress-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 Jan 2019 18:59:40 -0000 --000000000000e630d4057ea67aa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I=E2=80=99m appreciative the authors took the initiative for this draft. I= =E2=80=99d like this to be a working group item. Kind regards, Job On Fri, Jan 4, 2019 at 18:35 Ruediger Volk wrote: > Nick Hilliard wrote: > > internet-drafts@ietf.org wrote on 03/01/2019 21:55: > > > It is useful fpr RPKI-based Origin Validation to classify and > mark > > > prefixes for all ingress, redistribution, and egress policies. > For > > > egress policy, it is important that the classification uses the > > > effective origin AS of the processed route, which may > specifically be > > > altered by the commonly available knobs such as removing privat= e > ASs, > > > confederation handling, and other modifications of the origin A= S. > > > > good point. Are there any bgp stacks which currently implement this? > all implementations relevant for my network (NOT an empty set) do NOT > conform. > > I guess the better question is: > which implementation actually do the right thing? > (congrats to the implementor!) > > (and the next: what are the planned fixes?) > The draft does not change ROV, it just asks that application > in certain circumstance MUST be correct - that seem to be very > easy to neglect. > > Most thinking about ROV application (and controlling correctnes of > route announcements) tends to focus on ingress policy. > I started late to seriously look at the egress - but I take > the robustnes principle serious - and in security matters > essentially the "be conservative" part applies. > > When I started to consider requirements for my egress filtering > I hit the interesting cases, and immediately thought > "implementors most likely are missing these [corner?] cases" > > Ruediger > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000e630d4057ea67aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I=E2=80=99m appreciative the authors took the initiative for this= draft. I=E2=80=99d like this to be a working group item.

Kind regards,

=
Job

On Fri, Jan 4, 2019 at 18:35 Ruediger Volk <rv@nic.dtag.de> wrote:
Nick Hilliard wrote:
=C2=A0 > i= nternet-drafts@ietf.org wrote on 03/01/2019 21:55:
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0It is useful fpr RPKI-based Origin Vali= dation to classify and mark
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0prefixes for all ingress, redistributio= n, and egress policies.=C2=A0 For
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0egress policy, it is important that the= classification uses the
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0effective origin AS of the processed ro= ute, which may specifically be
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0altered by the commonly available knobs= such as removing private ASs,
=C2=A0 > >=C2=A0 =C2=A0 =C2=A0confederation handling, and other modif= ications of the origin AS.
=C2=A0 >
=C2=A0 > good point.=C2=A0 Are there any bgp stacks which currently impl= ement this?
all implementations relevant for my network (NOT an empty set) do NOT confo= rm.

I guess the better question is:
which implementation actually do the right thing?
(congrats to the implementor!)

(and the next: what are the planned fixes?)
The draft does not change ROV, it just asks that application
in certain circumstance MUST be correct - that seem to be very
easy to neglect.

Most thinking about ROV application (and controlling correctnes of
route announcements) tends to focus on ingress policy.
I started late to seriously look at the egress - but I take
the robustnes principle serious - and in security matters
essentially the "be conservative" part applies.

When I started to consider requirements for my egress filtering
I hit the interesting cases, and immediately thought
"implementors most likely are missing these [corner?] cases"

Ruediger

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000e630d4057ea67aa8-- From nobody Fri Jan 4 11:17:27 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80BE130E8A for ; Fri, 4 Jan 2019 11:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 MA6IdJH_UsGg for ; Fri, 4 Jan 2019 11:17:24 -0800 (PST) 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 C76B6130E85 for ; Fri, 4 Jan 2019 11:17:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gfUy8-0006Yb-E0; Fri, 04 Jan 2019 19:17:20 +0000 Date: Fri, 04 Jan 2019 11:17:19 -0800 Message-ID: From: Randy Bush To: Job Snijders Cc: Ruediger Volk , Nick Hilliard , "sidrops@ietf.org" In-Reply-To: References: <7284.1546615914@x59.NIC.DTAG.DE> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-sidrops-ov-egress-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 Jan 2019 19:17:26 -0000 > I=A2m appreciative the authors took the initiative for this draft. I=A2d > like this to be a working group item. i suspect that the author will ask the wg chairs to do a wg adoption call after it has simmered a bit and we have some feedback with content. randy From stkent@verizon.net Mon Jan 7 13:58:22 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340D612DDA3 for ; Mon, 7 Jan 2019 13:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 JgG819_INNNr for ; Mon, 7 Jan 2019 13:58:20 -0800 (PST) Received: from sonic315-14.consmr.mail.bf2.yahoo.com (sonic315-14.consmr.mail.bf2.yahoo.com [74.6.134.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 994B512E036 for ; Mon, 7 Jan 2019 13:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1546898299; bh=+H1SGflQThaowdwwYYmJXZmlw//tHnxxBlvPnZv73P0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=FRZ1npEDBP8dDY/Od4g7WDGb6ipQ3xm9rZoLhZ6PXINy4/geqhwGwCXiT2eaw7vtGZ08q/4DRloyv3boyZJcmtuZC8jFf1UAkdum4RP36z8ePc6u/1o8J8/F74JvLT+k77YoRITjEp0z7E+qC34/sz6SR+eNZbU5mU53GDcvw4PdSR/UON9aLPmYoZ0iof+272WAuUSMCrcmGwDLT6m6w8TDb+A93PuQtx0fQApJpjtO0Rh8y4QNLeRChfFJHQaXxQiC5N2We7raT2ytNeS0Qpxewzj6pLKq/Xkfiy7Hkw870hVvdPgYXycKq57cqNf41xonRBD3/0cZLvJfP/GIIQ== X-YMail-OSG: 0czQqnoVM1luHG9Nbz9_fxF9Qx6GtTt9NIcDRKS7lLc3uAT2jd8RIaD59_zOzpo FRZKQi6U32F4uYnd2vNGJkGorbog3HHuzzm9t3wLUjrFCtMMUUCWU.djOd09_9.T06bU9G8GZCib zO5_SLKMeb9kTi6vzc9xtPuWKF4XC8XM70lV33PvXeFnc8M68ImkB77UMcRa7LllWwsvhc962sR7 y1JHjgpqu6cfc__ReA.Emn0LK3YrOHJECurMz3lgxZFw_KzgHFZ0Wy2hEQsWyPKPW3pdTFO7b6bj FDEwyobvBmmPYAHagOkmG7S3S_TTbJnzKXpSqZV75yaxi2Qwd1jM6crN9Envr6twd.mEpmr7qMK. 6XeznkqUTn7YgA7QjwzFCkmbmtdODfZWHLODWfjy2jrSO2WrvOhDnRRjIzoRsPSy7F9RK9LPk0Tq tExN9FCQUuP8a3iTZ.dmeoKbERaSRFC7D9vW5LE8Z.BLdna1qCbb_VewLcDmmk1iPPHRW0PoG1n8 ih010geMtpIU4aH9k9sS31Lr7poeHqrzOf1iwkpXcFVwhuAAYMUE2lkyEe4YubKyIxGdtgtX3MZS 6KhcG7dS2EXamCMSEY.xEwADw_2oNvbEuKKY_BViU.C.lKLaITCcTyFy6lCFqsOCYbLYpOumX3dL j2uZVvs6pYMMxD3.SzKyoi.pksti_ln7XSaxcmY2OlGLyoRSP72KvAM1FucBRztn0t1ifyipz8rm plY6H7BHq7hplaxqgeM6zBg9f5opeIxLEer2dMy7siKutrSyllV3u3gVXJ6dO3e_oJx3fT.K3NXY 3AmKEXhRdvuTbY1I21mgeGDlGdSEDBKa..9xh6Oqa8I0.mVKlmJa02cGskoNenMKc_q.15425_K9 OR65UquY9FH.pIZ2_HxOHcY3BKNGtPd5Ae2pbWBzQe9aFrChhJjqGULM_wxsSPQVDbFe7EgbjA6s Gl4zqFVRIycS8KhLnB_dpWbBTHZsvso_J4GToI.FzpoQlD8y.yLFMe9dCNc4cLjcwzgDa75R2Dj5 t3TFrjTtFeenxtH5u8YKcvkv3bk7bhd1ZietPlsMW8.PT4NYKg0YWhAekK7.1XcCEx.joq6QT78E pi7j0EnQj Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Mon, 7 Jan 2019 21:58:19 +0000 Received: from pool-71-184-117-160.bstnma.fios.verizon.net (EHLO iMac-Study.fios-router.home) ([71.184.117.160]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b85df4fc683e1c32fe2ffd9335d1a960; Mon, 07 Jan 2019 21:58:14 +0000 (UTC) To: sidrops@ietf.org, Chris Morrow References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> From: Stephen Kent Message-ID: Date: Mon, 7 Jan 2019 16:58:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 09 Jan 2019 12:10:18 -0000 Chris, All of the issues I raised with the prior version apply to this version, as there have been no substantive changes. This doc should cite SLURM, and note that the solution presented there does not require creating new TAs, but does enable creation of a local view of the RPKI. Steve > Chris Morrow has requested publication of draft-ietf-sidrops-lta-use-cases-04 as Informational on behalf of the SIDROPS working group. > > Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Sat Jan 12 10:50:22 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F04127B4C for ; Sat, 12 Jan 2019 10:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.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 Dl_8mSx-Ffq5 for ; Sat, 12 Jan 2019 10:50:20 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 7944512E04D for ; Sat, 12 Jan 2019 10:50:17 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id 96so18621521wrb.2 for ; Sat, 12 Jan 2019 10:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ts5CJYQ2qtXRs35RlXi1GOLJCukYy4haHOpa/NFlaTI=; b=UeqMpn9UkwvbwFrfnBWKhgg5hJVx4R4N7Yd3TPtCzLC/rTXOsfO8E3orGPPgEmzXtY kLMvnn0Qn3xSrtI3qZCSY7rpX20ro7VSfepuX5ZP1XPbp61Yd3CTLnTHZnSWWnsrnQW9 JK0kFGM9Im8tH/XzFX60WUOAOiQsh4p+Bj5NP4pS8Ksds/RRpjGVcW7qW911NiCHnB5n 3tRFAAb0DetfibeCqanIM6SaeLKWIxs1D3W7GiHN7rQ3xtr181u5RpxsplyWhc3/4a1K HNVEtSJXOv/SEYuuFjU7Oo8ZX5kgMlquvKMPnVbKfg5x/7RAhfeKfVyJ1/ji8L+aBRYY 7sBg== 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=Ts5CJYQ2qtXRs35RlXi1GOLJCukYy4haHOpa/NFlaTI=; b=fdk1PxBBswB0Mu/NcTv/PcvwMt9NZ7F1mW4foB1QCP9bfgDM5u0GVMz1KjzAA0yj8C UyfNWH9REqustLoI0joYGs/dC3y44hJfJWfOSO7tmy26yWArIFDr+KZZPvc0vcnE5pae nxXaxlPLQyEvsUTQW7jQSPbKRiWC3mnl8DJmFiPHNI+WaaTx2dFns0lEnwPWHjaEBVIC qGr5g4v29niTFUVn8gtca5Zym1+qepoiVdZDX7gYylqY/f7xlfBSGRMW0FiY9+i5sVJZ ynMao5H5TbOYIHbSFlBeqQdUK60gT4jThspdvgroAs+31JGUMCbaTBn6MII80PGBEbS7 NidA== X-Gm-Message-State: AJcUukc5Tb2RZaJ9F9bgDbd9lAc2NmtaXrjLmHqEosGl4sH6I+Lt+HXr ZehDEHZ0lX18NANa1qpFhGfSC2rXU+ruuHWDUlcsOGoi X-Google-Smtp-Source: ALg8bN6kbQuYxzUiCAQjLalbBeLytJGpdbuMFBHejEbJ+GZ7mYULyqlF96W1XLu+BpnD+ga9eZdqCMm1xHbxaeXiMh8= X-Received: by 2002:adf:f0c5:: with SMTP id x5mr17547791wro.77.1547319015590; Sat, 12 Jan 2019 10:50:15 -0800 (PST) MIME-Version: 1.0 References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> In-Reply-To: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Sat, 12 Jan 2019 13:49:38 -0500 Message-ID: To: Chris Morrow Cc: SIDROps Chairs , sidrops@ietf.org, IESG_Secretary Content-Type: multipart/alternative; boundary="0000000000004763cf057f47483d" Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 12 Jan 2019 18:50:22 -0000 --0000000000004763cf057f47483d Content-Type: text/plain; charset="UTF-8" I'm returning this document to the Working Group because I do not see sufficient evidence of consensus. With no hats - I personally believe that documenting the use cases is useful, and would like to see this / a document describe the operational practices of having a local TA. W On Thu, Jan 3, 2019 at 8:43 PM Chris Morrow wrote: > Chris Morrow has requested publication of > draft-ietf-sidrops-lta-use-cases-04 as Informational on behalf of the > SIDROPS working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000004763cf057f47483d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm returning this document to the Working Group because I = do not see sufficient evidence of consensus.

With no hats - I personal= ly believe that documenting the use cases is useful, and would like to see = this / a document describe the operational practices of having a local TA.<= /div>
=
W

On Thu, J= an 3, 2019 at 8:43 PM Chris Morrow <morrowc@ops-netman.net> wrote:
Chris Morrow has requested publication of draft= -ietf-sidrops-lta-use-cases-04 as Informational on behalf of the SIDROPS wo= rking group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/<= /a>



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div> --0000000000004763cf057f47483d-- From nobody Sat Jan 12 14:20:22 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690001310F6; Sat, 12 Jan 2019 14:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_D3ByLVVzbN; Sat, 12 Jan 2019 14:20:13 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B571310FC; Sat, 12 Jan 2019 14:20:12 -0800 (PST) X-Envelope-To: sidrops-chairs@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x0CMK9el025791 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2019 22:20:09 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Warren Kumari Cc: Chris Morrow , SIDROps Chairs , sidrops@ietf.org, IESG_Secretary References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> From: Nick Hilliard Message-ID: <3321b6de-ef69-5d3c-b4b0-31865ddca224@foobar.org> Date: Sat, 12 Jan 2019 22:20:07 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.9 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 12 Jan 2019 22:20:20 -0000 Warren Kumari wrote on 12/01/2019 18:49: > I'm returning this document to the Working Group because I do not see > sufficient evidence of consensus. > > With no hats - I personally believe that documenting the use cases is > useful, and would like to see this / a document describe the operational > practices of having a local TA. this is likely to be useful from the point of view of dealing with long term concerns about centralisation of control of the global routing infrastructure, that have been aired from time to time in various fora, both private and public. The three example cases are realistic (cf: RIPE NCC court order regarding registration of resources in 2011). It would also be important to note that the local trust anchor mechanism suggested here could also be created to override legitimate announcements, e.g. states who wish to control the routing tables of service providers in their legal jurisdiction. Knives make no judgement about what they cut through. I support publication of the draft. It may need more content, e.g. description of methods to implement the ideas that it suggests. Nick From nobody Sat Jan 12 14:43:55 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B686C131133; Sat, 12 Jan 2019 14:43:53 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 epJDY6rnFmYE; Sat, 12 Jan 2019 14:43:48 -0800 (PST) Received: from out20-86.mail.aliyun.com (out20-86.mail.aliyun.com [115.124.20.86]) (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 776F5131132; Sat, 12 Jan 2019 14:43:46 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.09190307|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e01l07391; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.DksGQ4W_1547333017; Received: from 192.168.3.18(mailfrom:madi@rpstir.net fp:SMTPD_---.DksGQ4W_1547333017) by smtp.aliyun-inc.com(10.147.43.230); Sun, 13 Jan 2019 06:43:38 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: <3321b6de-ef69-5d3c-b4b0-31865ddca224@foobar.org> Date: Sun, 13 Jan 2019 06:43:35 +0800 Cc: Warren Kumari , Chris Morrow , SIDROps Chairs , sidrops@ietf.org, IESG_Secretary Content-Transfer-Encoding: quoted-printable Message-Id: <096ED0B2-1FBC-4CDC-B73D-28D61F08AC24@rpstir.net> References: <154656623575.29677.9867680687994360294.idtracker@ietfa.amsl.com> <3321b6de-ef69-5d3c-b4b0-31865ddca224@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04 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, 12 Jan 2019 22:43:54 -0000 Nick, > =D4=DA 2019=C4=EA1=D4=C213=C8=D5=A3=AC06:20=A3=ACNick Hilliard = =D0=B4=B5=C0=A3=BA >=20 > Warren Kumari wrote on 12/01/2019 18:49: >> I'm returning this document to the Working Group because I do not see = sufficient evidence of consensus. >> With no hats - I personally believe that documenting the use cases is = useful, and would like to see this / a document describe the operational = practices of having a local TA. >=20 > this is likely to be useful from the point of view of dealing with = long term concerns about centralisation of control of the global routing = infrastructure, that have been aired from time to time in various fora, = both private and public. The three example cases are realistic (cf: = RIPE NCC court order regarding registration of resources in 2011). >=20 > It would also be important to note that the local trust anchor = mechanism suggested here could also be created to override legitimate = announcements, e.g. states who wish to control the routing tables of = service providers in their legal jurisdiction. Knives make no judgement = about what they cut through. >=20 > I support publication of the draft. It may need more content, e.g. = description of methods to implement the ideas that it suggests. There is a standardized way to do so, as specified by RFC 8416, called = SLURM, which by the way has been supported by some RP software such as = Routinator and RPSTIR. I agree with what Steve suggested, draft-ietf-sidrops-lta-use-cases = should cite SLURM. Di= From nobody Tue Jan 15 20:57:10 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1F131106 for ; Tue, 15 Jan 2019 20:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 pIKVUWWn9XJv for ; Tue, 15 Jan 2019 20:56:05 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 B69521310D7 for ; Tue, 15 Jan 2019 20:56:02 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id f9so4352657eds.10 for ; Tue, 15 Jan 2019 20:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OM8K5ltrNqyCLXOQs/z7H2b/ogWyaHFUZI5GsnTwJzs=; b=gx9cTe6e1YMq53VIL+13LCaLMAQCBWms131TiqgNfgxIY4+H/dG/G56SCr8DBSbLiR ORcIr7gJwf2HGwHUal1DPIHfd4dHoNA5KHgdaC9wGDX4uK3EHeKvjFVejXygz74eOv9m mibXSTN4TWR3UKKrYVjktUYo5zZhdk/+8Kqs4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OM8K5ltrNqyCLXOQs/z7H2b/ogWyaHFUZI5GsnTwJzs=; b=AM8m6qmsZsX0rcYShEj5Gv43CD/7F7esTy6Y9Twi/CW3ZlR3xIXFlPwqTf2guleE8X LraNZle1/XF8H/nS9sX+3dwBeh4b+mMUE6Zzjv4AEi0+cC8mxrK/i73sq26jfyL7fhjo DspqHtNs5pzC9Vl4ecK0DbOyBkAB5GlWH1ycHSo97nNW+xsJ2gcICMviV7YpbjMSuAoF iRxfEV4Ln4liZt7RTn1KgvbMxuYL0X/Tya6dIlV7mCq8Ba2XXEZzlUxHoiqRwQIaMIZS jf1AcS+D2pae5Nj92eOTEtuE2tsOUpAjPOUt7pRGqU0a4m9nsODV+ng4V3qIwHBcrEls 4j/g== X-Gm-Message-State: AJcUukfiCZX9cJrL+JMo/g4N+Bv2Agn8M2JGKblkSz4AyOxvnkf93GIc eYuGKf7vFA/6cDUkddMih4eIjw== X-Google-Smtp-Source: ALg8bN7Cx75KVm+gGsMruCyBitUDVzEHzjNm9+Sap9PeF6X1MQQKGERJ25lQA+gBiTQTVXz2PUFVow== X-Received: by 2002:aa7:d684:: with SMTP id d4mr5685349edr.59.1547614561152; Tue, 15 Jan 2019 20:56:01 -0800 (PST) Received: from [5.5.33.23] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id k26-v6sm3011536ejv.59.2019.01.15.20.55.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 20:56:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 15 Jan 2019 20:55:57 -0800 Cc: SIDROps Chairs , ops-dir , IETF Discuss , SIDR Operations WG , sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> To: Christopher Morrow , Warren Kumari , Scott Bradner X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-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: Wed, 16 Jan 2019 04:56:10 -0000 Apologies for just finding this now =E2=80=A6 I seem to remember a WG discussion about whether this draft should be = BCP or ST. We discussed BCP addressing both what the IETF wanted to be = the best practice as well as what is the actual current practice. Since = BGPsec was/is new it was/is hard to say it fell in the latter bucket and = there was at least one person who felt that the router and operator = driven methods weren=E2=80=99t the way to go in the future (hence why = there is s8 the "advanced deployment scenarios=E2=80=9D section). So = the WG said go ST and because this draft has exhausted me we just = changed it to ST. I will note that the SECDIR and RTGDIR both had this = same comment it seems like we=E2=80=99re back to BCP. I think there was = another message somewhere about changing this to BCP so I will do that = in -03 unless I hear otherwise. spt > On Dec 26, 2018, at 08:29, Christopher Morrow = wrote: >=20 > BCP seems like a fine answer here, I'm not remembering why we would = have swapped to ST from BCP. >=20 > On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari = wrote: > [ + Sandy, Alvaro ] >=20 > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > that use of a MUST is commendable but its not exactly an = interoperability issue=20 >=20 > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases = in this document) >=20 > but, that said, 2119 has been misused for kinda a long time so its not = a new sin >=20 >=20 > This document has a long history -- it was originally a product of the = SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over = to SIDROPS recently, when SIDR closed down = (https://datatracker.ietf.org/wg/sidr/about/). >=20 > The document was originally a BCP = (https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but = was changed to Standards Track in -10 = (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). >=20 >=20 > I have gone back through the agenda and minutes for IETF 92 = (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 = (https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 = (https://datatracker.ietf.org/doc/agenda-94-sidr/).=20 > I also went back and watched the video recordings from IETF 94: = https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any = discussion of why the change was made, but I *was* able to find some = changes made between -09 and -10 which seem to be the outcome of those = discussions.=20 >=20 > Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the = track change was made?=20 >=20 > Whatever the case, the IETF LC was done as Standards Track (a higher = level), and so it could always be "downgraded" to BCP / informational = during IESG Eval. > I personally think it "feels" like BCP, but I don't have full history = / inherited the document and don't want to be arbitrarily making = changes. >=20 >=20 > W > [0]: SIDROPS and SIDR participant overlap is almost 100%. >=20 >=20 > =20 > Scott >=20 > > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: > >=20 > > mornin=E2=80=99 scott, > >=20 > >> it is hard to see why it should be standards track or why it should=20= > >> be using RFC 2119 type terminology. > >=20 > > these are two separate issues. =20 > >=20 > > alvaro and the chairs can adjudicate what flavor of ice cream it = should > > be. it my memory says it was a wg decision. i really do not care. > >=20 > > as to 2119 language, i kinda feel it should remain. it is used > > sparingly. but is crucial when used. e.g. > >=20 > > all private keys MUST be protected when at rest in a secure > > fashion. > >=20 > > i suspect we would want to keep that strongly prescriptive; but it = is > > not a hill on which i am interested in dying. > >=20 > > randy >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad = idea in the first place. > This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. > ---maf > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Jan 16 12:15:32 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81595131131 for ; Wed, 16 Jan 2019 12:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.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 ARNPsoLE1b9H for ; Wed, 16 Jan 2019 12:15:14 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 A8B36131130 for ; Wed, 16 Jan 2019 12:15:08 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id s12so8463233wrt.4 for ; Wed, 16 Jan 2019 12:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=irUvobGH9rOn+AXxosD0ppx775WHBWv3GKvd/S+nyGTHuuKrt6tf2i4Y03gxhZYAPp 2Tp3ktkHkqZnbxeiEhqTnvwrltJ2oQP5IgZvDwLPdGC+pMbeP7zqVF5Mh6inWJNgdOXu RAyBRiXnU5+kS59KLhLr4zFL4NwaoJ4gUKlvKHS7qbfrjwqhHwHe9d6Cfur8fKhh0Vxe jAeSjTzH1aMuC/1G3PPi2eoR25zR8f3dkhvZHmGzBi2BGLN/O65ikAJcQFno31J0XIr6 e7WYenmGWcml5NwxByxS4W5Er5OXSr/rcHfQ1+4o+Bs5kDaUhO++dFa7xBg4pw7WtAIH Xi5A== 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=HFNZ89Ckctn1lBaFaEEAVaWdtcVXA36whUt0I2UCWGg=; b=M0oEJluIGIbllHv21YmTHDfOc8toAknVSz9Cn71t5/+Jh9uLoahHavq1OSKB2HO+00 pMTo6jfWXUGeThC5yUSOf2EYQB8CbFZOptTIjM3Fx0fY+TzMP8vMwwwA3NEoiRdZHrSW VovRWZ3hOZxG+5mjBVtjBYJ7nHjmstn1dnbHg0B8UEcQ2Ez28KQ+9TuGoW5EkGy+Brpj d2YUA6AiWgQlESAxMywrZa90n2wWGrhWUfRHFb/5sUZZ2sttHr1cLOo+g7oUl33EkHxI ULsweWfEWrKmDNKLrtOxy8L5eQRYC1KoK+P5usHgUcQrOn906+tbRwjxKa55cZCc1Gm5 Irew== X-Gm-Message-State: AJcUukca48gzlhVf9R8KxMzhPPexnPBMLAvqcXiTJDJ9VtT5tOxIqacF LAIex7FHl+xDu6jF6KxgxA3Soub5MmuEn9+KYO7sPg== X-Google-Smtp-Source: ALg8bN54OJsrsgCj4s5bNJ5BXNTozwjr7DY7dipfscK5jXZYw6aQx6W99sKm4qTQG3QRsyd4hmO1Klll8nBpGm7wGTk= X-Received: by 2002:adf:f0c5:: with SMTP id x5mr8649261wro.77.1547669706604; Wed, 16 Jan 2019 12:15:06 -0800 (PST) MIME-Version: 1.0 References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> In-Reply-To: <0D959FE6-928D-48E0-B748-A372F67F8B96@sn3rd.com> From: Warren Kumari Date: Wed, 16 Jan 2019 15:14:30 -0500 Message-ID: To: Sean Turner Cc: Christopher Morrow , Scott Bradner , SIDROps Chairs , ops-dir , IETF Discuss , SIDR Operations WG , sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000001799f9057f98efd2" Archived-At: Subject: Re: [Sidrops] [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-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: Wed, 16 Jan 2019 20:15:20 -0000 --0000000000001799f9057f98efd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2019 at 11:56 PM Sean Turner wrote: > Apologies for just finding this now =E2=80=A6 > > I seem to remember a WG discussion about whether this draft should be BCP > or ST. We discussed BCP addressing both what the IETF wanted to be the > best practice as well as what is the actual current practice. Since BGPs= ec > was/is new it was/is hard to say it fell in the latter bucket and there w= as > at least one person who felt that the router and operator driven methods > weren=E2=80=99t the way to go in the future (hence why there is s8 the "a= dvanced > deployment scenarios=E2=80=9D section). So the WG said go ST and because= this > draft has exhausted me we just changed it to ST. Ah, awesome, I'm glad someone remembers the original reason. > I will note that the SECDIR and RTGDIR both had this same comment it seem= s > like we=E2=80=99re back to BCP. I think there was another message somewh= ere about > changing this to BCP so I will do that in -03 unless I hear otherwise. > Yes please, and thank you for solving the mystery. W > > spt > > > On Dec 26, 2018, at 08:29, Christopher Morrow > wrote: > > > > BCP seems like a fine answer here, I'm not remembering why we would hav= e > swapped to ST from BCP. > > > > On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari > wrote: > > [ + Sandy, Alvaro ] > > > > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > > that use of a MUST is commendable but its not exactly an > interoperability issue > > > > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in= this document) > > > > but, that said, 2119 has been misused for kinda a long time so its not = a > new sin > > > > > > This document has a long history -- it was originally a product of the > SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over t= o > SIDROPS recently, when SIDR closed down ( > https://datatracker.ietf.org/wg/sidr/about/). > > > > The document was originally a BCP ( > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was > changed to Standards Track in -10 ( > https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). > > > > > > I have gone back through the agenda and minutes for IETF 92 ( > https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 ( > https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 ( > https://datatracker.ietf.org/doc/agenda-94-sidr/). > > I also went back and watched the video recordings from IETF 94: > https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any > discussion of why the change was made, but I *was* able to find some > changes made between -09 and -10 which seem to be the outcome of those > discussions. > > > > Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the > track change was made? > > > > Whatever the case, the IETF LC was done as Standards Track (a higher > level), and so it could always be "downgraded" to BCP / informational > during IESG Eval. > > I personally think it "feels" like BCP, but I don't have full history / > inherited the document and don't want to be arbitrarily making changes. > > > > > > W > > [0]: SIDROPS and SIDR participant overlap is almost 100%. > > > > > > > > Scott > > > > > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: > > > > > > mornin=E2=80=99 scott, > > > > > >> it is hard to see why it should be standards track or why it should > > >> be using RFC 2119 type terminology. > > > > > > these are two separate issues. > > > > > > alvaro and the chairs can adjudicate what flavor of ice cream it shou= ld > > > be. it my memory says it was a wg decision. i really do not care. > > > > > > as to 2119 language, i kinda feel it should remain. it is used > > > sparingly. but is crucial when used. e.g. > > > > > > all private keys MUST be protected when at rest in a secure > > > fashion. > > > > > > i suspect we would want to keep that strongly prescriptive; but it is > > > not a hill on which i am interested in dying. > > > > > > randy > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad ide= a > in the first place. > > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > > ---maf > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000001799f9057f98efd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Apologies for just finding this no= w =E2=80=A6

I seem to remember a WG discussion about whether this draft should be BCP o= r ST.=C2=A0 We discussed BCP addressing both what the IETF wanted to be the= best practice as well as what is the actual current practice.=C2=A0 Since = BGPsec was/is new it was/is hard to say it fell in the latter bucket and th= ere was at least one person who felt that the router and operator driven me= thods weren=E2=80=99t the way to go in the future (hence why there is s8 th= e "advanced deployment scenarios=E2=80=9D section).=C2=A0 So the WG sa= id go ST and because this draft has exhausted me we just changed it to ST.= =C2=A0

Ah, awesome, I'm glad someone remem= bers the original reason.

=C2=A0
I will note that the SECDIR and RTGDIR bot= h had this same comment it seems like we=E2=80=99re back to BCP.=C2=A0 I th= ink there was another message somewhere about changing this to BCP so I wil= l do that in -03 unless I hear otherwise.

Ye= s please, and thank you for solving the mystery.
W

=C2= =A0

spt

> On Dec 26, 2018, at 08:29, Christopher Morrow <morrowc.lists@gmail.com> wr= ote:
>
> BCP seems like a fine answer here, I'm not remembering why we woul= d have swapped to ST from BCP.
>
> On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari <warren@kumari.net> wrote:
> [ + Sandy, Alvaro ]
>
> On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner <sob@sobco.com> wrote:
> that use of a MUST is commendable but its not exactly an interoperabil= ity issue
>
> to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases i= n this document)
>
> but, that said, 2119 has been misused for kinda a long time so its not= a new sin
>
>
> This document has a long history -- it was originally a product of the= SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to= SIDROPS recently, when SIDR closed down (https://datatra= cker.ietf.org/wg/sidr/about/).
>
> The document was originally a BCP (https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), bu= t was changed to Standards Track in -10 (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt= ).
>
>
> I have gone back through the agenda and minutes for IETF 92 (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF= 93 (https://datatracker.ietf.org/doc/agenda-93-sidr= /) and IETF 94 (https://datatracker.ietf.org/doc= /agenda-94-sidr/).
> I also went back and watched the video recordings from IETF 94: https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find= any discussion of why the change was made, but I *was* able to find some c= hanges made between -09 and -10 which seem to be the outcome of those discu= ssions.
>
> Authors / SIDROPS [0] & SIDR / chairs -=C2=A0 can y'all rememb= er why the track change was made?
>
> Whatever the case, the IETF LC was done as Standards Track (a higher l= evel), and so it could always be "downgraded" to BCP / informatio= nal during IESG Eval.
> I personally think it "feels" like BCP, but I don't have= full history / inherited the document and don't want to be arbitrarily= making changes.
>
>
> W
> [0]: SIDROPS and SIDR participant overlap is almost 100%.
>
>
>=C2=A0
> Scott
>
> > On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
> >
> > mornin=E2=80=99 scott,
> >
> >> it is hard to see why it should be standards track or why it = should
> >> be using RFC 2119 type terminology.
> >
> > these are two separate issues.=C2=A0
> >
> > alvaro and the chairs can adjudicate what flavor of ice cream it = should
> > be.=C2=A0 it my memory says it was a wg decision.=C2=A0 i really = do not care.
> >
> > as to 2119 language, i kinda feel it should remain.=C2=A0 it is u= sed
> > sparingly. but is crucial when used.=C2=A0 e.g.
> >
> >=C2=A0 =C2=A0 =C2=A0 all private keys MUST be protected when at re= st in a secure
> >=C2=A0 =C2=A0 =C2=A0 fashion.
> >
> > i suspect we would want to keep that strongly prescriptive; but i= t is
> > not a hill on which i am interested in dying.
> >
> > randy
>
>
>
> --
> I don't think the execution is relevant when it was obviously a ba= d idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing= regret at having chosen those particular rabid weasels and that pair of pa= nts.
>=C2=A0 =C2=A0 ---maf
> _______________________________________________
> sidr mailing list
> sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000001799f9057f98efd2-- From nobody Wed Jan 16 18:49:21 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D0E130E9C; Wed, 16 Jan 2019 18:49:19 -0800 (PST) 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: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154769335987.29652.8078024034193408502@ietfa.amsl.com> Date: Wed, 16 Jan 2019 18:49:19 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-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, 17 Jan 2019 02:49:20 -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 : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidrops-rtr-keying-03.txt Pages : 18 Date : 2019-01-16 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rtr-keying-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 Wed Jan 16 18:50:59 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D043130F4C for ; Wed, 16 Jan 2019 18:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 a2lgbeB1NinI for ; Wed, 16 Jan 2019 18:50:56 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 E0E93130F3A for ; Wed, 16 Jan 2019 18:50:55 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id e5so9735691qtr.12 for ; Wed, 16 Jan 2019 18:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=3qyrMWuf7upo5z7EHU7K/s7WZLoCVPJGRNkuv/pviW0=; b=G9Ij87Jiay4l0i6FB/fz0QhbijtKA20vXe1dtR8Nztpy+YXYwl8b8gUqkcU5Oqy4RA b4CWCHL7EVtT0qjT3ZyYiSlrmjrX0eRjNqXAWjQePaeDCpGv1k94qkDksmrupk44moRp 0XF06VS1CTm3qhXOi3jKBK/LzSedet64bPwLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=3qyrMWuf7upo5z7EHU7K/s7WZLoCVPJGRNkuv/pviW0=; b=F2BqdZpWK98A4moHsp17l6wzaVUK/YoMuQfP8EJjCBp+DdzCLcdxwZQGeSXXaQmxEC z29Dp7eUu8jHjb/H3UkQ67PF7654oGvH569p4dJiggytyapEvGipY56C6KLLlOpTLhOT cVA8ZN2dtvXrdVX8pqpGGybxmViBqoPZ51EyWSh8xOoyKCa2/8CmViP94LFtW4th3QB8 WS0dErhJT+QzUAtd6vjrIcH/Tb7IK8KQ6n8CZA8pHjFG/x6eBr0ihxm3PfvKycHhdeZr jUDJk2qqt1kFJs8iV9qfvM1p/tL6ePaDzVDoeKqdx6fUjmn0EIw1soUnLuLZzB5y1vBb 9ZBA== X-Gm-Message-State: AJcUukdMcWosmN6XnDL3d9CDflB9ANJogXQ1FLAYiVpg/O7Md1W+nBtJ 7XWHZ4ez8TJYB/+82OAiRf4RPC47rD5KEw== X-Google-Smtp-Source: ALg8bN44ZPEgflFLPA0uJAGXCXwoCf1MAKKAYaMqNC/rT/PZTht9ItP1YZ0u21FDIdCvjGVAE9z3YQ== X-Received: by 2002:aed:37e7:: with SMTP id j94mr9914498qtb.282.1547693454901; Wed, 16 Jan 2019 18:50:54 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id w52sm59605849qtc.51.2019.01.16.18.50.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 18:50:54 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 16 Jan 2019 21:50:53 -0500 References: <154769335987.29652.8078024034193408502@ietfa.amsl.com> To: SIDR Operations WG In-Reply-To: <154769335987.29652.8078024034193408502@ietfa.amsl.com> Message-Id: <97582DFB-9AAE-4080-A95E-C8A6D24FF2F3@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-03.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: Thu, 17 Jan 2019 02:50:57 -0000 This version addresses the SECDIR and OPSDIR comments. The biggest = change was to change the intended status to BCP. spt > On Jan 16, 2019, at 21:49, 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 : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidrops-rtr-keying-03.txt > Pages : 18 > Date : 2019-01-16 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys in order = to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two = methods > of generating the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-03 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rtr-keying-03 >=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jan 21 03:46:10 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F050F12DD85; Mon, 21 Jan 2019 03:46:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154807116197.8204.4725884576566449203.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2019 03:46:01 -0800 Archived-At: Subject: [Sidrops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sidrops-rtr-keying-03=3A_=28with_COMMENT=29?= 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: Mon, 21 Jan 2019 11:46:02 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in the security considerations section. If not, it might be worth moving Appendix A to the main body of the document. From nobody Mon Jan 21 09:28:01 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27234124D68; Mon, 21 Jan 2019 09:27:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2019 09:27:53 -0800 Archived-At: Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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: Mon, 21 Jan 2019 17:27:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I know the intended status has been beaten to near death already, but I could see this as Informational as well as BCP. Section 1 For example, when an operator wants to support hot-swappable routers, the same private key needs to be installed in the soon-to-be online router that was used by the the soon-to-be offline router. This motivated the operator-driven method As the secdir review notes, there is no need to copy private keys to hot-swap routers (unless there is something special about the "hot-swap" case that nullifies the arguments he made?). It rather seems that we should avoid framing this behavior as justified by a need for hot-swapping, but rather as something that people do to work around processes that do not admit the more secure workflow, as an operational reality. Section 2 (see [RFC6470]), the protected the protected channel between the nit: duplicate "the protected" Section 5 The PKCS#10 request SHOULD be saved to enable verifying that the returned public key in the certificate corresponds to the private used to generate the signature on the CSR. I mostly assume this is done by the party that generates the CSR, though perhaps one could read it as being done on the router always. (I guess later on we do recommend both the operator and router to do this verification.) This could be reworded, though, either to remove the 2119 language ("Retaining the CSR allows for verifying that [...]" or to apply to the actual verification as opposed to just the saving. Section 5.1 NOTE: If a router were to communicate directly with a CA to have the CA certify the PKCS#10 certification request, there would be no way for the CA to authenticate the router. As the operator knows the authenticity of the router, the operator mediates the communication with the CA. nit: I think that the thing we care about here is the CA's ability to show that the request is authorized. The operator is assumed to have an account/relationship with the CA and a channel via which to authorize cert-signing requests. In particular, "no way" is a rather strong statement, and would seem to deny the possibility of a three-party workflow where the router sends the CSR to the CA but the operator logs in to the CA independently and is presented with a list of pending requests to approve. (It would also preclude the operator from delegating their authorization at the CA to the router, as described in Section 8.) Section 5.2 ("Operator-Generated Keys") Even if the operator cannot extract the private key from the router, this signature still provides a linkage between a private key and a router. That is, the operator can verify the proof of possession (POP), as required by [RFC6484]. This paragraph seems a bit of a non-sequitur -- if the operator just generated the key, it sure isn't going to need to extract the private key from the router to sign something using it! Section 6 In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message, and verify that the private key it holds corresponds to the returned public key. If the nit: "private key it holds" is the one the operator holds, not the PKCS#7 certs-only message. It's probably worth disambiguating, here. Section 7 NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8 permits more advanced configurations where the entity that generates the keys is not the direct CA. Why are we talking about PKCS#8 (asymmetric key transport) signatures here at all? This is the section about installing certificates! I guess I am not terribly familiar with the RPKI, but in the Web PKI at least it's quite uncommon for the CA to be generating the private keys, so mentioning these together is a non sequitur to me. Section 8 More PKI-capable routers can take advantage of this increased functionality and lighten the operator's burden. Typically, these nit: most readers will not bind "this" to the right thing and will instead be left confused. Why do we not mention the need to get the manufacturer-installed key material (or information thereof) to the operator? When a router is so configured, the communication with the CA SHOULD be automatically re-established by the router at future times to renew or rekey the certificate automatically when necessary (See Section 9). This further reduces the tasks required of the operator. Mentioning renewing certificates is natural, as they have a stated end time to prepare for. Re-keying certificates is something of a different matter, and it would be nice to provide (a link to) some guidance on what timescales at which to rekey, if we're mentioning rekeying here. (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I did not see much concrete on this point.) Section 9.4 Currently routers often generate private keys for uses such as SSH, and the private keys may not be seen or off-loaded from the router. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software which accesses the router must be updated with the new keys. Also, This seems to be talking about key management for keys other than BGPsec-signing keys. Isn't that out of scope for this document? any network based initial contact with a new routing engine requires trust in the public key presented on first contact. To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to be inserted via a Making this a SHOULD is perhaps an overstatement, since AFAICT this functionality is not useful for the stated purpose unless the operator has access to private keys directly (whether by virtue of the operator having generated the keys or an extraction interface on the current routers). This is an inherent tradeoff, as stated, between the delay in update/distribution of public keys in the RPKI vs. reducing the risk of unauthorized key access. I'm not making this a Discuss point because it's not exactly my tradeoff to make, but I do want to be sure that this is actually the tradeoff that SIDROPS wants to present to the community. protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This lets the operator escrow the old private key via the mechanism used for operator-generated keys, see Section 5.2, such that it can be re- inserted into a replacement router. The router MAY allow the private key to be to be off-loaded via the protected channel, but this SHOULD be paired with functionality that sets the key into a permanent non- exportable state to ensure that it is not off-loaded at a future time by unauthorized operations. This last sentence is a somewhat different topic and could probably stand alone as its own paragraph. This would also provde the opportunity to clarify that this offload interface is intended for use in conjunction with key generation, and the permanent non-exportable state to be applied thereafter. Appendix A I agree with Mirja about the duplication of content and thus non-need for normative language. From nobody Tue Jan 22 19:26:31 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833B9130E0E; Tue, 22 Jan 2019 19:26:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 19:26:22 -0800 Archived-At: Subject: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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: Wed, 23 Jan 2019 03:26:23 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct status? (I agree with BCP, by the way.) - I share Benjamin's concern about the idea of moving private keys between routers as a "need" vs "something people do". §5.2.1: "The router should inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope." Should that be normative? §9.3: The second paragraph is a single convoluted sentence. Can it be broken into simpler sentences? §10: - "This document defines no protocols. So, in some sense, it introduces no new security considerations." I think practices can absolutely come with security considerations. For example, the practice of moving private keys between routers. - "Private key protection in transit": Is there no expectations that transmitted private keys would have object-level encryption? §A: I'm curious why this is not part of the main-body security considerations? From nobody Tue Jan 22 20:09:45 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE391130E16; Tue, 22 Jan 2019 20:09:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154821657076.13328.13662061490601279410.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 20:09:30 -0800 Archived-At: Subject: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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: Wed, 23 Jan 2019 04:09:31 -0000 Adam Roach has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for a well-written and clear document. I have one substantive comment, and a minor editorial nit. --------------------------------------------------------------------------- §3: > - Using FTP or HTTP per [RFC2585], and It's not clear from a casual examination whether use of unencrypted and non-integrity-protected channels for these operations are safe. I would expect to see a discussion of this in this section and/or section 10. The closest I could find is the SHOULD-strength (!) recommendation for transport-level security for private key transport. Without a more thorough analysis, I suspect we should more strongly deprecate the use of unencrypted/non-integrity-protected transports. This document is, after all, supposed to be calling out best practice; and, in 2019, that really does entail transport security except under the most exceptional circumstances. --------------------------------------------------------------------------- §2: > Though other configuration mechanisms might be used, e.g. NetConf > (see [RFC6470]), the protected the protected channel between the Nit: duplicate "...the protected..." From nobody Tue Jan 22 20:31:48 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116A1130E0A; Tue, 22 Jan 2019 20:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bNPSi-HJzPTt; Tue, 22 Jan 2019 20:31:44 -0800 (PST) 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 539E7130DFA; Tue, 22 Jan 2019 20:31:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gmACU-0002t3-Ny; Wed, 23 Jan 2019 04:31:43 +0000 Date: Tue, 22 Jan 2019 20:31:41 -0800 Message-ID: From: Randy Bush To: Ben Campbell Cc: The IESG , SIDR Operations WG In-Reply-To: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com> References: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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, 23 Jan 2019 04:31:46 -0000 on the issue of uploading private keys. how the wg got where we are. essentially, we made the mistake of letting operators in. it's 2am. the bleeping device melted. a new key generated by a replacement device will take a good while to get into the rpki and then many more hours to get into everybody's bgpsec validation key caches around the planet [ask geoff why he insisted he did not have to publish more frequently than once a day]. and by 3am, people with shiny shoes will be giving the op snake eyes that customers in tiblisi can't give them money online right now. when the op tells them it will be tomorrow afternoon, it is usually referred to as a resume generating event. randy From nobody Wed Jan 23 01:11:39 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6DE130E59; Wed, 23 Jan 2019 01:11:15 -0800 (PST) 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: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154823467586.7485.17416366729552218933@ietfa.amsl.com> Date: Wed, 23 Jan 2019 01:11:15 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.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: Wed, 23 Jan 2019 09:11:16 -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 : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Tim Bruijnzeels Filename : draft-ietf-sidrops-https-tal-06.txt Pages : 10 Date : 2019-01-23 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). TALs allow Relying Parties in the RPKI to download the current Trust Anchor (TA) CA certificate from one or more locations, and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys, but allow these TAs to change the content of their CA certificate. In particular it allows TAs to change the set of Internet Number Resources included in the RFC3779 extension of their certificate. This document obsoletes the previous definition of Trust Anchor Locators in RFC 7730 by adding support for HTTPS URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-06 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 Wed Jan 23 01:17:00 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA55130E78 for ; Wed, 23 Jan 2019 01:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 JWcto1aksn8K for ; Wed, 23 Jan 2019 01:16:56 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.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 74146130E62 for ; Wed, 23 Jan 2019 01:16:56 -0800 (PST) Received: from [IPv6:2a04:b900::1:24d3:bc8d:c6c0:da53] (unknown [IPv6:2a04:b900:0:1:24d3:bc8d:c6c0:da53]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2F8F61E2BD; Wed, 23 Jan 2019 10:16:54 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1548235014; bh=PHdwDbpltVkYMMWT+/sjSkfPrBExvZ+PaIwRtlnSMfE=; h=Subject:From:In-Reply-To:Date:References:To; b=T59XEgdsgmh8cUjaMyh0byu0GtT1sddDRw1ixtgANS6qshA/aD/n59/y8AZdHG6ZS c7lkZnpjUaJNkEPR6IX315O8hqY7FGXk1CwIghzfgFODejImtToifzwo+Qk6OwD1xn wV3qP2kfDxl6/XmHE6fQa8/A+erEADwp9Cpk//Ek= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <154823467586.7485.17416366729552218933@ietfa.amsl.com> Date: Wed, 23 Jan 2019 10:16:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.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, 23 Jan 2019 09:16:59 -0000 Dear WG, This version address the comments made after the unclosed last call for = -05. * There is now no blank line between the comments and the URIs. * Relying Parties MUST now do TLS verification (from SHOULD) and text = that was there arguing that unsafe transport is not a huge issue when = there is object security has been removed. * Job Snijders is acknowledged for suggesting the comments section. Please have a look and speak up if you see any remaining issues. This = should have been a simple change, but we're talking about this for = almost a year now. If I get no comments by the end of next week, then I = will try asking for last call once again, but I hope to avoid having to = make a version -07. Thanks Tim > On 23 Jan 2019, at 10:11, 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) = Trust Anchor Locator > Authors : Geoff Huston > Samuel Weiler > George Michaelson > Stephen Kent > Tim Bruijnzeels > Filename : draft-ietf-sidrops-https-tal-06.txt > Pages : 10 > Date : 2019-01-23 >=20 > Abstract: > This document defines a Trust Anchor Locator (TAL) for the Resource > Public Key Infrastructure (RPKI). TALs allow Relying Parties in the > RPKI to download the current Trust Anchor (TA) CA certificate from > one or more locations, and verify that the key of this self-signed > certificate matches the key on the TAL. Thus, Relying Parties can = be > configured with TA keys, but allow these TAs to change the content = of > their CA certificate. In particular it allows TAs to change the set > of Internet Number Resources included in the RFC3779 extension of > their certificate. >=20 > This document obsoletes the previous definition of Trust Anchor > Locators in RFC 7730 by adding support for HTTPS URIs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-https-tal-06 >=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jan 23 09:46:51 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9DA130FB5; Wed, 23 Jan 2019 09:46:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154826560230.7563.12584828485918011085.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 09:46:42 -0800 Archived-At: Subject: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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: Wed, 23 Jan 2019 17:46:43 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I don't really have a strong objection for this document being a BCP. However, while documenting two different methods, there is no clear indication of "what is believed to be the best" [rfc2026], or even better, which method should be used in what situations. I understand that operators have different preferences/needs and that prescribing one method as the default in not the right thing to do. I would really like to see some text (maybe a "Deployment Considerations" section) that talks about when one or the other might be preferred/considered. (2) §4: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286] (3) §4: "In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the BGP Identifier as always being non-zero. rfc8209 says that "if the same certificate is issued to more than one router (and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer." It seems to me that it doesn't matter which ID is used...it just can't be 0. The simple fix is to just remove the sentence. (4) §8: "Enabling the router-to-CA connectivity MAY require connections to external networks (i.e., through firewalls, NATs, etc.)." That "MAY" is out of place because this sentence is just stating a fact. (5) §8: "Note that the checks performed by the router in Section 7...SHOULD be performed." Besides confirming the checks from §7, I'm not sure what this sentence really contributes...but I do think that the "SHOULD" is out of place because the Normative language is already in §7. (6) Nits s/used by the the/used by the s/corresponds to the private used/corresponds to the private key used From nobody Wed Jan 23 11:52:43 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C01512785F; Wed, 23 Jan 2019 11:52:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154827316130.7453.12140820828793016275.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 11:52:41 -0800 Archived-At: Subject: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) 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: Wed, 23 Jan 2019 19:52:41 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As this is a BCP, I don't understand why transport encryption of the private key is not normatively required. Could you explain? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given that this document is ostensibly specifying a "best" current practice, I would have expected a clearer expression of preference for the router-driven method over the operator-driven method, e.g., something like BGPsec-speaking routers MUST implement the router-driven method and MAY implement the operator-driven method. Or if there is some exception case that makes that MUST problematic, it would at least be good to emphasize which one of these is actually "best" from a security perspective, even though the other one is being specified and we know will be used. Nit in Section 1: s/gritty details/details of the BGPsec protocol/ From nobody Wed Jan 23 20:57:52 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B61310C4; Wed, 23 Jan 2019 20:57:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154830586386.7517.12515642346949342885.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 20:57:43 -0800 Archived-At: Subject: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) 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, 24 Jan 2019 04:57:44 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D13996 DETAIL S 2. > > Operators are free to use either the router-driven or operator-driven > method as supported by the platform. Regardless of the method > chosen, operators first establish a protected channel between the > management system and the router. How this protected channel is > established is router-specific and is beyond scope of this document. This seems rather under-specified. Given that we know that people are not careful about this, I think you need to specify some sort of minimum requirements for this channel. That need not be a particular protocol, but it needs to specify the security properties it provides. I see you have some SHOULD-level language later, but I think you need MUST level, and as noted below, I think the guidance is wrong. S 5.2. > the BGP Identifier when it sends the CSR to the CA. > > Even if the operator cannot extract the private key from the router, > this signature still provides a linkage between a private key and a > router. That is, the operator can verify the proof of possession > (POP), as required by [RFC6484]. It's not clear to me what is being claimed in terms of PoP here. As I understand it, the certificate is a binding between the AS number/BGP identifier pair and the public key, but if neither of those is in the PKCS#10 request, then they're not signed over by the private key, and so PoP isn't really operative. The relevant question is whether if I obtain the PKCS#10 request I can obtain a certificate for an identity other than the intended one. S 5.2.1. > ensure the returned private key did in fact come from the operator, > but this requires that the operator also provision via the CLI or > include in the SignedData the RPKI CA certificate and relevant > operator's EE certificate(s). The router should inform the operator > whether or not the signature validates to a trust anchor; this > notification mechanism is out of scope. I don't understand what security this is intended to provide. As I understand it, the way this works is that the operator signs the PKCS#8 package and then sends it to the router, which verifies the signature. This verification is performed based on a key configured by the operator, right? But in that case, if someone obtains operator access to the router, they can just configure their own key, thus bypassing the signature check. Secondarily, I don't understand how this works if the RPKI CA certificate is included in the SignedData, because then how do I validate it against a trust anchor. Finally, how does the router know which of the large number of EEs signed by the RPKI CA it should accept signed PKCS#8 messages from. S 6. > private key it holds corresponds to the returned public key. If the > operator saved the PKCS#10 it can check this correspondence by > comparing the public key in the CSR to the public key in the returned > certificate. If the operator has not saved the PKCS#10, it can check > this correspondence by generating a signature on any data and then > verifying the signature using the returned certificate. It is not clear to me that this is correct. You seem to be assuming that it given a key pair (K_priv, K_pub), it is not possible to generate a new key K_pub' that will validate signatures made with K_priv. This isn't ordinarily an assumption we make of digital signature systems. S 8. > the CA prior to operator initiating the router's CSR. CAs use > authentication material to determine whether the router is > eligible to receive a certificate. Authentication material at a > minimum includes the router's AS number and BGP Identifier as > well as the router's key material, but can also include > additional information. Authentication material can be Surely it also includes some information that allows the router to prove it is entitled to a key with that AS and BGP identifier, but I'm not seeing this here. S 12.1. > CSR you sent; the certificate will include the subject name, serial > number, public key, and other fields as well as being signed by the > CA. After the CA issues the certificate, the CA returns the > certificate, and posts the certificate to the RPKI repository. Check > that the certificate corresponds to the private key by verifying the > signature on the CSR sent to the CA; this is just a check to make This is not the right check. The CSR contains the public key. If you want to check, make sure it is identical to the one in the cert. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1. > These two methods differ in where the keys are generated: on the > router in the router-driven method, and elsewhere in the > operator-driven method. Routers are required to support at least one > of the methods in order to work in various deployment environments. > Some routers may not allow the private key to be off-loaded while > others may. While off-loading private keys would ease swapping of Nit: "off-load" has multiple meanings. I would suggest "exported" S 1. > operator-driven method. Routers are required to support at least one > of the methods in order to work in various deployment environments. > Some routers may not allow the private key to be off-loaded while > others may. While off-loading private keys would ease swapping of > routing engines, exposure of private keys is a well known security > risk. This is a somewhat shallow treatment of this. Specifically: 1. There are multiple ways in which a device might allow a key not to be exported. For instance, there might not be a command, but it might be in unencrypted NVRAM. Or, it might be in an HSM. These have very different security properties. 2. There are designs which allow a key to be moved from device to device without exposure, e.g.,, a hardware token. S 1. > In the router-driven method, the router generates its own > public/private key-pair. > > The router-driven method mirrors the model used by traditional PKI > subscribers; the private key never leaves trusted storage (e.g., > Hardware Security Module). This is by design and supports classic This seems overly concrete. The router may or may not have an HSM, but there are benefits even if it does not. S 1. > ensure that no one can impersonate the subscriber. For non-humans, > this method does not always work. For example, when an operator > wants to support hot-swappable routers, the same private key needs to > be installed in the soon-to-be online router that was used by the the > soon-to-be offline router. This motivated the operator-driven > method. I'm not following this explanation, as it's routine for Internet servers to have keys in software and be able to transfer them from device to device. This is, after all, what PEM files do S 1. > acting as the intermediary. Section 8 describes another method that > requires more capable routers. > > Useful References: [RFC8205] describes gritty details, [RFC8209] > specifies the format for the PKCS#10 certification request, and > [RFC8208] specifies the algorithms used to generate the PKCS#10's Nit "The PKCS#10's signature" is not grammatical S 2. > method as supported by the platform. Regardless of the method > chosen, operators first establish a protected channel between the > management system and the router. How this protected channel is > established is router-specific and is beyond scope of this document. > Though other configuration mechanisms might be used, e.g. NetConf > (see [RFC6470]), the protected the protected channel between the "the protected the protected" S 3. > bis] to return the issued certificate, > > - Using FTP or HTTP per [RFC2585], and > > - Using Enrollment over Secure Transport (EST) protocol per > [RFC7030]. I'm surprised you don't list ACME. S 5. > is sometimes referred to as a Certificate Signing Request (CSR), may > be generated by the router or by the operator. > > The PKCS#10 request SHOULD be saved to enable verifying that the > returned public key in the certificate corresponds to the private > used to generate the signature on the CSR. This is generally not necessary. In most systems, the private key syntax either includes the public key or the public key can be generated from the private key. S 5.1. > > NOTE: If a router were to communicate directly with a CA to have the > CA certify the PKCS#10 certification request, there would be no way > for the CA to authenticate the router. As the operator knows the > authenticity of the router, the operator mediates the communication > with the CA. This doesn't seem like it's necessarily true. For instance, with ACME the operator could provide the router with a credential sufficient to authenticate the request. S 5.2.1. > > 5.2.1. Using PKCS#8 to Transfer Private Key > > A private key can be encapsulated in a PKCS#8 Asymmetric Key Package > > [RFC5958] and should be further encapsulated in Cryptographic Message SHOULD? S 10. > Private key protection in transit: Mistakes here are, for all, > practical purposes catastrophic because disclosure of the private > key allows another entity to masquerade as (i.e., impersonate) the > signer; transport security is therefore strongly RECOMMENDED. The > level of security provided by the transport layer's security > mechanism SHOULD be commensurate with the strength of the BGPsec I'm not sure "commensurate" is what's needed here. For instance, the transport channel might be much more secure than the router key (e.g., P-521 and AES-256 with a RSA-2048 router key). More generally, it's not clear to me that these are really connected at all, as the threat environments are totally different. As noted above, I believe you should just specify a minimal level. S 12.1. > and integrity and replay protection. > > Appendix B. The n00b Guide to BGPsec Key Management > > This appendix is informative. It attempts to explain all of the PKI > technobabble in plainer language. All fields have jargon, but generally deriding another field's language as "technobabble" doesn't seem that helpful. S 12.1. > BGPsec speakers send signed BGPsec updates that are verified by other > BGPsec speakers. In PKI parlance, the senders are referred to as > signers and the receivers are referred to as relying parties. The > signers with which we are concerned here are routers signing BGPsec > updates. Signers use private keys to sign and relying parties use > the corresponding public keys, in the form of X.509 public key They're not in the form of public key certificates, they are carried in certificates. S 12.1. > that will generate the key pair for the algorithms referenced in the > main body of this document; consult your router's documentation for > the specific commands. The key generation process will yield > multiple files: the private key and the public key; the file format > varies depending on the arcane command you issued, but generally the > files are DER or PEM-encoded. Actually, it may or may not generate multiple files. That's implementation specific. From nobody Wed Jan 23 21:33:24 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E78130E0A; Wed, 23 Jan 2019 21:17:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154830702513.7489.16345843750694834385.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 21:17:05 -0800 Archived-At: X-Mailman-Approved-At: Wed, 23 Jan 2019 21:33:22 -0800 Subject: [Sidrops] Terry Manderson's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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, 24 Jan 2019 05:17:05 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought] Thank you for a concise document, and especially thank you for the very informal appendix ("B") to explain BGPsec/PKI key management to people who are more concerned with making sure packets go from "here" to "there" and not be crypto key management experts. I have no strong concerns about document status, but BCP feels about right to me given the art of dealing with key material on routing kit is likely to evolve as experience dictates - that said, I won't be out of shape if the sponsoring AD and the rest of the IESG feels otherwise - however I see that BCP looks like the consensus at this stage. I'm torn about the absence of a clear recommendation to choose between a router-method operator-method. On one hand it seems a deficiency to leave it as "free to choose" without providing a set of considerations that may help direct the operators naive choice, and yet on the other hand the experience gained thus far appears limited and this BCP is yet to find its way, and may well be updated in future. From nobody Thu Jan 24 05:16:50 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D3F130E6E; Thu, 24 Jan 2019 05:16:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux To: "The IESG" Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154833578539.25088.8998015406968018020.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2019 05:16:25 -0800 Archived-At: Subject: [Sidrops] Martin Vigoureux's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) 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, 24 Jan 2019 13:16:25 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, thank you for this Document. I only have a couple of questions: In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message, and verify that the private key it holds corresponds to the returned public key. The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. I believe SHOULD applies to extract and to verify, correct? But I wonder why isn't that a MUST, or asked differently, what could happen wrong if that verification was not done? Thank you From nobody Mon Jan 28 14:05:23 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FBB13115A for ; Mon, 28 Jan 2019 14:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 l9EFDCH6t5f8 for ; Mon, 28 Jan 2019 14:05:20 -0800 (PST) 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 2CC49130EDD for ; Mon, 28 Jan 2019 14:05:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1goF1q-0002yz-2X for sidrops@ietf.org; Mon, 28 Jan 2019 22:05:18 +0000 Date: Mon, 28 Jan 2019 14:05:17 -0800 Message-ID: From: Randy Bush To: SIDR Operations WG References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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: [Sidrops] draft-ymbk-sidrops-ov-signal-02.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, 28 Jan 2019 22:05:21 -0000 i would like to put draft-ymbk-sidrops-ov-signal-02.txt on the agenda for praha. discussion so far: there was one red herring; outsourcing security. as this was discussed in the draft, i can only assume actual reading helped. the substantial issues raised in the meeting (i found nothing in the mailing list archives) seems to be the signaling/transport. let's focus on this. these seem to be three general alternatives for signaling. in-band, as described in the draft, uses an extended community. alternatively it could use a new attribute or other hack. such alternative in-band mechanisms could be discussed/investigated. a new afi/safi, which did not get rousing support from router implementors who would have to create and support a whole new afi/safi for the task. of course, creative folk could undoubtedly find more things to do with the new afi/safi if they get bored with bgp-ls:) augment the rpki-rtr protocol to allow the router to signal back to the cache one or more invalid routes. but then what happens with those data? if the cache will signal those to router clients, then those router clients will have done the evaluation on their own. these are the thoughts which led us to in-band signaling. but this is certainly worth discussing, here, praha, or both. randy From nobody Mon Jan 28 21:25:23 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11999130E86; Mon, 28 Jan 2019 21:25:22 -0800 (PST) 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: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154873952201.2863.14639503968117019865@ietfa.amsl.com> Date: Mon, 28 Jan 2019 21:25:22 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rp-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: Tue, 29 Jan 2019 05:25:22 -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 : Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties Authors : Di Ma Stephen Kent Filename : draft-ietf-sidrops-rp-03.txt Pages : 11 Date : 2019-01-28 Abstract: This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rp-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rp-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 Mon Jan 28 21:49:30 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8914A130ED9 for ; Mon, 28 Jan 2019 21:49:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MADHbuLk6EdK for ; Mon, 28 Jan 2019 21:49:24 -0800 (PST) Received: from out20-99.mail.aliyun.com (out20-99.mail.aliyun.com [115.124.20.99]) (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 087AF130EA4 for ; Mon, 28 Jan 2019 21:49:22 -0800 (PST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.07623341|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03299; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.Ds.nIck_1548740958; Received: from 192.168.218.235(mailfrom:madi@rpstir.net fp:SMTPD_---.Ds.nIck_1548740958) by smtp.aliyun-inc.com(10.147.41.231); Tue, 29 Jan 2019 13:49:18 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: <154873952201.2863.14639503968117019865@ietfa.amsl.com> Date: Tue, 29 Jan 2019 13:49:17 +0800 Cc: Di Ma Content-Transfer-Encoding: quoted-printable Message-Id: <83DCD4EC-BEEF-443F-A933-E8F600E2CD58@rpstir.net> References: <154873952201.2863.14639503968117019865@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rp-03.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, 29 Jan 2019 05:49:29 -0000 Hi, folks, We authors just updated this draft as follow:=20 1) TAL Considering draft-ietf-sidrops-https-tal seems to be ready for WGLC, we = authors replaced RFC 7730 with it where the TAL topics are mentioned. 2) Distributing RPKI validated cache In light of a new model of how RP service the validated cache, which by = the way, has been used by Cloudflare, we authors are slightly changed = the description in Section 5 in terms of distributing RPKI validated = cache.=20 That is, the RP may deliver the validated cache via HTTPs to a cache = server who is responsible for provisioning validated cache to BGP = speakers. https://blog.cloudflare.com/rpki-details/ We think this method is making sense for big ISPs, ICPs and a third = party RP in the cloud.=20 And RPSTIR (bgpsecurity.net) the RP software has also supported = transferring validated cache via https, which is expected to go public = in Github this year.=20 We would appreciate your comments. And if there is no major changed needed hereafter, we expect WGLC issued = for this document.=20 Di > =D4=DA 2019=C4=EA1=D4=C229=C8=D5=A3=AC13:25=A3=ACinternet-drafts@ietf.or= g =D0=B4=B5=C0=A3=BA >=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 : Requirements for Resource Public Key = Infrastructure (RPKI) Relying Parties > Authors : Di Ma > Stephen Kent > Filename : draft-ietf-sidrops-rp-03.txt > Pages : 11 > Date : 2019-01-28 >=20 > Abstract: > This document provides a single reference point for requirements for > Relying Party (RP) software for use in the Resource Public Key > Infrastructure (RPKI) in the context of securing Internet routing. > It cites requirements that appear in several RPKI RFCs, making it > easier for implementers to become aware of these requirements that > are segmented with orthogonal functionalities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rp-03 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rp-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rp-03 >=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jan 29 02:13:08 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54425130F4A for ; Tue, 29 Jan 2019 02:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 L4wcNt8p-9S1 for ; Tue, 29 Jan 2019 02:13:04 -0800 (PST) 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 82861130F47 for ; Tue, 29 Jan 2019 02:13:04 -0800 (PST) Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id F331F1F7C1; Tue, 29 Jan 2019 11:13:00 +0100 (CET) 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=1548756781; bh=GMzx/cTvsbt6qGGtgRdbBGVmzMASjScvy9WK1zIsNfw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=luWyC3xKBLdsZGC0Q7a3RqXCnvdIjxUDoRB7Ci3KKyRwSIC0tn3aknipDjcNnUYBP cxuo/5I8gUopI7X5YEzs/RsLYUy2rni7jYs6Z9dXxc1c/ZIH8WB80PJfT7ls3cVeIh 0lwwERqrlx6XS3l7wuNI2CYN8POvRR7X9u9QXX7g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 29 Jan 2019 11:13:00 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02.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, 29 Jan 2019 10:13:06 -0000 Hi Randy, all, I have a question: why is signalling OV (within a trust boundary) = preferable over doing OV? If signalling is desired, then the community seems plausible enough to = me, albeit that it's not clear to me how this is easier on the router = than doing OV in the first place. A lot of routers support this now, = and there are more and more lightweight RP options. But I may well miss = the operational reason for this, so don't take this as opposition. Tim > On 28 Jan 2019, at 23:05, Randy Bush wrote: >=20 > i would like to put draft-ymbk-sidrops-ov-signal-02.txt on the agenda > for praha. discussion so far: >=20 > there was one red herring; outsourcing security. as this was > discussed in the draft, i can only assume actual reading helped. >=20 > the substantial issues raised in the meeting (i found nothing in the > mailing list archives) seems to be the signaling/transport. let's > focus on this. >=20 > these seem to be three general alternatives for signaling. >=20 > in-band, as described in the draft, uses an extended community. > alternatively it could use a new attribute or other hack. such > alternative in-band mechanisms could be discussed/investigated. >=20 > a new afi/safi, which did not get rousing support from router > implementors who would have to create and support a whole new = afi/safi > for the task. of course, creative folk could undoubtedly find more > things to do with the new afi/safi if they get bored with bgp-ls:) >=20 > augment the rpki-rtr protocol to allow the router to signal back to > the cache one or more invalid routes. but then what happens with > those data? if the cache will signal those to router clients, then > those router clients will have done the evaluation on their own. >=20 > these are the thoughts which led us to in-band signaling. but this is > certainly worth discussing, here, praha, or both. >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jan 29 06:59:47 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475212D84D for ; Tue, 29 Jan 2019 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 scOokKuPuhRJ for ; Tue, 29 Jan 2019 06:59:44 -0800 (PST) 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 66BBD126F72 for ; Tue, 29 Jan 2019 06:59:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1goUrW-00077C-Dl; Tue, 29 Jan 2019 14:59:42 +0000 Date: Tue, 29 Jan 2019 06:59:41 -0800 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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] draft-ymbk-sidrops-ov-signal-02.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, 29 Jan 2019 14:59:46 -0000 hi tim, ( omg! someone is alive in this wg! :) > I have a question: why is signalling OV (within a trust boundary) > preferable over doing OV? within the trust boundary, one tends to want to manage complex services on fewer devices. route reflection is a poster child; the clients have a restricted number of peers and a minimized consistent view. so it is what we used in the text. Within a routing trust boundary, e.g. an operator's Point of Presence (PoP), it may not be desirable or necessary for all routers to perform Origin Validation using the Resource Public Key Infrastructure (RPKI) per [RFC6811]. A good example is route reflectors (see [RFC4456]). a pop may have a few dozen routers. no need to run rpki-rtr and full validation on them all. > If signalling is desired, then the community seems plausible enough to > me, albeit that it's not clear to me how this is easier on the router > than doing OV in the first place. one can do it with policy, no need for a whole rpki-rtr client and validation. randy