From nobody Wed Aug 2 07:50:10 2017 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 6944A132118 for ; Wed, 2 Aug 2017 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 JcOQO-f5TnRb for ; Wed, 2 Aug 2017 07:50:04 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 59EF4131CA2 for ; Wed, 2 Aug 2017 07:50:04 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id n125so18800226vke.1 for ; Wed, 02 Aug 2017 07:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fmBSgM1RnRzXpCABmp4imdNRCidN3khdHwguCfXrtlk=; b=1ZTy2LmUVJUlyuZt1g6h5+q6+DBQdyUfWHhMpNMDe8E9Uvwd0+XwOEiyDRxvad3NX1 wILbDiIqYG0fKFSo603SHVPMLrhcZjbE/oP0LYtHH2YBnNSiWFi+KUHNWxOP/ppg7A4Z I7GMRzqIfduIMREYKyfNHlukJ6+xDM27PYoBksMeKsKpIfaftIiFDneaY+040R+eFuMv 8Pg3kvIWe4/L99Scpv9jTFKpflTymUQzz4fIzhwLdaNP4+IXajL8ItrNdje5mb8aKbYj voVZ56jbhLTFFFAr0Sj+Bz2zNjBn5y41UstNDlgNiZ9hp66xqJMTKL7F9mVaOe7DNGVw QHNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fmBSgM1RnRzXpCABmp4imdNRCidN3khdHwguCfXrtlk=; b=NWRj/n4DtOjMFKFIFA3/mXphQLv9DmIiVo+bpakUAt7r5XKTp58OqjIj3CB/7arO6h HxHNON4GI2PPcBlf8SMkpAdJv4mZipMpmG99/qbAR6r/1VuUzU8wMwkf45rWINRWd19L mhFXFIqxliAb4CMaAXvSutJ1ePEpO11kHMX29iVt40GaANGTyzWYnU70t7/5PNUe65fr ZXNzj09F2N7Tt7I3o/L64fPR2UDhIa52m1LKZb44JKGeMMvRU862fF+/1ZLkP7MerDKz boS3e4G+xooHk5vUot4/Nvt+pAuDEBYfzp4PlAca6mZvzUXW3sbg+JDiIqdG4Hk4sxb6 rF8w== X-Gm-Message-State: AIVw113e8U3RduyQqe8l/BUkLBjZY19gyut+yCTNc9/t7lU9OhZt633Q 5dVSLtmiY8CI6GjfpiLMhh+YmbhsqupKHP0= X-Received: by 10.31.163.201 with SMTP id m192mr15450401vke.13.1501685403248; Wed, 02 Aug 2017 07:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.9.231 with HTTP; Wed, 2 Aug 2017 07:49:22 -0700 (PDT) In-Reply-To: <17227969.9438@service.govdelivery.com> References: <17227969.9438@service.govdelivery.com> From: Warren Kumari Date: Wed, 2 Aug 2017 10:49:22 -0400 Message-ID: To: sidrops@ietf.org Content-Type: multipart/alternative; boundary="001a1142d6e20679b70555c6613f" Archived-At: Subject: [Sidrops] Fwd: Seeking Technology Collaborators: Secure Inter-Domain Routing X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:50:07 -0000 --001a1142d6e20679b70555c6613f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I figured others may be interested in this. This is similar to the note Doug M sent on Jul 20th, but with more detail..= . W ---------- Forwarded message ---------- From: National Cybersecurity Center of Excellence < nccoe@service.govdelivery.com> Date: Wed, Aug 2, 2017 at 9:13 AM Subject: Seeking Technology Collaborators: Secure Inter-Domain Routing To: warren@kumari.net Federal Register Notice now available NCCoE Seeks Technology Collaborators for Secure Inter-Domain Routing Projec= t Today, the National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) released a Fed= eral Register notice (FRN) for the Secure Inter-Domain Routing: Route Hijacks project. This notice invites technology vendors to participate in the collaborative project. This project will use commercially available and open source technologies to develop a cybersecurity reference design that can be implemented to increase security and functionality in internet routing. This project will demonstrate how the implementation of BGP Route Origin Validation (ROV), using Resource Public Key Infrastructure (RPKI), can mitigate malicious route hijacks and accidental misconfigurations in BGP. The FRN launches a collaborative effort between the NCCoE and technology companies to address cybersecurity challenges identified in the Secure Inter-Domain Routing: Route Hijacks project description. All interested organizations are encouraged to request a Letter of Interest (LOI) template. This template will include instructions on how to submit the LOI. Additional information on how to collaborate with the NCCoE can be found here . *If you are interested in providing products or technical expertise to develop a reference design for this project, please review the FRN for more information. * If you have any questions or would like to request a Letter of Interest, please don=E2=80=99t hesitate to contact the project team at sidr-nccoe@nis= t.gov. ------------------------------ [image: NIST] Questions? Contact Us STAY CONNECTED: SUBSCRIBER SERVICES: Manage Preferences | Unsubscribe | Help ------------------------------ If you have questions or problems with the subscription service, please contact subscriberhelp.govdelivery.com . Technical questions? Contact inquiries@nist.gov. (301) 975-NIST (6478). This service is provided to you at no charge by National Institute of Standards and Technology (NIST). 100 Bureau Drive, Stop 1070 =C2=B7 Gaithersburg, MD 20899 =C2=B7 301-975-6478 <(301)%20975-6478> [image: GovDelivery logo] --=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 --001a1142d6e20679b70555c6613f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I figured others may be interested in this.
This is similar to = the note Doug M sent on Jul 20th, but with more detail...

W
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">
<= br>
---------- Forwarded message ----------=
From: National Cybersecurity Center of Ex= cellence <nccoe@service.govdelivery.com>
Date: Wed, Aug 2, = 2017 at 9:13 AM
Subject: Seeking Technology Collaborators: Secure Inter-= Domain Routing
To: warren@kumari.ne= t


=20

Federal Register Notice now available

NCCoE Seeks Technology Collaborators for=C2=A0Secure Inter-Domain Rou= ting=C2=A0Project

Today, the=C2=A0National Cybersecurity Center of = Excellence (NCCoE) at the National Institute of Standards and Technolog= y (NIST) released a Federal Register notice=C2=A0(FRN)=C2=A0for the= =C2=A0Secure Inter-Domain Routing: Route Hijacks=C2=A0project. This not= ice invites technology vendors to participate=C2=A0in the collaborative pro= ject.

This project will use commercially available and=C2=A0open source=C2=A0t= echnologies to develop a cybersecurity reference design that can be impleme= nted to increase security and functionality in internet routing.=C2=A0This = project will demonstrate how the implementation of BGP Route Origin Validat= ion (ROV), using Resource Public Key Infrastructure (RPKI), can mitigate ma= licious route hijacks and accidental misconfigurations in BGP. The FRN=C2=A0launches a collaborative effort between the NCCoE and technology com= panies to address cybersecurity challenges identified in the=C2=A0Secure Inter-Domain Routing: Route Hijacks=C2= =A0project description.=C2=A0All interested organizations are enco= uraged to request a Letter of Interest (LOI)=C2=A0template. This template w= ill include instructions on how to submit the LOI. Additional information o= n how to=C2=A0collaborate with the NCCoE can be found here.

If you are interested in=C2=A0providing products or technical ex= pertise to develop a reference design for this project, please review=C2= =A0the=C2=A0FRN=C2=A0for more information.=C2=A0

If you have any questions or would like to request a Letter of Interest,= please don=E2=80=99t hesitate to contact the project team at sidr-nccoe@nist.gov.=C2=A0<= /p> =20

=C2=A0

=

Questions?=C2=A0Contact Us

STAY CONNECTED:=C2=A0<= /span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03D""=C2=A0

SUBSCRIBER SERVICES:
Manage Preferences =C2=A0|=C2=A0 Unsubscribe =C2=A0|=C2=A0 Help=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

If you have questions or problems with the subscription service, please = contact subscriberhelp.govdelivery.= com.
Technical questions? Contact inquiries@nist.gov. (301) 975-NIST (6478).

This service is provided to you at no charge by National Institute of St= andards and Technology (NIST).=C2=A0100 Bureau Drive, Stop 1070=C2=A0=C2=B7= Gaithersburg, MD 20899=C2=A0=C2=B7=C2=A0301-975-6478

 3D"GovDelivery
3D""



--
I don't think the execution is= relevant when it was obviously a bad idea in the first place.
This is l= ike putting rabid weasels in your pants, and later expressing regret at hav= ing chosen those particular rabid weasels and that pair of pants.
=C2=A0= =C2=A0---maf
--001a1142d6e20679b70555c6613f-- From nobody Fri Aug 11 02:56:32 2017 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 B6DD1132645 for ; Fri, 11 Aug 2017 02:56:26 -0700 (PDT) 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 QLx149xiegVx for ; Fri, 11 Aug 2017 02:56:24 -0700 (PDT) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 80C88132643 for ; Fri, 11 Aug 2017 02:56:24 -0700 (PDT) Received: from [2001:43f8:90:250:e9e0:e756:d93b:ac7d] (port=50951) by smtp.mu.afrinic.net with esmtpsa (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1dg6fx-000AMt-HM for sidrops@ietf.org; Fri, 11 Aug 2017 09:56:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Daniel Shaw In-Reply-To: X-Pgp-Fingerprint: F49E C21E C756 BAB4 111A A824 1054 DE1B 27FB F3D4 Date: Fri, 11 Aug 2017 13:56:17 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1679794B-98EB-48C0-89B9-6BDCAEDD8D06@afrinic.net> References: To: sidrops@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:56:27 -0000 On 19/07/2017, 12:59, Tim Bruijnzeels typed: >=20 > Dear WG, >=20 > As presented I want to propose a change to RFC7730 to move to HTTPS = URIs, rather than RSYNC. >=20 > The reasons why I want this change are: > - As a TA operator I feel more confident assuring the availability of = a TA certificate over HTTPS compared to RSYNC Just for the record, as another TA operator, plus one. I'd like to see this work go ahead. Thanks and regards, Daniel From nobody Mon Aug 14 13:35:51 2017 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 47D57132422; Mon, 14 Aug 2017 13:35:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274294924.10434.8513082703194961655@ietfa.amsl.com> Date: Mon, 14 Aug 2017 13:35:49 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-rollover-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:35:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Router Certificate Rollover Authors : Brian Weis Roque Gagliano Keyur Patel Filename : draft-ietf-sidrops-bgpsec-rollover-01.txt Pages : 10 Date : 2017-08-14 Abstract: Certificate Authorities (CAs) managing CA certificates and End-Entity (EE) certificates within the Resource Public Key Infrastructure (RPKI) will also manage BGPsec router certificates. But the rollover of CA and EE certificates BGPsec router certificates have additional considerations for Normal and emergency rollover processes. The rollover must be carefully managed in order to synchronize distribution of router public keys and BGPsec routers creating BGPsec Update messages verified with those router public keys. This document provides general recommendations for the rollover process, as well as describing reasons why the rollover of BGPsec router certificates might be necessary. When this rollover process is followed the rollover should be accomplished without routing information being lost. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bgpsec-rollover-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-bgpsec-rollover-01 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 Aug 14 14:05:29 2017 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 EA9FC132429 for ; Mon, 14 Aug 2017 14:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4BORgjEemu52 for ; Mon, 14 Aug 2017 14:05:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47DB132422 for ; Mon, 14 Aug 2017 14:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2528; q=dns/txt; s=iport; t=1502744725; x=1503954325; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=b2gnoN3YmfxZnaMUVb+VoD2c0EkLU+Hzxfxwv/XF2pc=; b=i2mETudhnbaoQ4CPTU3DmyJKrF+ZuJH/AIWOfsbl1piaOs5k/vuRBBsJ sTyajar1YjsZQi7i/oVa28jNk1PKigNdsgMkjULTlNeN4wo5GTNKrr6l+ d7+TF5rfdlA+2YKoLNVKR82k6IxBh+N7ksDBPk8YNVA0Umu7R2pTdz32m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAAA1EJJZ/4gNJK1aAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNaZIEUB44KkBGBbpYYDoIELoUZhHs/GAECAQEBAQEBAWsdC4UZAQQ?= =?us-ascii?q?BOj0HCwIBPhAyJQIEE4onCBCvJotsAQEBAQEBAQEBAQEBAQEBAQEBAQEegyiCA?= =?us-ascii?q?oMvK4J8gyaBGgESAUAmgnyCMQWRC48mAodRg1OJFoIPWYUEimmJZIwwAR84fwt?= =?us-ascii?q?3FR88AYcHdgGHYoEjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="scan'208";a="471556564" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2017 21:05:24 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7EL5OSL029426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Aug 2017 21:05:24 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Aug 2017 17:05:23 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Mon, 14 Aug 2017 17:05:23 -0400 From: "Brian Weis (bew)" To: "sidrops@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sidrops-bgpsec-rollover-01.txt Thread-Index: AQHTFTztw+OIpRuS2kK1eAgSOntpBg== Date: Mon, 14 Aug 2017 21:05:23 +0000 Message-ID: <605BE4D9-0A76-40D4-BA4B-AA4FFEA5B2B8@cisco.com> References: <150274294941.10434.10745925044193104854.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.173.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <8742A446F0344342B7A1637901B0C267@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Sidrops] New Version Notification for draft-ietf-sidrops-bgpsec-rollover-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 14 Aug 2017 21:05:28 -0000 This version of the BGPsec rollover I-D addresses many helpful comments pro= vided by Sriram. The majority of the wording changes are adjustments to the= terminology and addition of clarification text. Major changes include a re= -written Abstract, re-written Security Considerations, and referencing draf= t-sriram-replay-protection-design-discussion-08 as a source of other replay= protection methods for BGPsec. I believe this addresses all of the WGLC comments on the document. Thanks, Brian > A new version of I-D, draft-ietf-sidrops-bgpsec-rollover-01.txt > has been successfully submitted by Brian Weis and posted to the > IETF repository. >=20 > Name: draft-ietf-sidrops-bgpsec-rollover > Revision: 01 > Title: BGPsec Router Certificate Rollover > Document date: 2017-08-14 > Group: sidrops > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-ietf-sidrops-b= gpsec-rollover-01.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpse= c-rollover/ > Htmlized: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rol= lover-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-= bgpsec-rollover-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-bg= psec-rollover-01 >=20 > Abstract: > Certificate Authorities (CAs) managing CA certificates and End-Entity > (EE) certificates within the Resource Public Key Infrastructure > (RPKI) will also manage BGPsec router certificates. But the rollover > of CA and EE certificates BGPsec router certificates have additional > considerations for Normal and emergency rollover processes. The > rollover must be carefully managed in order to synchronize > distribution of router public keys and BGPsec routers creating BGPsec > Update messages verified with those router public keys. This > document provides general recommendations for the rollover process, > as well as describing reasons why the rollover of BGPsec router > certificates might be necessary. When this rollover process is > followed the rollover should be accomplished without routing > information being lost. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Wed Aug 16 07:10:53 2017 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 F36501252BA for ; Wed, 16 Aug 2017 07:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F0LXEchMz509 for ; Wed, 16 Aug 2017 07:10:51 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 786001241FC for ; Wed, 16 Aug 2017 07:10:51 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dhz21-000C8z-9u for sidrops@ietf.org; Wed, 16 Aug 2017 16:10:50 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-102.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dhz21-0005vI-49; Wed, 16 Aug 2017 16:10:49 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 16:10:48 +0200 Message-Id: <0439F08A-FA21-42C5-A22A-3208F32F712D@ripe.net> To: sidrops@ietf.org X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e9b2fae579c131bbf3bb93aef3dcb336 Archived-At: Subject: [Sidrops] Signed TAL X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 14:10:53 -0000 Dear working group, Following the discussion at the microphone at IETF99, we have uploaded = an updated version of the signed TAL document: https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidrops-signed-tal/ Two issues were brought up: 1) magic numbers used for staging periods We removed the time after which a Signed TAL should be removed - opting = instead for a model where a TA can publish what it believes should be = considered its current TAL at all times. RPs that have already learned = this TAL can just ignore it.=20 We kept 24 hour staging period in key rolls (section 6.2). I don=E2=80=99t= think we strictly need it to be honest, but it is in-line with how = things are done in CA key rolls (RFC6489). We also kept a 24 hour period when withdrawing a publication point. = Although there is no explicit guarantee about how frequently RPs = re-sync, most RPs do use a much high frequency than this. The 24 hour = value is in-line with key rolls, and should be more than enough time. 2) Lessons from RFC5011 (Automated Updates of DNS Security (DNSSEC) = Trust Anchors) As I read the mechanisms described here are not applicable to RPKI = because we do not have explicit TTLs defined, and we do not have the = concept of Trust Anchor Sets. Therefore we still propose a model based = on the existing TAL format that we believe is simpler. We would now like to ask for working group adoption of this document. Kind regards Tim=