From nobody Mon Apr 4 04:14:40 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8897312D1CB for ; Mon, 4 Apr 2016 04:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiNNMEOKHp57 for ; Mon, 4 Apr 2016 04:14:38 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433C312D1BE for ; Mon, 4 Apr 2016 04:14:38 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A2A0328B0043 for ; Mon, 4 Apr 2016 07:14:37 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0E8B81F801E; Mon, 4 Apr 2016 07:14:36 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_EE1EF7A8-ECA3-4D6B-8B30-D8ED5D72456C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 4 Apr 2016 07:14:35 -0400 Message-Id: <1B071660-618C-49BF-98AF-BC62F7D5B231@tislabs.com> To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] agenda change X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:14:39 -0000 --Apple-Mail=_EE1EF7A8-ECA3-4D6B-8B30-D8ED5D72456C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A new agenda has been updated. We will have a discussion today of the new version of = draft-ietf-sidr-rpki-validation-reconsidered-03. Thomas King graciously agreed to have his presentation moved to = Wednesday. =97Sandy, speaking as one of the co-chairs --Apple-Mail=_EE1EF7A8-ECA3-4D6B-8B30-D8ED5D72456C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXAkycAAoJEHplpQeet0IZ1Q4P+wVT5e0W5YLEEBROy5qRCieA txMSm00g6evwKTVYPBtjymsT08SgT2T/DX1Z9SDmwaQwcsxGLcJ+gtVIZNg5ewz2 2XFZyQSxmzPO/oUkUPvSb0lYgyTzITiDlrxK6h9hiewX+bjLZZ/RxIC+0j+3yfDH IkB+PeWSbUdBDYxK1fiP8RH1ijCDqDsYM1qzWQqFOSV57v+DbZ/DcuoX+Iv+bfDo Vub1HuO11IFTHZS0umLFjnOg4YqVAgawMYUx9fcUEQbHoIlWZmaMUiwC0k5/+QJA v2H3+NshfZrHD7FltrvtwCEML/uKNbrxJ8dkwTRT5GmgtCb+VFXdXtUIyrWi4hFp 9dHvMdq/RgJPCpsMMqdp3L7yCyciHKku/pJLX/W6//s+Ox8hznkL+CXiaDkCVCwV TuY+jGiXtDxk1+FjPH7v8wGckryaCLeMGA6F7lh82qkqSxVoecU6y3AYnsquHL3X w27E0eTKmfi1KwnDccxNUgr9W8scDNWoRuTL++ZTSfVWXy4/yDosljP6Yf0SCh38 kn4369LuJ4P8xQoSdPB4eapobdYRNX5APmNxrkBzhPHrTIrJdY14c1MX//v5fXZc FGNP3gTUrmF21e+TdcI/poezETxH/epaMkwBaTKeq6biDrnTJzwyTzQlmb57tqIE w/oUg/L968Sg657arHxf =aYcx -----END PGP SIGNATURE----- --Apple-Mail=_EE1EF7A8-ECA3-4D6B-8B30-D8ED5D72456C-- From nobody Mon Apr 4 04:42:03 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B2212D524 for ; Mon, 4 Apr 2016 04:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGPMgRKaOj4f for ; Mon, 4 Apr 2016 04:42:00 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DA112D567 for ; Mon, 4 Apr 2016 04:41:51 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0C35028B0041 for ; Mon, 4 Apr 2016 07:41:51 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 872A51F8035; Mon, 4 Apr 2016 07:41:50 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_0EDC7BC3-41FF-4BC0-833E-2A355417B32E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 4 Apr 2016 07:39:04 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] need jabber scribe and minutes takers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:42:02 -0000 --Apple-Mail=_0EDC7BC3-41FF-4BC0-833E-2A355417B32E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We need jabber scribes and minutes takers for the Monday and Wednesday = sessions. Please volunteer. If we don=92t have someone who has agreed we can=92t = continue with the meeting. =97Sandy, speaking as one of the co-chairs --Apple-Mail=_0EDC7BC3-41FF-4BC0-833E-2A355417B32E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXAlJlAAoJEHplpQeet0IZY70P/1TcYqiEwGmqQru0B8zZA4W4 zTbMV4grm1+kwqVG3ShEJcJaxUDHKgq8YUO45o6fRtyIpI0UC+FPXewnwqllDKki XScuAdPX3AuICc23kpZG2ZkYibW1FGIygHV9l/QuqKkRp7wYBJMBLmuYv5fOoJzL 4klB0qrL6qFaVWs07u9sZ34cAwXlMuTm1Yp0wAH/O3OEGMhCzMuTHInV58RTyX4L f3GHQ6qFzkE7G2vZ3TGmcCkEIol9887xlTGvLWn6aNeIzlWmdy00GNK6O3glKSed gxgWJKWxVLgelNMjacx3kFieAMufJoNeHRceGi8xwHyinX/bdFh4EbkdptuxgUUG PbwIQsI4U/wvT2dsuoVQXxl2Pih/8GtXA13udtaFm0Zpq4vmolLzo2aTi4/KGqvA 63h2TOcDv2brMI9xQogf/xR+5A8fXArFTpej7S7T0ge5yQTt34iOzTu9yi6KSx4b zCCvqr7b+5PNcIugcSMxeaXjHF5dGt3fcEyN8Tt4JrVfn2EyjFpGv95VrMyXkU8V CPtllgSfTzU9LSXhKmHavwDGbm4OPTjiHKdRY69N7UwWk57bCBImuHDT/OIzH56B dwjZiuBPAWR6lzHbTroNc5AX/7U2wHXJ8BfTk56LeRxDCLhEknI3scKNm6Pvx9Cw K/IH14tvejR/zzO4mm/y =TK8z -----END PGP SIGNATURE----- --Apple-Mail=_0EDC7BC3-41FF-4BC0-833E-2A355417B32E-- From nobody Mon Apr 4 09:49:35 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3127B12D7B2 for ; Mon, 4 Apr 2016 09:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJROw3dzp28d for ; Mon, 4 Apr 2016 09:49:24 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E00D12D79E for ; Mon, 4 Apr 2016 09:49:24 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 82B2128B003D for ; Mon, 4 Apr 2016 12:49:23 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id ED70F1F801E; Mon, 4 Apr 2016 12:49:12 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_3F1A987B-3AE6-461B-B08C-447CDCBBDF16"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 4 Apr 2016 12:48:55 -0400 Message-Id: <1C7AAE86-D1EF-4516-9D6E-3638C5CBA069@tislabs.com> To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] discussions on Wednesday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:49:27 -0000 --Apple-Mail=_3F1A987B-3AE6-461B-B08C-447CDCBBDF16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There are two topics that at the AD and chairs would like to discuss on = Wednesday. The first is the future of sidr (new charter, new area, new group, etc = etc) The second is the intended status of the BGPsec protocol. =97Sandy --Apple-Mail=_3F1A987B-3AE6-461B-B08C-447CDCBBDF16 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXApsAAAoJEHplpQeet0IZD28QAKiicF8ILaLjUQx2ltPxLwh9 mV3+91xsyOAcXfNpf2m0jKKki+BD9cV44yOFmFXUlgh+1qzbh2GlQTqyPOtVs7lJ k/ncihGGGOg6eFTA+XWWUg8so5rssGvi+Jang3+fiyPUQyPJqdx6Ai9X5kGFIe08 eIPLdWslxZadHe3mlIxmdLX6y8OwCRtY8Pic7zuyHNCeeB8bSwkPulIRQKi1Wi6l jT6VybdF9DtdGyQhHnvpm6TDjBS0e95iIBquXRarMxfb33k6N3Wxn7UNg1vULm4m eVHINbETS2Ts20roSCnfCNNxk6WNXwURTjA4ZhsB/z0t+pTJNYCJ2zFv8SrDuM/J kRzouGsn5GVBiga3QEy/n7HHp6YQZz/kLZLgQwYiD2PHqfXPQlqk6ZkEWLyK82eN 3ZdArxh8LIGpWMJFnFtIosnQvo0fAN5Guz6lirPBl9+tv8XMe3rp3LqHeuVQeBXn u0K6FX4hIR9FnS6qm6qDwrt/g01I+8XRGvHti1vU7yy9tCnZfLYG8ychfZHkAa5U CGs30l+p2kPhSI3qrFjcU2H4pxd2QBfavANg092A669QHyw9XfDQVDLrVBsvIWh5 DdLo88bxkARO3AcKyNL/Fon9QmtoARLRyCEu60+6QhJhtSIALegJbKecFgiw/b8b Iv6Az4M4j1xarAb5DIqH =SRTE -----END PGP SIGNATURE----- --Apple-Mail=_3F1A987B-3AE6-461B-B08C-447CDCBBDF16-- From nobody Mon Apr 4 15:51:40 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170E312D8E6 for ; Mon, 4 Apr 2016 15:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcS47GdMt7CQ for ; Mon, 4 Apr 2016 15:51:37 -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 AA5A712D8EA for ; Mon, 4 Apr 2016 15:51:37 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1anDLK-000BMJ-56 for sidr@ietf.org; Tue, 05 Apr 2016 00:51:35 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-175.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1anDLJ-0001zI-N7; Tue, 05 Apr 2016 00:51:33 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2016 19:51:29 -0300 To: sidr Message-Id: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197a303304442343a2e96fc6b73b2918dd Archived-At: Subject: [sidr] The question about https certificates and frequency of mft/crl re-issuance X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:51:39 -0000 Hi all, I promised to take this to list. So, as presented today, the volume of updates of MFTs and CRLs in the = RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad = signal -to-noise ratio that causes waste of cycles and bandwidth. =3D Why this noisy? MITM.. We get this, because we use a 'next update time' of 24 hours, but we = actually republish every 8 hours to make sure that we can fix issues = before things go stale. In my understanding we need this because of = man-in-the-middle attacks involving replay or withhold. And rsync is = vulnerable to this (clear text, and no authentication of server). If an = RP is being fed old data, they would notice that something is wrong = within 24 hours. A longer period seems scary.. If this understanding is = wrong I would love to be educated. =3D Solved by https? But assuming this does make sense, I wondered whether RRDP with httpS = offers a way out of this. With RRDP a CA signs a certificate with an = https URL like: https//my.repository.example.org/notification.xml. We = can trust this because it's on a signed certificate. Now, if we can also = exclude mitm, because we can trust the httpS certificate, this would = allow for a much longer period 'next update time'. And in the meantime = the RP would still learn about updates before this, because the = notification.xml is checked regularly and would include any changes = ahead of this. =3D If so, how to handle https TAs? This is a question for RPs. But trusting all https certificates or all = default TAs configured on a system is potentially problematic if the CA = assumes that RPs check against mitm. Some of the many TAs preconfigured = in browsers have been shown to have issues here. Then again, RP software could be pre-configured with a smaller set of = TAs or even server certificates for know repositories and offer an = interface to operators to change this set. Or RPs could accept new = certificates for repositories, but require operators to confirm changes. = The number of expected repositories isn't great. But there clearly are = scaling issues here. As I stated on the mic. I don't claim to have the answer. But I think = it's really worth thinking about ways to reduce the signal-to-noise = ratio mentioned. Tim From nobody Tue Apr 5 03:35:11 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65E12D71C for ; Tue, 5 Apr 2016 03:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VkiieHjYFCbj for ; Tue, 5 Apr 2016 03:35:07 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 45A7312D7D3 for ; Tue, 5 Apr 2016 03:35:07 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id g185so13624200ioa.2 for ; Tue, 05 Apr 2016 03:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DYbRCClKiyXNdKPS6XvbkPeyIrr3E21Z7JYWjiKHd1g=; b=gAU2oLILNRY9jwj3dw3JN4h4dr45qY0YzqGBGN0XR6VpUQVVtFsZi8z6/FPs0iu5IB zK+itg5hQnCisvx9hQm+5tNCe3m7qp102KOKkmfsAgzKs6a5ljdmotHpEMZk/InaObRf MSCLw4FjA7GxrB8M3+729pEw2VADUOHTdOf5xz1rMzC71LKHQNUI25okNK+Jau6NT4cj 4oZ3KToqDokEXif7wFpHa3YiYdj2Xx9/lmuLVvnq//n2otNZC3UBRT44ziYTzsQOlC5q cBnNjQP2uSqK9h7QhWGUYfuHa1LHEWhCwGHYIK1c1tRIGxHD+FWOY7L9gGPfRGU+HX3x Bz+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DYbRCClKiyXNdKPS6XvbkPeyIrr3E21Z7JYWjiKHd1g=; b=BW3MQkEm2apkdAEuMbRqrqb/jn6DLCvxii+NR0PYUPqgEkBdGdFhgCwUgyB8aFEdUR a1q4how/VOCyz4e1gmjzgaLal7YyUH6qgoSrafHYcRsppTHfaNavGJI5shw/9oF1woRq Dd8sqHMfziyuOCk5jth9kb1z2V2CBSePRD3Txoppx2o4ML4sQzv2IWqqcoj2gw5iUQ6j RL3f5lVOeeMvjuBDI939QFIpw/bxnkvovjkUn8I7cJAbdaDZ0XUmPnh5vax0pDfv689U kWwOqpPTXli1oasjspciRGFVc0w3L2E414+KNeNQq2SDQnv7petGHcl5WCzM5kucL8hz a9ng== X-Gm-Message-State: AD7BkJJ5PoqQRK3yux+tfjNFt3hu1qXCsTVvtOzGi1e8Gef1iqpegopjNGU2jw314g3Yus0SavXfQ1GpN+WaUw== X-Received: by 10.107.185.133 with SMTP id j127mr20457903iof.72.1459852506599; Tue, 05 Apr 2016 03:35:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arturo Servin Date: Tue, 05 Apr 2016 10:34:57 +0000 Message-ID: To: "Xialiang (Frank)" , "sidr@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c070a1c14c2ac052fba6675 Archived-At: Subject: Re: [sidr] adoption call for draft-kent-sidr-adverse-actions-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 10:35:09 -0000 --94eb2c070a1c14c2ac052fba6675 Content-Type: text/plain; charset=UTF-8 Support, and agree on Tim and Randy's comments. .as On Thu, 31 Mar 2016 at 06:59 Xialiang (Frank) wrote: > Hi > > I have read this draft and support the adoption of it. > > > > B.R. > > Frank > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --94eb2c070a1c14c2ac052fba6675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support, and agree on Tim and Randy's comment= s.

.as

<= div dir=3D"ltr">On Thu, 31 Mar 2016 at 06:59 Xialiang (Frank) <frank.xialiang@huawei.com> wro= te:

Hi

I have read this draft and supp= ort the adoption of it.

=C2=A0

B.R.

Frank

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--94eb2c070a1c14c2ac052fba6675-- From nobody Tue Apr 5 11:01:45 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7990312D764 for ; Tue, 5 Apr 2016 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhRybdn_BrcP for ; Tue, 5 Apr 2016 11:01:41 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [IPv6:2a02:c50:0:1e::4:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5146712D7E4 for ; Tue, 5 Apr 2016 11:01:36 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,444,1454972400"; d="p7s'?scan'208"; a="3257916" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw012.de-cix.net with ESMTP; 05 Apr 2016 20:01:34 +0200 Received: from MS-EXCHANGE.for-the-inter.net (unknown [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 590A4B009D; Tue, 5 Apr 2016 20:01:34 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 5 Apr 2016 20:01:34 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Tue, 5 Apr 2016 20:01:34 +0200 From: Thomas King To: "Sriram, Kotikalapudi (Fed)" Thread-Topic: New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt Thread-Index: AQHRNnoeBTQtz7wo5UuIHjaJS1blSp9v6SzwgAxStwA= Date: Tue, 5 Apr 2016 18:01:33 +0000 Message-ID: <8865D28E-559D-42B5-AB5D-19E9D036681C@de-cix.net> References: <20151214141704.6060.4078.idtracker@ietfa.amsl.com> <91A4DE37-13EF-4E45-9D7D-49C1D271D6A9@de-cix.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.140.155] Content-Type: multipart/signed; boundary="Apple-Mail=_D0FE2587-65A0-40A1-BD1F-806C72969A1D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:01:43 -0000 --Apple-Mail=_D0FE2587-65A0-40A1-BD1F-806C72969A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sriram, thanks for your feedback. I comment inline. > On 28 Mar 2016, at 22:14, Sriram, Kotikalapudi (Fed) = wrote: >=20 > I read the draft. A few comments: >=20 > 1. RPKI validation refers to checking cryptographic integrity of the = RPKI objects such as certs, ROAs, etc. > What you intend to signal from RS to peers is prefix-origin validation = results (RFC 6811). > s/RPKI validation results/ prefix-origin validation results/g Fixed. >=20 > 2. "Route-servers providing RPKI-based route > origin validation set the validation state according to the RPKI > validation result (see = [I-D.ietf-sidr-rpki-validation-reconsidered])." (in Section 2) >=20 > The reference cited here is incorrect. It should be RFC 6811. > RFC 6811 defines the prefix-origin validation states and also provides = the validation algorithm. Fixed. > 3. How do you signal that the RS did not perform validation on an = update (for whatever reason). > Is that implicitly conveyed when the "Prefix Origin Validation State = Extended Community" > is absent in the update forwarded to peers? May be it needs to be said = in the draft. > For instance, 'Not Found' should not be used as default value in the = extended community. > 'Did not perform validation' should not be equated to 'Not Found=E2=80=99= . I see your point. I do not want to add another state as = ietf-sidr-origin-validation-signaling defines only the ones used in this = draft. I would like to be as close as possible to = ietf-sidr-origin-validation-signaling as this draft just adds another = use-case (route servers) to the concept. If validation could not be performed by the route server no community = should be set. The receiving peer should treat the update as if no = prefix origin validation information was provided by the route server = for this prefix ever. If this is okay with you I will add section = covering this topic in the Recommendation section. Best regards, Thomas --Apple-Mail=_D0FE2587-65A0-40A1-BD1F-806C72969A1D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJgTCCBFkw ggNBoAMCAQICCwQAAAAAATGJxjMGMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNp Z24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWdu MB4XDTExMDgwMjEwMDAwMFoXDTE5MDgwMjEwMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoT EEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0Eg LSBTSEEyNTYgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKYBOgY+TD0lJ71l 7FcN0/Nzj61Z4eB/NxJMsSxhevgtUUcwxyWYkoHDl+FoQMXe8JSYraOIN7UpZvvDa9fVVpouxlnk 1upfRTHJRpU636SlHTEE5ZnXTYWQ3pTL51oEoPL4fL4OIHHO8Xe0H7X/9nw+N8tNxCCiGKRBMCcH HXuJLeW3pFUISGaVwfc2mye8mjIw+bjIJ6gtjK66WaUW6fWY323qkkS8W9uzdCXKVpGPkZUhsmqW fGlg2msfbx3O8to8LaCk0RqlVvV+g7ZrY7xBwdWGfZKCRd5R1kt2QBYOBtZfRBV7dfPMsjI4XcQU uKyTYpccj7VTvLdaf+B+TZkCAwEAAaOCASkwggElMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBQ/bFdEnlefff1oOcu58RrkuXZQODBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LXIzLmNybDA+ BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9y b290cjMwHwYDVR0jBBgwFoAUj/BLf6guRSSuTVD6Y5qL3uLdG7wwDQYJKoZIhvcNAQELBQADggEB AGUF26aHSpzgt7hjcu8xUQsY2pcbwzMAS6Eyx+m80XfposXHisFP0qnPEnnbF+GH3/cw2DOFLIXk PBXOeFRSx25VtdtVJPZGQcNeu2Mb2zcDBR950sXb8A/5fd9ZXzGKTf751bAFn4OX1BAYZlcSSILR MiiHpVMQ7rhfC7NChIQoRL7su+oxiIOMHhYkCheGGhnf5kmPDY8f3INUjPlftUpkQ6eBV/yZ0BKp 6w04eK2ha3dSd/GS/f+yoVi2zQGmw4qh8rd9ijsJgjr5qOCK84jRS8Vp7JfKF+RvDk38dzsXdBHu vie5mMmw9DgtzAZ2z93EovkFeQYnWMi6th+PtG0wggUgMIIECKADAgECAhEA2O44+rO7W3RMNf2n PhVNvTANBgkqhkiG9w0BAQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu di1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcy MB4XDTE0MTIxNzE0MDMwNVoXDTE3MTIxNzE0MDMwNVowgaExCzAJBgNVBAYTAkRFMQwwCgYDVQQI EwNOUlcxEDAOBgNVBAcTB0NvbG9nbmUxHzAdBgNVBAoTFkRFLUNJWCBNYW5hZ2VtZW50IEdtYkgx FDASBgNVBAsTC0VuZ2luZWVyaW5nMRQwEgYDVQQDEwtUaG9tYXMgS2luZzElMCMGCSqGSIb3DQEJ ARYWdGhvbWFzLmtpbmdAZGUtY2l4Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AOP1el+NQvS54TU/sO77bxd2pGMFw15OZIPm4ggIanvFGMo/UqUEpq4eOSQp7qhyYr4ROr1bbTGk PNEnsXn1Ogoa0/xt2mQhpWlO4IykBN9eo09ZSuiQEWGHnKWNUevDRQpbkugZuvla8MVCWhIuDyc3 JlzA8SaCVoojaKltl5qqLYf4yln61tvu44ByaKMniTzHrUvSPeEntr9ZkN477MCL3h4tp38vyvGv zEJTPv2x/i5vS2kFxNl7oSdd3TcBsevz5ui3XxXy1isO05KrVD6JTkXbZejsPRPEa6VsgeR6Q0FP 833K/+7/EiYOtHfwiIAydO9wK6/u5mUX6n9MGJsCAwEAAaOCAZQwggGQMA4GA1UdDwEB/wQEAwIF oDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xv YmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wIQYDVR0RBBowGIEWdGhvbWFzLmtpbmdAZGUtY2l4Lm5l dDAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBHBgNVHR8EQDA+MDyg OqA4hjZodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMnNoYTJnMi5j cmwwWQYIKwYBBQUHAQEETTBLMEkGCCsGAQUFBzAChj1odHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24u Y29tL2NhY2VydC9nc3BlcnNvbmFsc2lnbjJzaGEyZzIuY3J0MB0GA1UdDgQWBBRWuQrVK+3zTtZn 1ORSIsFcQJX+2jAfBgNVHSMEGDAWgBQ/bFdEnlefff1oOcu58RrkuXZQODANBgkqhkiG9w0BAQsF AAOCAQEAoMDHFHReZqkQtBmjceWw09VArN6a8h4GXRRJ+Tmv3ia2u66bgBRBtmE1vEeIPoS4OtoJ SbAG0WUIVucWN9HgTJS7Cq1BvjHOaW5H0qxIViY67Re0coWnWhFdlQlCcZHTHDhgejZUhOdON3wL xzAkzctT/ACp3SYBBGyqGo+XEPITbeqN33kf29qAjd+4kNuyLrF71I60wPwnNOCZxgKqxl0mLlcY U1XSz49rqk1Nxko/OnrEY5w6brxIBABdOWe4b/He596QBdum0xq9CdHIRabYRzsKvChrT+TVkEI9 pRRl2zsoNg+hJKWTGgLZHpnnq/3Ktc0z3xUiJtUvyz67nDGCAwQwggMAAgEBMHIwXTELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVy c29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wCQYFKw4DAhoF AKCCAWcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDA1MTgw MTMzWjAjBgkqhkiG9w0BCQQxFgQUr6u/XDb9leB/6a2pCl+vZzdlXwswgYEGCSsGAQQBgjcQBDF0 MHIwXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4V Tb0wgYMGCyqGSIb3DQEJEAILMXSgcjBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAt IEcyAhEA2O44+rO7W3RMNf2nPhVNvTANBgkqhkiG9w0BAQEFAASCAQBq6BMVUOkdJNm9hOwW+chK uUCf2oP/TtE+hmv3jxZGCd1BFmdoNRkmfaUEBbhxLyKN0xPcfPbyK6R733Bh+493+mSaKY7ScW0f SBNmA68Gcdlt709fyAMFkDLenTJ3KciobxhYsL0xLCmetR8ssjxg3vNVeS1jgHD69jI6OiC8u7RP cXbZqWG63UaIDqAwEUehaBsP6UowqeMj0CtvEu9QrIC1T9BvF2iJP8CkfNPcsaUARCK1ZXJ8rRPZ 3n2KhwJsPl5kfAXXd5KZNrvNRz907g42Im6M6rOvEK5rx0/iVy8t7jFBEH9+PhL5R8gDJsTTXyDO wXqU9oas8EsA5oMDAAAAAAAA --Apple-Mail=_D0FE2587-65A0-40A1-BD1F-806C72969A1D-- From nobody Tue Apr 5 15:20:36 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7612DA45 for ; Tue, 5 Apr 2016 15:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0olzm_ljpHGh for ; Tue, 5 Apr 2016 15:20:33 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2E912D9F4 for ; Tue, 5 Apr 2016 15:20:31 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B8B0F28B0041 for ; Tue, 5 Apr 2016 18:20:30 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 44D581F801E; Tue, 5 Apr 2016 18:20:28 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_05B849A3-D7DA-4710-AA6C-8F60F4FF9C76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 5 Apr 2016 18:18:34 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] two new agenda items for Wednesday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:20:35 -0000 --Apple-Mail=_05B849A3-D7DA-4710-AA6C-8F60F4FF9C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A new agenda for Wednesday is uploaded. Two new topics have been added: c) RPKI Deployment Considerations: Problem Analysis = 1450-1505 and Alternative Solutions draft-lee-sidr-rpki-deployment-01 https://tools.ietf.org/html/draft-lee-sidr-rpki-deployment-01 Presenter: Yu Fu d) Wither Adverse Actions? = 1505-1515 =97Sandy, speaking as one of the co-chairs --Apple-Mail=_05B849A3-D7DA-4710-AA6C-8F60F4FF9C76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBDm6AAoJEHplpQeet0IZLjEP/2ZM+weiVgPQ2UsHFi0TBScj zNvsWH/jLwqUIt5ZcfSIXfsv7FV67WwnkuJztHNxyclDk1qkwpLTSVfm9fCk+0ZD 9bcAyLe+iO41Nhte99q7F7V/1BrsJnD5+7riQdlk8wkoSv8KAKIiEobR51uqgh3N wfJiV+oAcSfptEYmXOAf/rqCIcWcGEAlq14UZb0uhOdReB3MLTyMqH0y3zy8cwhL iIK1k8zd70SxWMmS1N7y0JJmzNOEOk7zNInvhFUb51Vp+VH/QgDqsJX+W3RdKMBs oXJrJJrLpVDam0XECbLCYuBZhKrTx6axM9wo6XSCo9KclPyRuhgoK5PJ5Vo+SrVV DtjQey7qxTpapb7cyTafO/RMf8Rx3owaCYrxAZbnpZ362g2QqEj4FGby8T6GezEK HdAg8isZCeGo0nw3VauVrJkuWi4/eUpt310WBIj9aLLxBYM1KHqzK+Ib1BDszHQQ FdWpq3mp4hmuPqVbMOLQzDTkfyvckQwtT+l+VH4EXF9b/s/wC+BV8Z4RF73ubT3K FD/+cNB//p2qgnTiF5H1Qrea3x6jT3zQ7dDq3I+byzGmo5xyeuk2k36lS2IReWBj +oKLRYUuhi8si26zx4D0rSMU3IiG1UEQ32bbWdB8kO4vwzeWBiNtyz3l2X74feZC K4uuVxnhjoxaUnefjMb4 =5E2F -----END PGP SIGNATURE----- --Apple-Mail=_05B849A3-D7DA-4710-AA6C-8F60F4FF9C76-- From nobody Wed Apr 6 04:00:00 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E41512D197 for ; Wed, 6 Apr 2016 03:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHN41CAssi_J for ; Wed, 6 Apr 2016 03:59:57 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF23912D560 for ; Wed, 6 Apr 2016 03:59:56 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 398DA28B003D for ; Wed, 6 Apr 2016 06:59:56 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 970D81F801E; Wed, 6 Apr 2016 06:59:55 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_3E2A9E48-CB98-40A3-865E-8D7A57F8B0AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 6 Apr 2016 06:59:54 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] remote participants today - use Meetecho agenda page's link, do not use tools agenda page's link!! X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:59:59 -0000 --Apple-Mail=_3E2A9E48-CB98-40A3-865E-8D7A57F8B0AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It has been reported that the tools agenda page link to the Meetecho = feed is incorrect for a wg's second session. Like sidr=92s second = session this afternoon. For today=92s sidr session: The link is http://www.meetecho.com/ietf95/sidr_II on the Meetecho = agenda page [http://ietf95.conf.meetecho.com] The link is http://www.meetecho.com/ietf95/sidr on the tools agenda = page [https://tools.ietf.org/agenda/95/#WEDNESDAY] Use the Meetecho agenda page=92s link. The tools page link is pointing = to Monday=92s session and will report that you are =93too late=94. Seems the tools agenda is not handling the =93_II" roman numeral part. Of course, the tools team is soooo good, this may all be fixed by the = session time this afternoon. =97Sandy --Apple-Mail=_3E2A9E48-CB98-40A3-865E-8D7A57F8B0AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBOwqAAoJEHplpQeet0IZ3MIP/jkebeQ3qrZNOZHSjnZ8K9JG 0DfZZspeKWvLHXGOSfrSwW9wPLa+cj9sSwMQ1r4z/4qtjY2+AfbFretTewqx/Zol pQoZNYwoVlDv9Pfx4cfCwrHEJzkPtISg3xso25Fqvk8dWmLg4XnD4cV0FarzveOP XqH3Rb8imyMKNkbDiWrBPTxwDt9qPgog7DzpbqT0Q/7Citu9jEB10DMfjzgwp573 y2IIXluMGFFyKogc8CnaqFYyBpMlYY3aSZHY88zkGFNUY3KpbZTD+idqBpWRPgo9 SaKoOa+OrwMCUMSmUVtR6AMg+uSOEsQl0eL47mrLwi/79XYJw0ZxIJmE8TD1hyl9 zcOceIw7sttMOpPaQYNN4P3W7dxt7hMys8BQsPRirhcsI0QMutjW7pfdobLJ9sm4 X4kdvWc7BcB8QdgBDeRFLJMuGz4zwKmEW6wlJ/t8y4XNVgkWw2ijzT/llceH6pYg 2zlMQAlprmG0YjYP+88kMVfsWXrEieEYJAD+mEpVbC9hBTaGX7WBl6yxpZdZyUdh 4lrMvZXd7gGIUJl67LRJ4yTSwfxintFbzK0SE/oDGgld4zPpU+ZX+1R/J8f2lMc9 raPJ6I0457ThGIelZ858m//6bgOgWjaEbZuIX0fCBnaeSR+OHj/jii3IEZ/KgnfH rGugp5nGhMIu2TeGBty3 =yVrD -----END PGP SIGNATURE----- --Apple-Mail=_3E2A9E48-CB98-40A3-865E-8D7A57F8B0AF-- From nobody Wed Apr 6 05:18:13 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A54412D8BF for ; Wed, 6 Apr 2016 05:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TsOcDc7MN09 for ; Wed, 6 Apr 2016 05:18:10 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEF912D0A2 for ; Wed, 6 Apr 2016 05:18:09 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 44E7728B003D for ; Wed, 6 Apr 2016 08:18:09 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BC5271F801E; Wed, 6 Apr 2016 08:18:08 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DC92A55E-C892-423C-A9BF-844A27F96AF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <769D58E2-90FF-4F93-ACDB-3D1F8C0B2294@tislabs.com> Date: Wed, 6 Apr 2016 08:15:17 -0400 Message-Id: References: <769D58E2-90FF-4F93-ACDB-3D1F8C0B2294@tislabs.com> To: sidr X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] wglc for draft-ietf-sidr-rfc6485bis-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:18:11 -0000 --Apple-Mail=_DC92A55E-C892-423C-A9BF-844A27F96AF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The wglc has ended. There were no disagreements with publication and = there=92s been no wg dispute over the changes needed. The consensus of the wg is judged to support publication. The chairs = will be requesting publication. =97Sandy, speaking as one of the co-chairs On Mar 9, 2016, at 6:28 AM, Sandra Murphy wrote: > As discussed in December, a new version for draft-ietf-sidr-rfc6485bis = was required to deal with an IESG comment on the Security Considerations = section. >=20 > The authors have submitted a new version and ask for a working group = last call. >=20 > This starts the wglc which will end on 23 Mar 2016. Please review the = draft for its readiness for publication and provide comments to the = list. >=20 > Positive support is needed in order to judge consensus for = publication, so please do comment on the list. >=20 > The draft is available at: = https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-05. >=20 > =97Sandy, speaking as one of the wg co-chairs > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_DC92A55E-C892-423C-A9BF-844A27F96AF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBP3iAAoJEHplpQeet0IZdDIP/2JpvwjaqjYnEka1XuKN49tX lb775DM7OdaeXYFMFHdvlm5tQ2B27h27meQ6ZhhJJhSMo5MavkjNI8IUPK02+FR6 sF5Accrdl01IJBCJ521OiKAl7/DawSjTvmtKukG0TducKiXuCNdzsm22mQQ68mmq g9RF89wYw0aXRCNQvtSsm/3E7R+gylrj1VySnL036GwLv9/kj6esIhUn4ecBPp03 svKIaMqhZZi/s8he5mIxGUD+3xK9Z/Q3kqZVG32X05ShWCVUXWy8yh1sQ1DpNtlQ js2S5U0RvXLbsBXDpQRUoUolHI/3KDHhdvHSMXXqsniIBq2lF27itgjfQgILO9P7 C8HTnq+r4MW+KnipE1dhn391ZdPKerATRJ+vfH5ORy6b+SF1c/7TlR88EEr8ZSHd tTWHP8hox0fLBjdPfNGVd6da86gW32raAAzM8AcErwaqdBk95D7CjFfyqV0ymV8s 6vJsF+GktZnvAFcfV8bgBDTm7/uZimZKlqEoIijp7z7dIqBelfTMxetnMFqGoS0H dHZ2ncq3UxtRbfGWqD0/htH0ZDBGG9VVxTr9beuuaHqW49VofLjjFOHKz+OEcuWy BkLPUjEUwJgj2/JBdRsAeDlj7uYIoFhBRMjLW9u1qQfHHGJfBFAqB6fQkg0yi5K4 dOy2LzsiIQ0VcaTiP69C =qN2s -----END PGP SIGNATURE----- --Apple-Mail=_DC92A55E-C892-423C-A9BF-844A27F96AF8-- From nobody Wed Apr 6 05:56:42 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29612D0B5 for ; Wed, 6 Apr 2016 05:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th-xD1mjPVHh for ; Wed, 6 Apr 2016 05:56:39 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2535312D1A2 for ; Wed, 6 Apr 2016 05:56:39 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 82A3F28B003D; Wed, 6 Apr 2016 08:56:38 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id ABECE1F801E; Wed, 6 Apr 2016 08:56:37 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1D2F3452-9391-4C66-930D-B1705C5E189B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: Date: Wed, 6 Apr 2016 08:55:09 -0400 Message-Id: <51663D87-1ABC-45D0-B8A9-B59041793FE4@tislabs.com> References: <20151214170534.11198.66446.idtracker@ietfa.amsl.com> To: John Scudder X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "sidr@ietf.org list" , Sandra Murphy Subject: Re: [sidr] [Idr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:56:41 -0000 --Apple-Mail=_1D2F3452-9391-4C66-930D-B1705C5E189B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There being no complaint from sidr about this post-wglc change, and the = idr review also being judged as successful, the wg consensus is judged = to support publication of this version of the draft. A publication request will be issued shortly. =97Sandy, speaking as wg co-chair On Dec 14, 2015, at 12:09 PM, John G. Scudder wrote: > Hi Everybody, >=20 > Just when we thought we were completely done with this draft, we were = approached by Thomas King who pointed out a use case that can be enabled = by validation signaling, which benefits from a minor revision in the = language of the draft. Here's the revision: >=20 > OLD: > By default, implementations SHOULD drop the origin validation state > extended community if received from an EBGP peer, without further > processing it. However an implementation MAY be configured to = accept > the community when warranted, for example when the EBGP session is = to > a neighbor AS under control of the same administration. Similarly, > an implementation SHOULD NOT send the community to EBGP peers but = MAY > be configured to do so if warranted. >=20 > NEW: > By default, implementations SHOULD drop the origin validation state > extended community if received from an EBGP peer, without further > processing it. Similarly, by default an implementation SHOULD NOT > send the community to EBGP peers. However it SHOULD be possible to > configure an implementation to send or accept the community when > warranted. An example of a case where the community would = reasonably > be received from, or sent to, an EBGP peer is when two adjacent ASes > are under control of the same administration. A second example is > documented in [I-D.kklf-sidr-route-server-rpki-light]. >=20 > The change does two things. One is to add an informative reference to = Thomas's draft. The second is a change in emphasis. Whereas we formerly = said that an implementation MAY be configured to send and/or receive the = community over EBGP, now we say it SHOULD be possible to configure it to = do that. >=20 > I'm hoping this change will be noncontroversial and we can continue to = move forward towards RFC, however I anticipate the respective working = group chairs of SIDR and IDR (for obvious reasons I'm recusing myself) = may want to have a period to allow people to comment. >=20 > Thanks, >=20 > --John >=20 >> On Dec 14, 2015, at 12:05 PM, 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 Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : BGP Prefix Origin Validation State Extended = Community >> Authors : Pradosh Mohapatra >> Keyur Patel >> John Scudder >> Dave Ward >> Randy Bush >> Filename : = draft-ietf-sidr-origin-validation-signaling-08.txt >> Pages : 5 >> Date : 2015-12-14 >>=20 >> Abstract: >> This document defines a new BGP opaque extended community to carry >> the origination AS validation state inside an autonomous system. >> IBGP speakers that receive this validation state can configure local >> policies allowing it to influence their decision process. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signali= ng/ >>=20 >> There's also a htmlized version available at: >> = https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-08= >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-validation-sign= aling-08 >>=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 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_1D2F3452-9391-4C66-930D-B1705C5E189B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBQcuAAoJEHplpQeet0IZPZUP/Ak/ouVr38O1EWKBhclx0XNy CMQl+PUfM/PWiG3HgTDEKJNULzXgttpMn6nYYTbWhkMvDWAVVICndmntHP5iUHoN FpaZWnUoHaXCx/ag6hh7gm63wIiOEM0lEbyOM8X+WSzmboma4yGAdbAzrnZtkFTA rcIrd1o7BYQbsT2rpLkDizHCy6/oYpYh72WBY5n2dALRwu6GjmSTFFxM0VdpxY2W Q8SvA44qMOm49GtkvYcr2dy3hLYdvCY7jQo+lUTPbtTJ0PjYGqPjfej4M89ze+/P ezcqJpQ7AFFNFOF0ZoiMD3yBiap/IAyLMKPD8BgFWx1ydUWOpH9NborIydVwMoXq DHojan02z4JA58a/Y6wi4GFnLNV466dr4D9G+1JTKeL93gYeia3lOwISlmqLd8Fc fNpSknQS5fL6HJujEh/9zzUn3Y7r1jO6LwKqGF19AZlJ5vhOu/+dC0mV/C5/2DpM xFIIjbz93OVRLzohkq3PFTct9JcgLmD0PtBBTiYAoREaLELSQdlCB+d4wa2af6K4 6/QR+rlmkD8awfbvHih0PiWnWhIKLT614JI+zoDNjeFsasN+qiaMUhXFmDAMVUm+ eZEdJO8/vXA3f2mPIbICmw3ihKPmNSweE9QV1mbK9Fv36aULbu2JAtkZEkjh1duO iWzXBob0U/e4E1EcrnH1 =sFxH -----END PGP SIGNATURE----- --Apple-Mail=_1D2F3452-9391-4C66-930D-B1705C5E189B-- From nobody Wed Apr 6 06:24:20 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153FA12D514 for ; Wed, 6 Apr 2016 06:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEBm2zPA-iDF for ; Wed, 6 Apr 2016 06:24:17 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FE912D1A8 for ; Wed, 6 Apr 2016 06:24:17 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0AE7728B0048; Wed, 6 Apr 2016 09:24:17 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 027EF1F801E; Wed, 6 Apr 2016 09:24:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sandra Murphy In-Reply-To: <083B024B-DA3A-4D1B-A77B-382F69D99A1C@parsons.com> Date: Wed, 6 Apr 2016 09:24:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083B024B-DA3A-4D1B-A77B-382F69D99A1C@parsons.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-15 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:24:19 -0000 The wglc is ended and the wg consensus supports publication. The chairs = will be requesting publication shortly. =97Sandy, speaking as wg co-chair On Mar 17, 2016, at 9:33 AM, Sandra Murphy = wrote: > This starts a two week wglc for draft-ietf-sidr-bgpsec-15. =20 >=20 > The draft is available at = https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-15. >=20 > Please respond with your opinion of the draft=92s readiness for = publication. >=20 > Remember that positive replies are needed, so please do provide = comments to the list. >=20 > =97Sandy, speaking as one of the wg co-chairs > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Apr 6 09:52:05 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD96312D5E7 for ; Wed, 6 Apr 2016 09:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4itw_o6-Pdsh for ; Wed, 6 Apr 2016 09:52:02 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE0112D5E2 for ; Wed, 6 Apr 2016 09:52:01 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 33EF828B005C for ; Wed, 6 Apr 2016 12:52:01 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3AA821F801E; Wed, 6 Apr 2016 12:51:59 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_9CD6A737-A657-459F-AE16-61EE32B9BF1F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 6 Apr 2016 12:51:52 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] query about certificate validity times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:52:04 -0000 --Apple-Mail=_9CD6A737-A657-459F-AE16-61EE32B9BF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking only as a regular ol=92 wg member. Thought I=92d bring this up while lots of people are here together. I happened to ask a question of an RIR that identified an error - a = certificate they issued did not include all the resources of an = organization that it should have included. The RIR corrected the error, adding the missing resources. Except that I noted that the validity start date of the new expanded = certificate had not changed. I checked to see if this was deliberate =97 to make the certified = resources as they should always have been. But (if I understand correctly) when the RIR issues a new cert with = added resources, they do not change the validity start time. This is a problem for historical forensic analysis (credit Doug = Montgomery for that phrase). Of course, I could have misunderstood. I=92m curious. What thinks the wg? What thinks those who are operating = CAs? =97Sandy, speaking only as regular ol=92 member --Apple-Mail=_9CD6A737-A657-459F-AE16-61EE32B9BF1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBT6uAAoJEHplpQeet0IZYBwQALZm7vwRto3K8aRZ82Sm0A6a 6lX7nQrx5UtvuR3NDKK/Lfd4962usETl0uuGgmfU1nIIlVy3u0cOEcq+pspft9th 7IhAHAyxpe1AUTlNj9xh5rY9GObfDiVtVcVqhFS8hdcyH0fRxEBx+VKXX1HYnq/f taq+PDbSK69gV7nJamc9bTYeqdCZr+Ky2yc4ZtXb7X0Ymuq/jkje9toW4oK7P1q0 FfoT+gVnEuXPYWaCwn2DK6xfK8eg1FS2E9ns7jc6hmX2156n4kM+pM07swruihhW MOOdzs09DBdhYbB/4aO1QhzArrsL4HUY3Xqliuo1wUOOjJU/aj0vmU1+7mGOw4C1 o4pTK5g8JdkawszGiCV9ogPrnd3Cnc5UgSKM4LUiSy0CgulovRzaKGYAlw0yQtJi KPfjxRhKJ4l/X73U4sH6xf6o5dZrQzJGJhiEaBAhaks0vkvAu0Y+PAZoJ+jhL1x6 5QO5dLLSSW9triQiHM+19pweLxAlWBztVvtxYuUG3wCiLx/FuCVMHKwYif8EfiQR 0PBWIEyTOlIyrhrFbee60KPYAvYCE6jZ4cjvvEbHZ9w+2DsKXNSyEbA/6FeGhfYo LphXV+QuDxepZpSv7wGmGUGGksOd080bFotxkdxzWlHIfX7wT/gUQ/F9IHCCasDn L6kUb07B0HxNl6xhZyjf =RRJi -----END PGP SIGNATURE----- --Apple-Mail=_9CD6A737-A657-459F-AE16-61EE32B9BF1F-- From nobody Wed Apr 6 11:23:39 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6228F12D129 for ; Wed, 6 Apr 2016 11:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzYZvYg2KhVE for ; Wed, 6 Apr 2016 11:23:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6614512D0E7 for ; Wed, 6 Apr 2016 11:23:33 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:61942) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ans72-000Cf4-4V for sidr@ietf.org; Wed, 06 Apr 2016 14:23:32 -0400 To: sidr From: Stephen Kent Message-ID: <57055423.6060703@bbn.com> Date: Wed, 6 Apr 2016 14:23:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010604000103060807070404" Archived-At: Subject: [sidr] suggested text for adverse actions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:23:35 -0000 This is a multi-part message in MIME format. --------------010604000103060807070404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To address the topic Tim B. raised wrt the IRR system, and n light of the comments provided by the cognizant routing AD, I propose adding the following text as a second paragraph in the Security Considerations section. Unless I hear suggestions otherwise, I'll add this text before we submit this as we post the I-D as a WG document. Steve ------- The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors, in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology [RFC2650, RFC2725], which uses the Routing Policy Specification Language (RPSL) [RFC2622]. The IRR technology exhibits its own set of security problems, which are discussed in [RFC7682]. --------------010604000103060807070404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit To address the topic Tim B. raised wrt the IRR system, and n light of the comments
provided by the cognizant routing AD, I propose adding the following text as a
second paragraph in the Security Considerations section.

Unless I hear suggestions otherwise, I'll add this text before we submit this as
we post the I-D as a WG document.

Steve
-------

The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors, in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology [RFC2650, RFC2725], which uses the Routing Policy Specification Language (RPSL) [RFC2622]. The IRR technology exhibits its own set of security problems, which are discussed in [RFC7682].



--------------010604000103060807070404-- From nobody Wed Apr 6 12:03:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00612D789 for ; Wed, 6 Apr 2016 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmFBN-wkiAed for ; Wed, 6 Apr 2016 12:03:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE11812D6AD for ; Wed, 6 Apr 2016 12:02:37 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:62006) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ansil-0008QY-Km for sidr@ietf.org; Wed, 06 Apr 2016 15:02:31 -0400 To: sidr@ietf.org References: From: Stephen Kent Message-ID: <57055D47.8050801@bbn.com> Date: Wed, 6 Apr 2016 15:02:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] query about certificate validity times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:03:07 -0000 Sandy, Keeping the original notBefore date/time isn't "wrong" but I agree that it would be preferable to change the value to the re-issue date/time, as per Doug's suggestion. Steve From nobody Fri Apr 8 08:16:06 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4012D1A2 for ; Fri, 8 Apr 2016 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhkKrQ5xJV0g for ; Fri, 8 Apr 2016 08:15:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C5F12D94B for ; Fri, 8 Apr 2016 08:15:52 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:43874 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aoY8U-0000FT-Rx for sidr@ietf.org; Fri, 08 Apr 2016 11:15:51 -0400 To: sidr From: Stephen Kent Message-ID: <5707CB26.5060706@bbn.com> Date: Fri, 8 Apr 2016 11:15:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010408080306000907070407" Archived-At: Subject: [sidr] comments on validation reconsidered -03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:16:05 -0000 This is a multi-part message in MIME format. --------------010408080306000907070407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit First, let me say this this version of the document is much improved relative to previous versions. I do have a few observations about this version, and some suggested changes. Abstract: There are 2 typos, and I think you want to assert that the revisions don’t undermine security, right? This document proposes an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. Also, presumably, this is not really "an alternative" but a proposal to UPDATE 6487 so that all RPs use the new pat validation algorithm, right? Section 2: The final sentence here says: The roa "ROA1" is also considered valid here in this regard - the prefix is encompassed by the embedded EE certificate. The example ROA is valid, but the final check on ROA validation is specified in RFC 6482, not in 6488. Thus the text might say: The ROA “ROA1” is valid because the specified prefix is encompassed by the embedded EE certificate, as required by RFC 6487. Similar wording shouldbe used when discussing the validity of ROAs in other examples throughout the document. Section 3: The motivation cited here “resource allocations can change in the RPKI” is so terse as to be not very persuasive. Previous versions of the draft mentioned resource transfers, for example. We have no standard for how to perform a transfer, however one could state that the proposed changewould reduce the constraints imposed on the order in which the CAs involved in a transfer re-issue certificates. Also, if you believe that the proposed change will help minimize the impact of some types of operational errors, then that too could be said. For example: The allocations recorded in the RPKI change as a result of resource transfers and some types of operational errors. For example, the CAs involved in transfer might choose to modify CA certificates in an order that causes some of these certificates to “over-claim” temporarily. Some types of operational errors that may occur during management of RPKI databases also may create CA certificates that, temporarily, no longer encompass all of the resources in subordinate certificates. The proposed changes (Section 4) to the validation procedure in [RFC6487] are intended to avoid causing CA certificates to be treated as invalid during transfers and as the result of some types of operational errors. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, no ROAs or router certificates will be treated as valid if they contain resources that are not encompassed by all superior certificates along a path to a trust anchor. If you believe this text matches your intent, I think it provides a better rationale for making the proposed changes. The text at the top of page 4 says: It should be noted that CA2 is not claiming any resources on ROA1 that it cannot receive on a new Certificate 3. I expected you to say that the EE certificate in ROA1 does not make use of any of the address resources that were removed from CA1’s certificate, and thus it would be desirable if ROA1 could still be viewed as valid. This motivates the goal of the proposedchanges, i.e., to avoid having a ROA become “collateral damage” due to over-claiming by a superior CA certificate. Saying that a new Cert3 can be issued to fix this problem is true, but fails to focus on the goal of minimizing the impact of an operational error of this sort. The paragraph that discusses how one might modify the text in 6492 to avoid over-claiming by subordinate CAs, when resources are removed from a CA certificate is problematic. Nothing prevents a CA from unilaterally re-issuing a certificate to subordinate CAs with reduced resource sets, when the CA itself requests (or is given) a certificate with a reduced resource set. The next paragraph seems to say that, indirectly, but it’s confusing (at least to me). The final paragraph of this section introduces the notion that the reason for the reduction in scope of CA1’s certificate is a dispute between the TA and that CA. This is pretty late in the section to suggest that this is why the CA certificate was reissued with reduced resources. And it doesn’t align with the rationale you provided or that I suggested above. I suggest these paragraphs need to be revised. Section 4: I don’t feel the revised text here is precise enough to provide clear guidance to implementers. RFC 6487 does not mention the term intersection in discussing path validation, so introducing that term in one sentence seems too terse. The text I provided a few months ago provided a more thorough discussion of the revised algorithm. For example, it noted the need to maintain two sets of resource data as part of the algorithm (one for addresses and one for ASNs), something not specified here. Also, the paragraph describing how to interpret the inherit flag is true, but I think it belongs as the beginning of the description of the revised procedure, with the introduction of the two working resource sets. In the current description its location of the two paragraphs below is very confusing. For any of the resource extensions that use the "inherit" element as described in sections 2.2.3.5 and 3.2.3.3 of [RFC3779], the corresponding resources of this type should be taken from the parent certificate, where this issuer is the subject. For any other resources the intersection of the quoted resources on this certificate and the parent certificate is kept.If any resources were found on this certificate that were not present on the parent certificate a warning SHOULD be issued to help operators rectify this situation. The second paragraph exempts the resources specified by an inherit flag from the intersection operation. Do you really want that to happen? Also, the term “quoted” isn’t well-defined in this context. Do you mean the resources specified in the certificate? The last sentence/paragraph in the revised path validation description says: If the the [sic] set of verified resources obtained this way is empty, then the certificate MUST be considered invalid. It’s unclear frothis statement whether a certificate is invalid if either the address or ASN extensions yield an empty intersection, or only if both intersections are empty, or what. This is another example of why I think the proposed path validation algorithm needs to include additional details. Overall, I think you need to expand the description of the validationalgorithmrevisions. The revised text should establish the fact that there are two working sets and say that these sets are to be used in lieu of the 3779 extensions in a certificate (after performing the intersection operation). If you don’t want to also revise RFC 6482, thenyou need to state that the working set is to be used in lieu of the 3779 extensions when performing further validation operations, and cite 6482 as an example. Section 5: It’s nice to begin with a note stating that the concerns that motivate the proposed revision to 6487 have not yet surfaced. However, referring to over-claiming as an “inconsistency” seems needless indirect. You refer to over-claiming as the problem throughout the document, so why not here? The next paragraph again refers to the over-claimed resources as being “under dispute.” I think this is too narrow a characterization of the circumstance that might result in a over-claiming certificate being issued. Please revise this sentence to better characterize the range of situations that might result in over-claiming, or provide a back pointer to a section of the document where that topic is discussed. I find the opening sentence of the last paragraph here to be a bit confusing: It should be noted that although this is a problem with a low probability today this is largely due to the fact that most current RPKI systems use their own Trust Anchor and do not support any large number of delegated CAs. … By “RPKI systems” do you the RIRs as high-tier CAs? Relying parties select Trust Anchors, so this sentence is not quite consistent with usual PKI terminology. How about this phrasing: Although the concerns that motivates this revision to RPKI path validation has not yet been observed in practice, this may be largely due to the fact that most of the certificates have been issued directly by the RIRs. Each RIR operates its own Trust Anchor (or set of Trust Anchors) and there are few (non-RIR) CAs that have established subordinate CAs with distinct resource holdings. When more CAs receive certificates from non-RIR parents, and when more transfers of resources involve more than three CAs (source, target, and common ancestor), the authors anticipate that these concerns will become more commonplace. --------------010408080306000907070407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

First, let me say this this version of the document is much improved relative to previous versions. I do have a few observations about this version, and some suggested changes.

 

Abstract:

 

There are 2 typos, and I think you want to assert that the revisions don’t undermine security, right?

 

   This document proposes an alternative to the certificate validation

   procedure specified in RFC 6487 that reduces aspects of operational

   fragility in the management of certificates in the RPKI, while retaining

   essential security features.

 


Also, presumably, this is not really "an alternative" but a proposal to

UPDATE 6487 so that all RPs use the new pat validation  algorithm, right?

Section 2:

 

The final sentence here says:

 

The roa "ROA1" is also considered valid here in this regard

- the prefix is encompassed by the embedded EE certificate.

 

The example ROA is valid, but the final check on ROA validation is specified in RFC 6482, not in 6488. Thus the text might say:

 

The ROA “ROA1” is valid because the specified prefix is encompassed by the embedded EE certificate, as required by RFC 6487.

 

Similar wording should  be used when discussing the validity of ROAs in other examples throughout the document.

 

Section 3:

 

The motivation cited here “resource allocations can change in the RPKI” is so terse as to be not very persuasive. Previous versions of the draft mentioned resource transfers, for example. We have no standard for how to perform a transfer, however one could state that the proposed change  would reduce the constraints imposed on the order in which the CAs involved in a transfer re-issue certificates. Also, if you believe that the proposed change will help minimize the impact of some types of operational errors, then that too could be said. For example:

 

The allocations recorded in the RPKI change as a result of resource transfers and some types of operational errors. For example, the CAs involved in transfer might choose to modify CA certificates in an order that causes some of these certificates to “over-claim” temporarily. Some types of operational errors that may occur during management of RPKI databases also may create CA certificates that, temporarily, no longer encompass all of the resources in subordinate certificates.

 

The proposed changes (Section 4) to the validation procedure in [RFC6487] are intended to avoid causing CA certificates to be treated as invalid during transfers and as the result of some types of operational errors. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, no ROAs or router certificates will be treated as valid if they contain resources that are not encompassed by all superior certificates along a path to a trust anchor.

 

If you believe this text matches your intent, I think it provides a better rationale for making the proposed changes.

 

The text at the top of page 4 says:

 

   It should be noted that CA2 is not claiming any resources on ROA1

   that it cannot receive on a new Certificate 3. 

 

I expected you to say that the EE certificate in ROA1 does not make use of any of the address resources that were removed from CA1’s certificate, and thus it would be desirable if ROA1 could still be viewed as valid. This motivates the goal of the proposed  changes, i.e., to avoid having a ROA become “collateral damage” due to over-claiming by a superior CA certificate. Saying that a new Cert3 can be issued to fix this problem is true, but fails to focus on the goal of minimizing the impact of an operational error of this sort.

 

The paragraph that discusses how one might modify the text in 6492 to avoid over-claiming by subordinate CAs, when resources are removed from a CA certificate is problematic. Nothing prevents a CA from unilaterally re-issuing a certificate to subordinate CAs with reduced resource sets, when the CA itself requests (or is given) a certificate with a reduced resource set. The next paragraph seems to say that, indirectly, but it’s confusing (at least to me). The final paragraph of this section introduces the notion that the reason for the reduction in scope of CA1’s certificate is a dispute between the TA and that CA. This is pretty late in the section to suggest that this is why the CA certificate was reissued with reduced resources. And it doesn’t align with the rationale you provided or that I suggested above.

I suggest these paragraphs need to be revised.

 

Section 4:

 

I don’t feel the revised text here is precise enough to provide clear guidance to implementers. RFC 6487 does not mention the term intersection in discussing path validation, so introducing that term in one sentence seems too terse. The text I provided a few months ago provided a more thorough discussion of the revised algorithm. For example, it noted the need to maintain two sets of resource data as part of the algorithm (one for addresses and one for ASNs), something not specified here. Also, the paragraph describing how to interpret the inherit flag is true, but I think it belongs as the beginning of the description of the revised procedure, with the introduction of the two working resource sets. In the current description its location of the two paragraphs below is very confusing.

 

     For any of the resource extensions that use the "inherit"

       element as described in sections 2.2.3.5 and 3.2.3.3 of

       [RFC3779], the corresponding resources of this type should be

       taken from the parent certificate, where this issuer is the

       subject.

 

     For any other resources the intersection of the quoted

       resources on this certificate and the parent certificate is

       kept.  If any resources were found on this certificate that

       were not present on the parent certificate a warning SHOULD be

       issued to help operators rectify this situation.

 

The second paragraph exempts the resources specified by an inherit flag from the intersection operation. Do you really want that to happen? Also, the term “quoted” isn’t well-defined in this context. Do you mean the resources specified in the certificate?

 

The last sentence/paragraph in the revised path validation description says:

 

      If the the [sic] set of verified resources obtained this way is empty,

      then the certificate MUST be considered invalid.

 

It’s unclear fro  this statement whether a certificate is invalid if either the address or ASN extensions yield an empty intersection, or only if both intersections are empty, or what. This is another example of why I think the proposed path validation algorithm needs to include additional details.

 

Overall, I think you need to expand the description of the validation  algorithm  revisions. The revised text should establish the fact that there are two working sets and say that these sets are to be used in lieu of the

3779 extensions in a certificate (after performing the intersection operation). If you don’t want to also revise RFC 6482, then  you

need to state that the working set is to be used in lieu of the 3779

extensions when performing further validation operations, and cite 6482 as an example.

 

Section 5:

 

It’s nice to begin with a note stating that the concerns that motivate the proposed revision to 6487 have not yet surfaced. However, referring to over-claiming as an “inconsistency” seems needless indirect. You refer to over-claiming as the problem throughout the document, so why not here?

 

The next paragraph again refers to the over-claimed resources as being “under dispute.” I think this is too narrow a characterization of the circumstance that might result in a over-claiming certificate being issued. Please revise this sentence to better characterize the range of situations that might result in over-claiming, or provide a back pointer to a section of the document where that topic is discussed.

 

I find the opening sentence of the last paragraph here to be a bit confusing:

 

   It should be noted that although this is a problem with a low

   probability today this is largely due to the fact that most current

   RPKI systems use their own Trust Anchor and do not support any large

   number of delegated CAs. …

 

By “RPKI systems” do you the RIRs as high-tier CAs? Relying parties select Trust Anchors, so this sentence is not quite consistent with usual PKI terminology. How about this phrasing:

 

   Although the concerns that motivates this revision to RPKI path validation

   has not yet been observed in practice, this may be largely due to the fact

   that most of the certificates have been issued directly by the RIRs. Each

   RIR operates its own Trust Anchor (or set of Trust Anchors) and there are

   few (non-RIR) CAs that have established subordinate CAs with distinct

   resource holdings. When more CAs receive certificates from non-RIR parents,

   and when more transfers of resources involve more than three CAs (source,

   target, and common ancestor), the authors anticipate that these concerns

   will become more commonplace.

 

 

 

--------------010408080306000907070407-- From nobody Mon Apr 11 16:16:54 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E520812F5F1; Mon, 11 Apr 2016 16:16:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160411231649.13201.39457.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 16:16:49 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:16:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Services Author : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-04.txt Pages : 20 Date : 2016-04-11 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable secure means. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging BPKI keying material. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-oob-setup-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 11 16:24:34 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B7F12F630 for ; Mon, 11 Apr 2016 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 D9mY17fDg9og for ; Mon, 11 Apr 2016 16:24:32 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388A212F631 for ; Mon, 11 Apr 2016 16:24:32 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id D04E417062 for ; Mon, 11 Apr 2016 23:24:31 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 175FE3E786D9 for ; Mon, 11 Apr 2016 19:24:28 -0400 (EDT) Date: Mon, 11 Apr 2016 19:24:28 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20160411231649.13201.39457.idtracker@ietfa.amsl.com> References: <20160411231649.13201.39457.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160411232428.175FE3E786D9@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:24:33 -0000 One minor substantive change: added an optional "tag" attribute (as in the publication protocol) to simplify client matching of responses with outstanding requests. This capability was in the original protocol but in a very obscure form, and was removed as part of the general cleanup; recent experience talking a user through using an implementation of this protocol suggested that the protocol does need this capability, so -04 puts it back in (what I hope is) clearer form. Other than that, the only changes editorial, filling in TBD stuff like IANA considerations (none), and so forth. I think this is ready for WGLC. From nobody Wed Apr 13 11:17:44 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EEF12DE3A for ; Wed, 13 Apr 2016 11:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 2nGD0r-ZfX2O for ; Wed, 13 Apr 2016 11:17:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9F312DB60 for ; Wed, 13 Apr 2016 11:17:41 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37572 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aqPMC-000HIk-HW for sidr@ietf.org; Wed, 13 Apr 2016 14:17:40 -0400 To: sidr From: Stephen Kent Message-ID: <570E8D44.1080208@bbn.com> Date: Wed, 13 Apr 2016 14:17:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 18:17:43 -0000 I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR session, at which the issue was raised as to whether the BGPSec RFC should be standards track or experimental. I believe standards track is the right approach here. This document has been viewed as standards track since we began work on it long ago. It is the successor to the origin validation standards, addressing the residual vulnerabilities that persist based on that use of the RPKI. From the perspective of promoting adoption it is critical that this remain a standards track document; router vendors will be unlikely to devote resources to design and implementation if BGPsec is labeled experimental. I agree that this is new technology, but I heard that we already have a couple of implementations already, and we may discourage others from continuing to work on BGPSec implementations if we downgrade the status of the RFC. The design has evolved to accommodate real-world routing deployment topics such as the role of IXPs and AS migration. In my long experience in the IETF experience, the level of attention to these an analogous details makes BGPsec a very solid candidate for standards track publication. Steve From nobody Wed Apr 13 11:36:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388E712D943 for ; Wed, 13 Apr 2016 11:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 rCJsTor4bnQZ for ; Wed, 13 Apr 2016 11:36:09 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 555B612D8EA for ; Wed, 13 Apr 2016 11:36:09 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BC114F24061 for ; Wed, 13 Apr 2016 14:36:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id eNnkrvSlPCvP for ; Wed, 13 Apr 2016 14:21:08 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5E9D1F2401F for ; Wed, 13 Apr 2016 14:36:08 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <570E8D44.1080208@bbn.com> Date: Wed, 13 Apr 2016 14:36:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <570E8D44.1080208@bbn.com> To: IETF SIDR X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 18:36:11 -0000 I didn't attend the IETF meeting because I as chairing another session = in another room at the same time. During that session the issue was = raised as to whether the BGPSec RFC should be standards track or = experimental. I strongly support publication on the standards track. = There are already two interoperable implementations, so I think that all = of the criteria for advancement on the standards track have been met = before we even get published at the proposed standard. I believe that publication as experimental will greatly delay = deployment, which will already take a very long time. Let=92s mover = forward on this journey and get some real experience. Russ From nobody Wed Apr 13 14:10:00 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C658812D0B3; Wed, 13 Apr 2016 14:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413210956.17329.84437.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 14:09:56 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:09:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI Author : David Mandelberg Filename : draft-ietf-sidr-slurm-01.txt Pages : 11 Date : 2016-04-13 Abstract: The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. In the future, ISPs also will be able to use the RPKI to validate the path of a BGP route. Some ISPs locally use BGP with private address space or private AS numbers (see RFC6890). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid based on the global RPKI (see RFC6491). The mechanisms described below provide ISPs with a way to make local assertions about private (reserved) INRs while using the RPKI's assertions about all other INRs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-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 Wed Apr 13 14:21:22 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8A012D990 for ; Wed, 13 Apr 2016 14:21:21 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 xbNLioGH4qHp for ; Wed, 13 Apr 2016 14:21:19 -0700 (PDT) Received: from nm26-vm7.access.bullet.mail.bf1.yahoo.com (nm26-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.214]) (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 DFF6712D924 for ; Wed, 13 Apr 2016 14:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460582476; bh=0dz+YM2RQncmJ8gQqJZxVBxNN/KSUiC6YNzVyglx90Q=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=K2Rw0bzTwxtgSot/ZaG8nrf70fX5z/r+N1h7LcF6VgBSFRYrM/FTQho7wZaMDqE/EvigdwwErGB0BMz2uKia8RRzbDkoa/xwUYx+igr1oROJWNOAfz1A+HXb3th9MJI/SzaobdrQEQ9jOclfjBYcuwdphbDW9K3II7OREgOvTSyZo/1XYfARau2uueoamDgX3LiN9L1ZuoEmIJKfZXTq7itTMjueh4uiP0fwWAgMuS+zNb3muFA/2Tn83cYWleuFF5+ntJDcKuv3g/xXP7K5yr5h+0wduU5xejDQ5c6xjFZJECOXAAHh32SpWOQrC1YyqLiTpXpDt+URNYZ+XydQLg== Received: from [66.196.81.160] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2016 21:21:16 -0000 Received: from [98.138.226.240] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2016 21:21:16 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 13 Apr 2016 21:21:16 -0000 X-Yahoo-Newman-Id: 795930.17079.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4KGcbW0VM1lP2Q07.2CUCnoRNXKmAATeuM1vg_62iE.MXc3 le1Bapgk5zdslf25Cl.af4UpkDjKJAMN5C9HGg4Strm1G4ZfrjrCblTel7.X VkGaGBF2_8pJQ6haEzPm7RBGVCL5lm6yxyF9qDxXO.q6VjeqZvwC09y6eZ_G tKxPnoNVU5MHLfVGniO1cLQPA_iTan3KTRjBgWauDqYqr7pyqfsTeC9FcQ6M Y0cSA3O1RV9FyPG0qboa.U9GJliTcBrgIYeKywCQRbw1JbvDxeg6jWbZ.Zmz 7itVdzefX66ybOz9qOWQYzqBK2H1yLnCYDw7_N2dlERAImKk_oaBBuo0df_3 LCR575Lht.r7EkGiPgxyffJhHdVjAVGJsTIl9HUblaUiCfJdfUaPfC7BS27W oSB9rFjQkajtSs_MjxO8IDf6u1qa3EZtg1DXxqnHdo44.dnB3RaZRulAUR_n zQvZSqZGE4te1LUuSPqm91y2I6ovUVeoxTk2EQB2mlu4XuDXZp7lZFQbLf6s yAdwYbNOZENsWJYnY8gFofoFtZ38- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 7A6BD1C6006 for ; Wed, 13 Apr 2016 17:21:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Apr 2016 17:21:15 -0400 From: David Mandelberg To: In-Reply-To: <20160413210956.17329.84437.idtracker@ietfa.amsl.com> References: <20160413210956.17329.84437.idtracker@ietfa.amsl.com> Message-ID: <62e87ac555c59fd5d3cde4f52b89b69b@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-slurm-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:21:21 -0000 Hi all, I believe this draft addresses all of the comments I've received so far, and is ready for WGLC. Chairs, please consider this a formal request. Here's a summary of changes from the previous version: * In Validation Output Filtering, an origin validation assertion where the prefix covers the locally reserved prefix, is no longer removed from the RP's output. For private-use prefixes, this change shouldn't be significant because there are no public covering routes. For other prefixes (e.g., stolen/borrowed public ones), this reduces the likelihood of accidentally invalidating an important covering route. * The document is now more clear and consistent about use of SLURM with non-private INRs. * The intended status is now STD instead of BCP. (I think it was BCP by mistake.) * I removed references to LTAM because LTAM is now dead. * I removed references to Suspenders because I think SLURM is ready for WGLC and Suspenders is still an individual draft. On 2016-04-13 17:09, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing of the > IETF. > > Title : Simplified Local internet nUmber Resource > Management with the RPKI > Author : David Mandelberg > Filename : draft-ietf-sidr-slurm-01.txt > Pages : 11 > Date : 2016-04-13 > > Abstract: > The Resource Public Key Infrastructure (RPKI) is a global > authorization infrastructure that allows the holder of Internet > Number Resources (INRs) to make verifiable statements about those > resources. Network operators, e.g., Internet Service Providers > (ISPs), can use the RPKI to validate BGP route origination > assertions. In the future, ISPs also will be able to use the RPKI > to > validate the path of a BGP route. Some ISPs locally use BGP with > private address space or private AS numbers (see RFC6890). These > local BGP routes cannot be verified by the global RPKI, and SHOULD > be > considered invalid based on the global RPKI (see RFC6491). The > mechanisms described below provide ISPs with a way to make local > assertions about private (reserved) INRs while using the RPKI's > assertions about all other INRs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-slurm-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Apr 13 22:15:00 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203C12D5BA for ; Wed, 13 Apr 2016 22:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-7z2H9AB1ts for ; Wed, 13 Apr 2016 22:14:58 -0700 (PDT) Received: from pv33p07im-ztdg10151401.me.com (pv33p07im-ztdg10151401.me.com [17.142.253.35]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADA212D1B1 for ; Wed, 13 Apr 2016 22:14:58 -0700 (PDT) Received: from [192.168.219.38] (unknown [124.17.24.198]) by pv33p07im-ztdg10151401.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O5L00BPEYKNQ310@pv33p07im-ztdg10151401.me.com> for sidr@ietf.org; Thu, 14 Apr 2016 05:14:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-14_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1604140076 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Declan Ma In-reply-to: Date: Thu, 14 Apr 2016 13:14:46 +0800 Content-transfer-encoding: quoted-printable Message-id: <8F474262-AF65-4ACB-8622-1DD0837A3CB5@icloud.com> References: <570E8D44.1080208@bbn.com> To: IETF SIDR X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 05:14:59 -0000 I think BGPsec should be Standards Track. ISPs and router vendors won=92t take BGPsec seriously if it is published = as an Experimental RFC. We came a long way here from S-BGP and so much time and so many efforts = by many have been spent on BGPsec. The community need some real = experience. Di ZDNS= From nobody Thu Apr 14 13:20:47 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC9612DB22 for ; Thu, 14 Apr 2016 13:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.787 X-Spam-Level: X-Spam-Status: No, score=-107.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXqfWlg99NHv for ; Thu, 14 Apr 2016 13:20:41 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (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 5689D12DA7E for ; Thu, 14 Apr 2016 13:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=M/KvLw3QYo3a+xxKEKCSBo6g5ZOZslNat840KkCM8bY=; b=MTFk9dQqfGiCb9iXpGR9jETh7JuNQhpyMohANPuCfMB24RjG6wk7kF0DAaBE2nAA3l6AMX604vH4y eOfcbQVUmaZgefoY9gphK+DKPhr37JCv5XVRbTap3BrC0+gZtGihaeQ+IdDInSMp5aYc+xaKsATuw2 gPEaULUrDjXw/xOM= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Fri, 15 Apr 2016 06:24:27 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 15 Apr 2016 06:20:04 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Geoff Huston In-Reply-To: <570E8D44.1080208@bbn.com> Date: Fri, 15 Apr 2016 06:20:28 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> References: <570E8D44.1080208@bbn.com> To: sidr X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:20:45 -0000 > On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: >=20 > I didn't attend the IETF meeting, but I did listen to the Wednesday = SIDR session, at > which the issue was raised as to whether the BGPSec RFC should be = standards track > or experimental. >=20 I was in the room, but did not speak to this topic.=20 > I believe standards track is the right approach here. I consulted the oracle of RFC2026 and read the following: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. This seems to fit well, including the caveats at the end. On the other hand: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). Which seems to fall short. The exercise of RFC publication of BGPSec is more than archival, and the = process has been much more than a cursory exercise of coordination with the SIDR = WG. While BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=E2=80=99s = Internet, that future uncertainty applies to most of the IETF=E2=80=99s work, and that = consideration=20 should not preclude its publication as a Proposed Standard, as I = interpret RFC2026. Geoff From nobody Thu Apr 14 16:51:18 2016 Return-Path: <7riw77@gmail.com> X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18DB12DAC4 for ; Thu, 14 Apr 2016 16:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Gp4TDDi1Y-GY for ; Thu, 14 Apr 2016 16:51:13 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 27B7412D846 for ; Thu, 14 Apr 2016 16:51:13 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id o66so120814267ywc.3 for ; Thu, 14 Apr 2016 16:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=iW2J1KxwlwXt+yFeAOWRUjT7dIktPSS+msCBGlhIUA0=; b=cdauwK04hC57neVDh6IOhyr90BJYv93dTk6J14+7g3k6kDuJ6OKDLDzeUFqyBRMqZ8 6GjXfviKCuQ1aqEk2HkpnSNPUUgQF9w6qFTfAu38BxJmGBwmTrq2ZUvkbPjN2YQK7o3/ FZGCyLMiJcWR/46TVF4Sxm3furiJVVxCX45LjQ/RfDr6WCZIr6l/Uj1xTAxTDCXqmJnA fahQLR5ojh7LRnmS8qhfstvRqg4drkpY6vTCYzvhbSpw/3ICXEqCRBhaou1huSpMo9Y0 Vy4jc/ESAlU2aP8+JI1c4agrPjltR8hB/DACfYLfsV+IrcOD/jKKwkAV/DmfTp/5b1u7 JCHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=iW2J1KxwlwXt+yFeAOWRUjT7dIktPSS+msCBGlhIUA0=; b=GEqCyP49+3K3ioo70JbwqSm7wzRaVzhbNcMCJehIKEb3Dp9QPO4LywttWY7kP5xx/H Scy5X/GGf+fgw7caMFa4bFJ9tb2V+EDcb4pzcHb7DtfTfTW/ktHfvDGlPHn4RqizpJeq znPV6vtw5WUlgAb8sr5aC8huaDPQdVK8kmsRFfE1IqpjbKWJzAC57G7rEULJ2UUqXxAz +R26FMRMxN8Glc65Qn+xP70Ayf6kxSVF/5Hl61PghCqtPMqxzIGXiVcIJAODptvj6I6D FFF5Nj+67me0pbXcCOH04Cj6kA7zmTrFySV8Rmlss4JrSk6bOGwPFK1/MEEgu3B4QHr8 j/fA== X-Gm-Message-State: AOPr4FWsA146pyVtnyTFctBfj3/as8MugfeATUMYvgmCweMwWQqftiTQPeg8NTMJkDVmUg== X-Received: by 10.129.153.65 with SMTP id q62mr10246874ywg.90.1460677872422; Thu, 14 Apr 2016 16:51:12 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id t201sm25203043ywe.45.2016.04.14.16.51.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 16:51:11 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'sidr'" References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> In-Reply-To: <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> Date: Thu, 14 Apr 2016 19:51:11 -0400 Message-ID: <052101d196a8$85e90c90$91bb25b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK50UkYZgz1WOiK04JSUwHF5BdAuwJ4+ki0naXh9GA= Content-Language: en-us Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 23:51:16 -0000 I wanted to address a point that's been brought up a number of times in = this thread -- the contention "if we don't go standards track, people = aren't going to be motivated to deploy this." There is an opposite = argument to be made in this line of logic -- "if we do go standards = track, there will no work done on any alternate solution -- because = there is a standard in place -- and if the standard ends up being = undeployable (which is, after 15+ years of work, still true), then we = will do nothing." Overall, I find it difficult to assess the risk in either direction, so = I think these two tend to equal one another out. OTOH, if we are going = to go standards track, it needs to be with the specifically called out = understanding that these drafts are not the final answer -- that the = IETF doesn't consider this the ultimate solution for the problem at = hand.=20 > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has = received > significant community review, and appears to enjoy enough community > interest to be considered valuable. =20 What is the meaning of "community interest." From which community, = specifically? Does "community interest" include actual deployment in = commercial networks, or ... ?? I'm not pretending to know the answer = here, just asking the question. :-) Russ From nobody Thu Apr 14 17:26:11 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC00612E1A2 for ; Thu, 14 Apr 2016 17:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 w3kKp9eGkfGI for ; Thu, 14 Apr 2016 17:26:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC3312E196 for ; Thu, 14 Apr 2016 17:26:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aqraJ-0000ps-Iv; Fri, 15 Apr 2016 00:26:07 +0000 Date: Fri, 15 Apr 2016 09:26:06 +0900 Message-ID: From: Randy Bush To: Russ White <7riw77@gmail.com> In-Reply-To: <052101d196a8$85e90c90$91bb25b0$@gmail.com> References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <052101d196a8$85e90c90$91bb25b0$@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 00:26:10 -0000 snmp, netconf, yang, ... heck even cops played in the space when your so-bgp, 15 years in the non-making, is mature as a document set, with two or more implementations, i'll support it for standards track, no problem. i am not desperate enough to sabatoge the work of others to move my work forward. randy From nobody Thu Apr 14 18:13:35 2016 Return-Path: <7riw77@gmail.com> X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D078812D6D6 for ; Thu, 14 Apr 2016 18:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 u1CVOGwvhwUp for ; Thu, 14 Apr 2016 18:13:32 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 5513C12DAA8 for ; Thu, 14 Apr 2016 18:05:13 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id d68so122234332ywe.1 for ; Thu, 14 Apr 2016 18:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Pim9TEtHR8vsBldvjUg352vWNAZ2wIDxs3MX3/gy+YA=; b=hpRz2a2ePbm7Vro49GpLgptnklILSSbkHaLOetJpThdqo2gvniRwDqqrClPXQOFOLt pgPocx8q3khTPQ0T7uNZVxhTKW645xhTpdmj3foFJ0whahhd3KnGplPzNMopRjLs3V2N V1fc/ks33PHBz1HLSqjmQAgcp7f36zplwTJYSc3ywzqHeOfwRoTQCNY4luHazcmuxVIu KcUevBIX6rciqG9AS0zbDHRg6xzvy83Oo52qF+e2KiARFoQkGOGNNuhLTdc10hK9uqnj GwoJ7TI2A1joCF5koVpmvvAvDtL245+58JFHAAJAOtgTIktZlUEkX97780g0rAG2Udca 9KaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Pim9TEtHR8vsBldvjUg352vWNAZ2wIDxs3MX3/gy+YA=; b=m1p2KR/4NxzXcwtdDbiX03rUzFfOGlUCMg6SaTSWbas6L9dM5AfuR/AykKjlQN+a1z UpzUh0vs/3TeDEOCNerRvY8qc4WV3Cd9UVoaQPeQp7zfMiGe+O7bryYsJl3sRoC4IIZw U/Z9NKXQimlLOwsVPI39xDaaRgk6t/fVexf5+8dmqLOosZIBeuvSAX9ghVY+T3E4G31a x4c5XqpG74PASDtshAvbyfRwcPm+SM9MzTId88eqO8Oitip9NQouN3hi33o34tqUKkRx UxaucEg1XNPpzQ0256Nb18UnU8ePoXhKVTbiq5DTw+wakjUIbnLkIu1R/+A26H+bLSfX I8iQ== X-Gm-Message-State: AOPr4FWeDphnRLNnahm1dlX1M9irYknNjEGMORoPMHtfXqzKczpAASc/ifpdVZCTal6S+Q== X-Received: by 10.129.27.6 with SMTP id b6mr11950584ywb.205.1460682312644; Thu, 14 Apr 2016 18:05:12 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id f129sm25379749ywd.10.2016.04.14.18.05.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 18:05:12 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Randy Bush'" References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <052101d196a8$85e90c90$91bb25b0$@gmail.com> In-Reply-To: Date: Thu, 14 Apr 2016 21:05:11 -0400 Message-ID: <052401d196b2$dc84a280$958de780$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK50UkYZgz1WOiK04JSUwHF5BdAuwJ4+ki0AigqhLYDB8zkQp18eJcA Content-Language: en-us Archived-At: Cc: 'sidr wg list' Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 01:13:34 -0000 > snmp, netconf, yang, ... heck even cops played in the space > > when your so-bgp, 15 years in the non-making, is mature as a document set, > with two or more implementations, i'll support it for standards track, no > problem. i am not desperate enough to sabatoge the work of others to > move my work forward. Wow -- care to prove that accusation? Or have we gotten to the point in the IETF where personal accusations are a normal, everyday, substitute for actual discussion? This sort of personal abuse is what turns people away from the IETF, and reduces our value as a community. This is just wrong, Randy, and you know it is. My point is simple -- the "no-one will use it" argument washes either way, so there needs to be some other grounds for deciding -- it's not a useful argument in either direction, honestly. Which throws us back to what "standards track" actually means. On that score, I'm not certain what the terms mean, so I asked for clarification on what the wording actually means. :-) Russ From nobody Thu Apr 14 20:18:05 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D1512DCCA for ; Thu, 14 Apr 2016 20:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 72D0f6gI4GBa for ; Thu, 14 Apr 2016 20:18:01 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 A05EC12DC6C for ; Thu, 14 Apr 2016 20:18:01 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id i84so124446201ywc.2 for ; Thu, 14 Apr 2016 20:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RnMhca8Lgx32cKNb6uMySxA1HquAR+VYdEexQdSnks8=; b=bYrU8tKL7lfeGURVTXE3Um4Jk06eEplgRnfcUyDF33JDt1L7W0TxizKj5LWZcoHOod s/bojNXHNCgp5MvsSkhai5XUyqreJcaNuoAmPISI/HBlLUmiqcii9pkf22RiEbiZXi81 0knViEWyj3Ob6viFZKodnenrJqokmyut8/yB4cJbw98FV5xF8qDqPImsTL9XJl5jU3a4 5kv7xVrpH+0XgGXOpJh/3u6Vko2PlK7bDpW3RqGeEph58GvVtl6egtG8IAupKXkPmdDL bMBeunyPSG4t1OwFBbfa/KmWzb64HPcJ2u6dEGtqIx38C6vV4nS3S1bnRlQ60D4j41iG xmaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RnMhca8Lgx32cKNb6uMySxA1HquAR+VYdEexQdSnks8=; b=CIQRll22yms2QUE+p5S8iPoZEn87Shz9OsTEhQvP8p9+xYSHoJpIXEtvPtJZE+ONUm 7iYd6jyzpqRnZt+d6e3YYX4owHMHmYwsiVDjctXCv2Bp06cIrbBS8Ru5N2l82OtF6i2G bJTfGjxe+5elwsh1HunjFvd1JZ4bTK5QCzfTMDmW/qM38dbpDpQ/VsJBAKeQo4XEFAvx ArkH5aO+Ozz1WwTl3UCKjBayF2zQ6ecMgOC7ghYKbMEt1uodRc0sf1HPN6xYccF0gM1R 0ijSWzOwbD5tTNof1xV137U2R3yBYWvIz92QTdbl3uuVLcrWtyWe3AZbhjO+bj5dL7zB 8/RQ== X-Gm-Message-State: AOPr4FVNvIuVfZk6X0tXZaJmzuoesg7IRNyJ5I0J4mkpdhRCGXkaQRflTG27MBVLIGUOgC2oYXOCO73oQ5HLjg== MIME-Version: 1.0 X-Received: by 10.129.130.196 with SMTP id s187mr10518243ywf.315.1460690280921; Thu, 14 Apr 2016 20:18:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Thu, 14 Apr 2016 20:18:00 -0700 (PDT) In-Reply-To: <052401d196b2$dc84a280$958de780$@gmail.com> References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <052101d196a8$85e90c90$91bb25b0$@gmail.com> <052401d196b2$dc84a280$958de780$@gmail.com> Date: Fri, 15 Apr 2016 00:18:00 -0300 X-Google-Sender-Auth: d7loRet9YnUFlFiyVDo6FqddMok Message-ID: From: Christopher Morrow To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=94eb2c07c18a52418c05307d75b1 Archived-At: Cc: sidr wg list Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:18:03 -0000 --94eb2c07c18a52418c05307d75b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2016 at 10:05 PM, Russ White <7riw77@gmail.com> wrote: > > > snmp, netconf, yang, ... heck even cops played in the space > > > > when your so-bgp, 15 years in the non-making, is mature as a document > set, > > with two or more implementations, i'll support it for standards track, = no > > problem. i am not desperate enough to sabatoge the work of others to > > move my work forward. > > Wow -- care to prove that accusation? Or have we gotten to the point in t= he > IETF where personal accusations are a normal, everyday, substitute for > actual discussion? This sort of personal abuse is what turns people away > from the IETF, and reduces our value as a community. This is just wrong, > Randy, and you know it is. > > =E2=80=8B=E2=80=8B =E2=80=8Bto be very clear, I don't think that rock tossing helps here.. in = fact I think it's distracting to the question asked. (original question I mean) let's not toss rocks please. (either of the 2 folk on To: nor other folk on the -list)=E2=80=8B =E2=80=8B=E2=80=8B > My point is simple -- the "no-one will use it" argument washes either way= , > so there needs to be some other grounds for deciding -- it's not a useful > argument in either direction, honestly. Which throws us back to what > "standards track" actually means. On that score, I'm not certain what the > terms mean, so I asked for clarification on what the wording actually > means. > > =E2=80=8BI don't know exactly either, but this from 2026: "=E2=80=8B A Proposed Standard specification is generally stable, has res= olved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances." doesn't: 1) say anything about the 'Final and Ultimate Solution' 2) that other work can't be done In fact the last sentence implies that more work could be done and that it's NOT the final solution. =E2=80=8Blet's please keep to the question. I do think discussion of this t= opic is interesting, to me at least, and useful for the group. My personal opinion is that PS seems like the right answer still, even after all these years. -chris =E2=80=8B --94eb2c07c18a52418c05307d75b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ap= r 14, 2016 at 10:05 PM, Russ White <7riw77@gmail.com> wrote:<= br>

> snmp, netconf, yang, ...=C2=A0 heck even cops played in the space
>
> when your so-bgp, 15 years in the non-making, is mature as a document = set,
> with two or more implementations, i'll support it for standards tr= ack, no
> problem.=C2=A0 i am not desperate enough to sabatoge the work of other= s to
> move my work forward.

Wow -- care to prove that accusation? Or have we gotten to the point= in the
IETF where personal accusations are a normal, everyday, substitute for
actual discussion? This sort of personal abuse is what turns people away from the IETF, and reduces our value as a community. This is just wrong, Randy, and you know it is.


=E2=80=8B<co-chair-hat>=E2=80=8B

=E2=80=8Bto be very= clear, I don't think that rock tossing helps here.. in fact I think it= 's distracting to the question asked. (original question I mean) let= 9;s not toss rocks please. (either of the 2 folk on To: nor other folk on t= he -list)=E2=80=8B
=E2=80=8B</hat>=E2=80=8B

=C2=A0
My point is simple -- the "no-one will use it" argument washes ei= ther way,
so there needs to be some other grounds for deciding -- it's not a usef= ul
argument in either direction, honestly. Which throws us back to what
"standards track" actually means. On that score, I'm not cert= ain what the
terms mean, so I asked for clarification on what the wording actually means= .


=E2=80=8BI don't know exactly either, but this from 20= 26:

"=E2=80=8B =C2=A0 A Proposed Standard specification is gene= rally stable, has resolved
=C2=A0 =C2=A0k= nown design choices, is believed to be well-understood, has received
<= div class=3D"gmail_default">=C2=A0 =C2=A0significant community review, and = appears to enjoy enough community
=C2=A0 = =C2=A0interest to be considered valuable.=C2=A0 However, further experience=
=C2=A0 =C2=A0might result in a change or= even retraction of the specification
=C2= =A0 =C2=A0before it advances."

<= /div>
doesn't:
=C2=A0 1) say anything ab= out the 'Final and Ultimate Solution'
=C2=A0 2) that other work can't be done
=C2=A0
In fact the last sentence = implies that more work could be done and that it's NOT the final soluti= on.

=E2=80=8Blet's please keep to the= question. I do think discussion of this topic is interesting, to me at lea= st, and useful for the group. My personal opinion is that PS seems like the= right answer still, even after all these years.

-chris
<co-chair>=E2=80=8B

--94eb2c07c18a52418c05307d75b1-- From nobody Thu Apr 14 20:56:25 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C164912DF42 for ; Thu, 14 Apr 2016 20:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 Yas7TMRl76yu for ; Thu, 14 Apr 2016 20:56:20 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D9212E11A for ; Thu, 14 Apr 2016 20:56:12 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by cyteen.hactrn.net (Postfix) with ESMTPS id DB039129A for ; Fri, 15 Apr 2016 03:55:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id B31A13E949BC for ; Thu, 14 Apr 2016 23:55:49 -0400 (EDT) Date: Thu, 14 Apr 2016 23:55:49 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <052101d196a8$85e90c90$91bb25b0$@gmail.com> <052401d196b2$dc84a280$958de780$@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160415035549.B31A13E949BC@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:56:23 -0000 At Fri, 15 Apr 2016 00:18:00 -0300, Christopher Morrow wrote: > > I don't know exactly either, but this from 2026: > > " A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances." > > doesn't: > 1) say anything about the 'Final and Ultimate Solution' > 2) that other work can't be done Exactly. Enough people seem to think this is a promising approach to merit PS status. The fact that there are also people who don't want to use it doesn't change that. Go for PS and move on. From nobody Fri Apr 15 03:22:52 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFF212E0FE for ; Fri, 15 Apr 2016 03:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01tpn_0L5qOW for ; Fri, 15 Apr 2016 03:22:48 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29EE12E0B8 for ; Fri, 15 Apr 2016 03:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tWTiINwTfUsxVmO90x4GtC6sGD/nsy3CjmZfdTT0Pf0=; b=FIYaIXHQWEzpkoY+NL54iCOMvOoUchw7r6OOf+NNSt091bqU2G/zkUtssK6TZrXRNJT3m3WOtfa0awl14xcmfl/93+wTZPYt0tklKKWI5v0DXSqfkNR9s02JWvlKesfK3+8/IlPKFHpLoxuX3PS2pbFNqtqbPfwb5UL9zWN2+c8= Authentication-Results: apnic.net; dkim=none (message not signed) header.d=none;apnic.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.171.1.17) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.466.12; Fri, 15 Apr 2016 10:22:27 +0000 Message-ID: <01f401d19700$4660d3c0$4001a8c0@gateway.2wire.net> From: t.petch To: Geoff Huston , sidr References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> Date: Fri, 15 Apr 2016 11:19:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.1.17] X-ClientProxiedBy: VI1PR05CA0023.eurprd05.prod.outlook.com (10.162.33.161) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: b8183b50-85c5-4d92-3147-08d36517d829 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:Ifta6v+FTw8ZyGAYNlGJ23j95Zdj7iRGggv5l6g3kRefVpM6P8zydtj7AJa2jjDrvf07rAewM3BZvGKe+tuJLWVNaupGOOP8URaYr5CmYVDpwvgqnrz5hBZiJ127KLlQYgmHAOSWvlwnKf412U6uSZ4yT7Mkz5mVoxfJRGcb8t2ixd5MNsZkYiBVfy6+bmTg; 3:9LNi6FFxGT4jX/diLKqNttcebwRtAJSHOQyKIx2ZNKp9IwZtD7GBlv6OQ/w2sGwQjgFcTYx1sIV2aJOZ6dfuEhpkNDs3pN2omgwARG9JSiaJoWuespw8vYne6R7zK6qG X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:SGwTHA9V9O0rClO8Iv4wMgwmiteHwIVdPb3b2d50x4mSs3eA0Ck1CsMYNajv6qFpZiW9pbBk/T3jyP8JBh/wLd8sZ3i97HEvNByw5mW36ZSDclH43WodGpN21O8WxY9mGvoosMVeUM0wO7jVE5f9gLmoS1uQxDK2glQSOXNKncU49gDmRenNTyhndaez0dIBRm5GC52AClHtw2Wvte1n5Zta/bfJDf+mKSC4DGajQhRPD4+fFWRgYNXFclvgEwNa91JSuWcywqJ2OzEG8Vypxd/VDauaDpestDbToSQAdSoSyXqT1QfrDurlymXi9b5pkrKsK+6ATmcLbk0GH8Tfhkr5Y27lX8KR3d5GCxXMF3ACMu7ywovvzZfqRw/prnIWqVTQfdXHFYvHW6baCpsCI+hF681FtU7WSZHWJzoF5vRve2NRgSNm8WwAkxzE9h0Kp1tBMu9Ufx5N+zFdQbWzuG8+giWFCG8UDFXMFjUF2W+IyZHuJxAit+gmz3DJjiXrATsj0hRyQZ0nWrNYht3PPT6ra8MuwehfIuBb+GmltPu5UO0GN1soatOTm/uc9RJ58BE3uBLaQuF4Fkqo5ZxkPF7G9mm71BCD42c6CKOLNaQItkj5M6hRRhHnCiVLnMdMeLCE7Iq8rXTROmkqhkeGIJ9tV+Z9eP2Tc5vf/Bz0vVK3NchK/uzxw5l7rr6TB5SxBkFyLoyktsphq2GEu5MRzfH+v6pWXlD4I1AuyVRZcCODDUf0W6cPTlikrtlHdxGI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:qnzgzAcDnaLeVIK4nXkM1B91s/II9z7Bar/m24d/CRhP98itNPnLYBX1mhPgwqEWTUtw0EyCh0CeNEs+MzDfE2g4o8Q/EGZYiOjuLI5nDna2bk/AMhj7MgI4TqtdZIv3LDICAQGeoBOQf+HtXOIMztcYRT7dZ/LRDhSyJSGoiOhMN0CszQ6xVUyh3DnvxMLmvBxj1V28SDOU6DOi4TVZCN4DneY7WDY6i4lOrmHph32NsrFNqAc6fVV1GhMZlB/2pwc60YJOZV+T1gMxIjrvgbv159Wpj2Uh8Bq2TRw6FPNjWtaZiZV/uiFCFnzijy2Az3UPpnt3Cz1pPFfIQVu9KAOOIE+o8vOJKT+pzeLo7pOk7ombQxhaPTc0Yev26h8HrLIxP/o9sIhnmw2rmqlsYg== X-Forefront-PRVS: 0913EA1D60 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(14496001)(2906002)(19580395003)(44716002)(62236002)(19580405001)(50226001)(33646002)(47776003)(1556002)(107886002)(586003)(44736004)(66066001)(5001770100001)(5008740100001)(97736004)(5820100001)(2870700001)(15975445007)(5004730100002)(23676002)(81816999)(1096002)(81686999)(6116002)(76176999)(3846002)(61296003)(189998001)(92566002)(42186005)(86362001)(50986999)(116806002)(50466002)(81166005)(84392002)(9686002)(1456003)(77096005)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOjNNYlNmdXJpS3lTQnpGWFRWbjdyYlFIT0py?= =?utf-8?B?bmlyYWpEME1qZ3VOZHV3dW9yMlY4MWFIZzFseExBcmw1NEFEY09kejNqVkpS?= =?utf-8?B?dEx3bktEOGc5ZkxTdFpiTFdWQ09GYVJUOGhqakQ2d0hMQWhLbUxuQ3BZMmRp?= =?utf-8?B?RTVmeGJPUE1FWjJ3RXJmVHUvYzVxUlVCcW0waFVCTlRQSFNhV2tNSXM5NkxC?= =?utf-8?B?U2JLMFhacW1wSVNhTE5xOWUyMW5tbmg3a3NhZVZVUVc2YzlEYkdONkMxTkZ3?= =?utf-8?B?by8xNGNmaEY1c0dxOUhXWmxldGdJQ0Y0SGdkdlpSd0FmNmdsKzk5TWtNcXhx?= =?utf-8?B?cU1YWDlzbDVZSnFCTURwcUF6UkFXMHBwU3FIOUVraFcwQmRXQ2UzeWk3TjZ2?= =?utf-8?B?eXFNRW5VcldrNUFsK3NQenJGUGJGM2M5WHhoWkl3bXkzdVF2N0dOZ3dPVjFm?= =?utf-8?B?TDlJYzlBNjRuQWk4RFQrT09sUklGUW51ZXJNQUJSWkVHRXhsZktrNjBXd2N0?= =?utf-8?B?RU9DM2hUUDNqVDVkL255dkFLTStPNmhzMHVCRW9ZZmZMTFNJampQRS9mMG01?= =?utf-8?B?aWlLd0lFeTJvdjN1TXlwV0FHeFh6bUFXZFNubFFTQXVzRk0wY0tnYUpxV0ph?= =?utf-8?B?VHJjQU9CdjFFSDNQQlNWRzRlUDJ4bEVQVE14USttSlV2bHJUUW9ZaEUxQklP?= =?utf-8?B?MFBrZm43eXlaeHBOUWZzQURRYi9kNGt0TXRhNWxkUEVjU2NmVjNnUlRkbVgx?= =?utf-8?B?QnZWNWlFK0JYd2dLS0lqUzVmeFRoRzJIZytpcC9PdGwvNWlDOXoyQVlSeGpw?= =?utf-8?B?Zm5kL3IzcHg3V0tMV2I5MEs3enlOVk1FTFFra1BleXdwb0wrcnpRQ2UxbWxH?= =?utf-8?B?Y1NlZVdTWFhRVzdHSWY0QjhqazhmMlloVTB0QnR6b2JSMExYZGRRaWZyekxy?= =?utf-8?B?MTJDVnV4UThIamNVR0Ewc3NKckZrNklnSSs3L3BqL1VvU0xYbUo4cWEwSGNJ?= =?utf-8?B?YzIyZUNtRlhRZ2V2alNMaUZmQXA4MUpheHFzMDlUcmJld3RERVpZQTJJYjVR?= =?utf-8?B?bkRQY05uQjBaL2RKTU1yRWhiR3kvSllmVzNjcEE5b3FXK2FhSlpVM2Z4bXo0?= =?utf-8?B?RnJ3d0Nhd3JEcm5xV2FTdC9kcC83TkEzYnlGMUVScm5wS2h1UXVZVGZQYys2?= =?utf-8?B?c1BjUG1rR1o1dDdqTUhWQ05rVjhhb1dkS2tPSXFEVFMxVjF4MG5IUGpreUNa?= =?utf-8?B?cmp3KzZNdHN2N0VJU3poQVJ1MVMzaDA3a2JqRnU3enJXS1F3cThSS0VsaGtP?= =?utf-8?B?RVhXT0hmbTgydUx3TG9qZjlTUzd6WGk4dVR4ODFNYTRURk5MY2Qra1ZlSGpp?= =?utf-8?B?RWNhcStkYVY4KzY5Mkw1Q1BIK2tLZ29XYUhad2oveVhCYnhQK0pvNWJoZzdt?= =?utf-8?B?ZW85K1hycmhHdkowWSt3dTB4NGFJaEMwcldVZThZQnpjTEJFdjFScXlBd2x2?= =?utf-8?B?SnBkRnBOMkVVRlhCYTh6bUVwUDM4ZHZ2eVFEdnQyM2RIUzBhSDBSd3Rpc1lK?= =?utf-8?B?cTJvMkJMbEJvZjZEZkhMVnVreGNrMWZ0ZFowK1dzSW5yeGxUU2tIcTZhenZY?= =?utf-8?B?OFhxUVFxOENkVytGQzRxVTJjYXloTDJhdStPMkwvU2FwZE1jNEdIUDNvaDFC?= =?utf-8?Q?8SA+bZ6JAS+wxqSqoh3Mfh0QLEVWS26G67bkXBn?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 5:GsTC5uvZu1OcOlkOseFYfuFjBNG4iZ5OzUB4g/pWOUYZnlx4NuZYsKKTxaycvCYDHX7rYFBLU9eLAFhw3e0wfP1aZjVqzUy5vciKzYsm/ejq3TOot7CYHnu0SLn3bSVetpLyLFQwdfyrlQ0I4Q7tiEL74jUl3dcLwyhwcRWN5rSqfBKD4TVnsykr55mVhREC; 24:BlICf+mbnIQthFRBkJ0RGaKlKAbBUlJNsWobfj7pVC0KKuvBQOxH9IU1pACiZYdbclRsLoZxTIb4ozWEMNtBZeCfivMSiC8/ntqYbgTT8Hc=; 7:4jQSep/TN6fk+0RaEKp6vOGtCmYzZZQoycL1uIhF9s+QJExppZwsPWZxMCuKKs9vrFZOCuZT+ADlaLqW8B7X4YL7651xtTg/LzM1VJQdrajmJj/K6BY0OMmNuhhe7up8KKO2mc7Mw/Cyj11kGdBhc1udYeKo9NAts5lteCymsIEJn4DYUWZiYpXxXn0AGPIP4QS2h2EYS++L48EVZt3+6z7K3ft2JHcUHyIhYPOZcTU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2016 10:22:27.0853 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 10:22:51 -0000 ----- Original Message ----- From: "Geoff Huston" To: "sidr" Sent: Thursday, April 14, 2016 9:20 PM > > On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: > > I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR session, at > > which the issue was raised as to whether the BGPSec RFC should be standards track > > or experimental. > > I was in the room, but did not speak to this topic. > > > I believe standards track is the right approach here. > > I consulted the oracle of RFC2026 and read the following: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > This seems to fit well, including the caveats at the end. Geoff I agree that Proposed Standard is the right, the obvious choice, but in another context, it might matter that the oracle is dead, buried by RFC7127 " A Proposed Standard specification is stable, has resolved known design choices, has received significant community review, and appears to enjoy enough community interest to be considered valuable. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard will have no known technical omissions with respect to the requirements placed upon it. Proposed Standards are of such quality that implementations can be deployed in the Internet. However, as with all technical specifications, Proposed Standards may be revised if problems are found or better solutions are identified, when experiences with deploying implementations of such technologies at scale is gathered. " which I find a somewhat looser requirement and so unlikely to affect the outcome of this discussion. Tom Petch > > On the other hand: > > The "Experimental" designation typically denotes a specification that > is part of some research or development effort. Such a specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). > > Which seems to fall short. > > The exercise of RFC publication of BGPSec is more than archival, and the process > has been much more than a cursory exercise of coordination with the SIDR WG. While > BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow’s Internet, that > future uncertainty applies to most of the IETF’s work, and that consideration > should not preclude its publication as a Proposed Standard, as I interpret RFC2026. > > Geoff > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Fri Apr 15 10:31:14 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F3212E866; Fri, 15 Apr 2016 10:31:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415173109.17554.71928.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 10:31:09 -0700 Archived-At: Subject: [sidr] The SIDR WG has placed draft-kent-sidr-adverse-actions in state "Call For Adoption By WG Issued" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:31:10 -0000 The SIDR WG has placed draft-kent-sidr-adverse-actions in state Call For Adoption By WG Issued (entered by Sandra Murphy) The document is available at https://datatracker.ietf.org/doc/draft-kent-sidr-adverse-actions/ Comment: Call was started 11 Mar 2016 https://mailarchive.ietf.org/arch/msg/sidr/HoJ1pvn2VmxAsRRsE_Bk-RVVlyU From nobody Fri Apr 15 10:33:28 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF40812E888 for ; Fri, 15 Apr 2016 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 0rYvhGv6K4mu for ; Fri, 15 Apr 2016 10:33:24 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2D512E86F for ; Fri, 15 Apr 2016 10:33:24 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DE01928B006F for ; Fri, 15 Apr 2016 13:33:23 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D735F1F801E; Fri, 15 Apr 2016 13:33:23 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8426103A-71D2-49E4-BBCD-5F1936E8081A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy Date: Fri, 15 Apr 2016 13:33:02 -0400 Message-Id: <739BE294-7855-4E50-9357-1AA209EB36EF@tislabs.com> References: <002885DC-BD79-47C4-A069-7F86269549B6@tislabs.com> To: sidr X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] Fwd: adoption call for draft-kent-sidr-adverse-actions-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:33:26 -0000 --Apple-Mail=_8426103A-71D2-49E4-BBCD-5F1936E8081A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb18030 There was considerable support for adoption of this draft as a wg work = item. The authors have submitted the draft as a working group work item, on = the basis of wg chair discussion. This message formally notes the results of the adoption call for the = mailing list. =A1=AASandy, speaking as one of the wg co-chairs Begin forwarded message: > From: Sandra Murphy > Subject: [sidr] adoption call for draft-kent-sidr-adverse-actions-02 > Date: March 11, 2016 at 12:05:42 PM EST > To: sidr > Cc: Sandra Murphy >=20 > This starts an adoption call for draft-kent-sidr-adverse-actions-02. >=20 > Please respond on the list if you believe the working group should = adopt this draft as a work item. The adoption call will end 25 Mar = 2016. >=20 > Remember that positive support is needed for adoption. Please state = whether you believe the work should be adopted and whether you will = review and comment on the work. >=20 > The draft is available at = https://tools.ietf.org/html/draft-kent-sidr-adverse-actions-02 >=20 > =A1=AASandy, speaking as one of the wg co-chairs >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_8426103A-71D2-49E4-BBCD-5F1936E8081A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXESXgAAoJEHplpQeet0IZI/AP/jw18IY4dPPRoqnW0lOJLoBQ yx5I4ttLR91pLnVRrlecVS52GN5C1npppm9xtAH2Fhl5cWYy0+PjEslY5No+vJA+ Bs9Dz4W02PkZwffJAYb9gNO1MEuDbyhWRitlf71hPNvt7h9jwGn+tp4RnG7znA7h gBg9wZPd4o/jbeFyficGnRo8OHra5i6mPuwDth35gL5CA78iZAjwN6aLE/suxM00 a99J3QhibBJleyBv0sops6ZagKcB9QgWo/OAaCxBYSXblzj6ilXnItFO2XfuZnBx caxN+z2CCI2YEt+7QqnH4TvSzbrpbOpt0vxPE4XOq8BgYv76ebaDGOnk74YvmEzH aM8+NZ2b1iVdJCUmAbpE2Nf4rEvvaiu8eHKv3WN04fi8QLCegjMgiqCAa8Odrk5l RbT9JteCF/p6vNcFleAQ9BIzgBP9gUtzTjHSm3lGLe/TZsxBFyHuuEsygoQ5TvkM sAc931TGLGjrdDH+KfgPCGGCX9QLKb1kaicJiJfV3lvMPVmrYa/X5avAAN3k2Ia7 4z5fVr2B/5rntYEJoIeotYZi7aKiPosVSbjeg88EAn/h7W+v5EG5b+jbKy1cpA4L 7kw0Hbs/FDznVo1nV0IMCNzeNmpqUOt+4hbEgCQFDznh+5K4dzvt0iqEuzgWsHJu PFaZ/+UMMLM68ifk1By1 =FrjK -----END PGP SIGNATURE----- --Apple-Mail=_8426103A-71D2-49E4-BBCD-5F1936E8081A-- From nobody Fri Apr 15 11:10:08 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2551412D6FF for ; Fri, 15 Apr 2016 11:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhQuwg_-1Iud for ; Fri, 15 Apr 2016 11:10:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3147812D6B1 for ; Fri, 15 Apr 2016 11:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QxEDfUNFYuOxAkyxPlUEcDrG9Bwm66+xS5bH5dasdKg=; b=ciwUp5Q7dA+dmfMicbxNJXLTYqRTc7XoZO7EcSMGQV/eOBLzbjAUZrjc7lLolsz2a1zh154xIngmf8FYfPsyUFPPeW9W0zq6jsfIx4x4Ad5VajuRYyco7v7gp+dyWdGynXKsf3COcHUaTmCLd9w3UNFWhdUzxQrf0P3KsAxJ7ds= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.115] (66.129.241.11) by BLUPR05MB198.namprd05.prod.outlook.com (10.255.191.12) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 18:10:03 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <570E8D44.1080208@bbn.com> Date: Fri, 15 Apr 2016 14:09:58 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <723CA032-880C-4B37-A8EC-35D67964BFDC@juniper.net> References: <570E8D44.1080208@bbn.com> To: sidr X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BLUPR19CA0021.namprd19.prod.outlook.com (10.162.230.159) To BLUPR05MB198.namprd05.prod.outlook.com (10.255.191.12) X-MS-Office365-Filtering-Correlation-Id: 6faa4ee7-afb1-49c0-28ab-08d365592b39 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB198; 2:1+X083LnyekC5H/HM33z6sPJmMnuqwcAn3m8Ap//1xF4oBXW4wROG9ZD9RzvWKoMFJjtBlENtqceLUwl617+b4K2QIuCH0fUQIPYhZX8xuNX4owJuxKja9bfcvEEInRfpDaqSyKJJuRLNAHjNCqFUSodd0dGHJPMK6kl59mGBQ0JR8siAKIeV+UVCoGwvT+o; 3:X54ha6ERUcvPjHgqy4WOztlKovNymXcy9PiULs3doLMCaIZvIYKk6K0vHp0jUu2hr2IxR0LO7uns2/LpSUPPGBRsW+w5/UGd3ZHu6M4zEJDWt0h9lgVaZonFXuntTNGX; 25:oAd28FCuvjsp+MqRKiNv9nidUTU77ez0Y5K/pk7mkPZzPjSBz8q9rmxcy0lK3nWQIaIjzSkaFKAj71OdejN10FJQOpBM4IsNi4dtiin5fEQDVueUigco7LG8xAyL2I8sH2bnizoeBoOda3zNkMfBueYW5GfymLvW9EzwZKzeuI6C+EkdWon/ETPN9xB6CFmbVilYW4EaBpaDKvzWV3pGEC1L2b75FMbNaRAtKZgFwZX26TDhPm4q8BdY4/b36JSFiDs0VvJdmJMnyK4IMhWI5JS1cbUn9JcU7NFOKoR6qYwZsLz2zUfgz24NOJ+alwSCBNjQBs5yzD9eSeP79S893w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB198; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB198; 20:yuRP1q0iQObvlU5a5Al3A564lfdHbx3Jy2KVm983vNdoL2b91BAEDUBElsvGkS1ROb/SNzr7jXLkVxin2vovcgBdVIopvew6TIeK+irw1M7hGBsNz9qNXEbqzV1bsH2Zfl4WqoovPOIUHu6bOY84oFG9SNgK5FmSjMI5C3o8aK/etXqRGKeJQP8xNyPM8Hb4dYTkWCISn8LV4Uuzst5f2/VY5s/wI//YGrp4Fcwr1WDlAmOwtPtefJ1IlC9PfgxNO5gcghFxfyNHfhM0DgrJX/vEp/B/PSp+VHRwFuS8QGuMdZ1we/6BF0YBuF+HsjJnc+gKIuCXkfV9DTI95kRTeddKculz0D1RKBPs55Jw9mXF3BglHhglcXKrTgoTsZ9u7WdbWRHkooWm7G3PdTYUsBN5M59vY0BwWM0dbcfumi+zJiCrb8ZkAbVOuRQ233PcYxZCeYaAOHFJSfmxNm6bNuWOY7Zdys+0EWjN4Chqa6FUwf0PQd/GHygbTM1jM9ji; 4:u1isXwPjB4K5wlUlxNscufGDCl/51PGO2q4izTaCCSCyrV9o9UHllo0BN/SZxZHVSXuN6lwA9q2C21TCYTaFj8NLd5l6Fy1Zfwl9wGJaVc466VQWf16A0YPZOIqp+N1NPe2o/8H7cMKwlZkCD89+d1IDOLz60SMHnsuU/6yxSAHg4aUzPB05ornDFF5gYrC5pw4vQVptwURXdWN1X4ueIY42PfL7smdzLzlsaysASGOXcvAd0qgU1j3Ip69/EPzemtY+pmLOacMreZfJfIPPBGzjgcb7/7KMzmuWzP1VCYH06PVmT4D3ehxGMpl7IvRhICLMEVWA7BZEQankNEcymY5P1cCKAuRhf4Uy6LxPTDezCRQlfMyjbksDu4jgbLmV2oYwZgGlIsWbTzX2l6+u0T2XCzjs2WmFodZ/ikLgJzg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BLUPR05MB198; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB198; X-Forefront-PRVS: 0913EA1D60 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(377454003)(1096002)(189998001)(5004730100002)(19580395003)(19580405001)(47776003)(81166005)(23726003)(36756003)(42186005)(66066001)(86362001)(586003)(33656002)(57306001)(6116002)(3846002)(107886002)(97756001)(110136002)(2950100001)(50226001)(82746002)(450100001)(50466002)(77096005)(50986999)(2906002)(5008740100001)(92566002)(76176999)(46406003)(83716003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB198; H:[172.29.35.115]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB198; 23:Zw04aifeHRFTvy0CmWDmyzJO0O83QjQhTntwHMr36b?= =?us-ascii?Q?C8384obJrRCrpZsDUeJ12QMy7iDXV6amEMTtYiqNDuoIUQP/0X9Rl251MYWq?= =?us-ascii?Q?I0Kthz17Z8U0bpUjMSXE8Kcsffj7CZBAxCpI/7IeTcjpEhrb3RDV4jix9oPH?= =?us-ascii?Q?2Gi/sfKk6GgSMYetM4CSMacYn78q8PkFqtZnQcCeqfmoOS3QWi2tBcviuWgR?= =?us-ascii?Q?VZ+4+CLMdVnG/2JUxyhJ9abaIW+IOa3Qd4weIriBGzJWo51lXd0EIFJaZ8mh?= =?us-ascii?Q?3k0XvkValospvhdgaDgfb5KPwN9mder7xZEjVjRYp13pE8zfDK14ekDeNJ5K?= =?us-ascii?Q?b9b+Oqf56IO8CiiuxxKOuUJHI1uCF4cB2lu91ToSC3CC2JIRXLZzIpo4ep15?= =?us-ascii?Q?ZnMlq5Wtw6SOfFOoZrPMoqsD2VUo3FQ6Yf/hFa+951wDv8FQWBA32NdNbWqX?= =?us-ascii?Q?VMDitMPxRAEQnq8/Az4Q75W9Xfx5qr7V1d0TrzfqjF14AwOV5Kj91NwQhiyc?= =?us-ascii?Q?22sobCAok8N0CYThE70kIwscIuKBdRdLlNZkkdL4yncD+wULxBQdm4IshDrV?= =?us-ascii?Q?vqP4SsdqhoiYNnUwhoM6F1TPpR6EoLBl9HJkMhhcK9PfnoXpwyFzAXlcbb67?= =?us-ascii?Q?dT70v8YK2vITIWXLxbcxyQ+YWq0MV8nm29VTA1B0c7MunSf7QZHC8HyNx1y8?= =?us-ascii?Q?qz2H4axk7gyZBKSqnJ8nZ4uMtVxSBSGYPTlJseuwBHOt6hkRJR3m9ZipOyPH?= =?us-ascii?Q?e4XlNf9DNg4t7a+KUP8nsUID8EWrP0haPyaB5mpIMpm0Ly3yc2E/mifAg9b8?= =?us-ascii?Q?38u+y2jdzZfzIYrIzDTnRJK2LXyOmmtBw3DKSUGb2W6/EgT/lCJLthsM8KLR?= =?us-ascii?Q?JnojqmT4mONq7tQ/UdrnSFimja7opUaCxQI762gRNTgGYhgnpFocOvKUv9cT?= =?us-ascii?Q?Rhfyz0BRBGD76qVYa4m1O+83EaTcpbZWKKnhwbHRMUWFBWUoTs6Qx9vJHTls?= =?us-ascii?Q?vGrvqfTLGlsHT62Aubi8hnRoF7Cpk52yaJ3MF6JiS/kQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB198; 5:KiaFJo70gz0uQrbwqhWl5ZnKgvI6EqVmzGJ5/T+ovbLauOEK40+yCEFVIxAhy6qIUlxGfzAhCjCkXEwToo9y7RTm6ht2W68HfIWsWs5WeB88OHtFkGyOHmUhv1ZFHzlT/OXaQep6M+KltcQbX/NsZw==; 24:n2TUKIStgpVkfSMMMjDS4l/x4mHruW6Ck3/mVxTfVM9b2BUjE18iQjcVHaEALx384hO/KUWAalABT5X5mhnqJifHnVhjcq2b8dszngmEnxw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2016 18:10:03.9316 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB198 Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 18:10:07 -0000 All, Thanks to Geoff and Tom for pointing out that we do have definitions of = what PS and Experimental mean. If those definitions are wrong (c.f. some = of the comments relating to whether some designation does or doesn't = advance some greater good or agenda) is not a question for SIDR to = decide -- if you don't like the definitions, propose revisions to RFCs = 7127 and/or 2026. Based on the definitions provided in those two RFCs, BGPSEC fits into = the PS bucket. If there is debate about whether it falls short of any of = the RFC 7127 criteria for PS, the best time to have raised that would = have been at WGLC but of course there's still IESG review and IETF LC, = so there's ample time for anyone who wants to be heard.=20 $0.02 from this individual WG member, --John > On Apr 13, 2016, at 2:17 PM, Stephen Kent wrote: >=20 > I didn't attend the IETF meeting, but I did listen to the Wednesday = SIDR session, at > which the issue was raised as to whether the BGPSec RFC should be = standards track > or experimental. >=20 > I believe standards track is the right approach here. This document = has been > viewed as standards track since we began work on it long ago. It is = the successor > to the origin validation standards, addressing the residual = vulnerabilities that > persist based on that use of the RPKI. =46rom the perspective of = promoting adoption > it is critical that this remain a standards track document; router = vendors will > be unlikely to devote resources to design and implementation if BGPsec = is labeled > experimental. I agree that this is new technology, but I heard that we = already have > a couple of implementations already, and we may discourage others = from continuing to > work on BGPSec implementations if we downgrade the status of the RFC. = The design has > evolved to accommodate real-world routing deployment topics such as = the role of IXPs > and AS migration. In my long experience in the IETF experience, the = level of attention > to these an analogous details makes BGPsec a very solid candidate for = standards track > publication. >=20 > Steve From nobody Fri Apr 15 15:33:07 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0A12E259; Fri, 15 Apr 2016 15:33:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415223303.17550.46282.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 15:33:03 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-adverse-actions-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 22:33:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) Authors : Stephen Kent Di Ma Filename : draft-ietf-sidr-adverse-actions-00.txt Pages : 25 Date : 2016-04-13 Abstract: This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is performed from the perspective of an affected INR holder. The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 17 09:35:21 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9012DA8B for ; Sun, 17 Apr 2016 09:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 aS0DhgPPvVSd for ; Sun, 17 Apr 2016 09:35:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 3A35712DA0D for ; Sun, 17 Apr 2016 09:35:18 -0700 (PDT) Received: from [IPv6:2601:647:4204:51:8864:8274:5c2b:a9ec] ([IPv6:2601:647:4204:51:8864:8274:5c2b:a9ec]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u3HGZGwf004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Apr 2016 16:35:17 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (13E238) In-Reply-To: <723CA032-880C-4B37-A8EC-35D67964BFDC@juniper.net> Date: Sun, 17 Apr 2016 09:35:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42592C0A-B1A1-4992-8476-724FF26768A3@bogus.com> References: <570E8D44.1080208@bbn.com> <723CA032-880C-4B37-A8EC-35D67964BFDC@juniper.net> To: "John G. Scudder" Archived-At: Cc: sidr Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 16:35:20 -0000 > On Apr 15, 2016, at 11:09, John G. Scudder wrote: >=20 > All, >=20 > Thanks to Geoff and Tom for pointing out that we do have definitions of wh= at PS and Experimental mean. If those definitions are wrong (c.f. some of th= e comments relating to whether some designation does or doesn't advance some= greater good or agenda) is not a question for SIDR to decide -- if you don'= t like the definitions, propose revisions to RFCs 7127 and/or 2026. >=20 > Based on the definitions provided in those two RFCs, BGPSEC fits into the P= S bucket. If there is debate about whether it falls short of any of the RFC 7= 127 criteria for PS, the best time to have raised that would have been at WG= LC but of course there's still IESG review and IETF LC, so there's ample tim= e for anyone who wants to be heard.=20 Not liking something very much is not a great basis for experimental status v= s ps as opposed to yes vs not at this time. IMHO when we look at BGPSec we'= ve go to ascertain whether we can live with the consequences of various acto= rs outside the IETF participants deciding it's cooked enough to deploy, use,= require and so on.=20 =46rom my vantage point it's about time, not because we're done, but the doc= uments are not going to get much more cooked, we've accumulated significant i= nfrastructure around it, and the marketplace needs to have as say on deploym= ent and this is how we signal that. > $0.02 from this individual WG member, >=20 > --John >=20 >> On Apr 13, 2016, at 2:17 PM, Stephen Kent wrote: >>=20 >> I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR s= ession, at >> which the issue was raised as to whether the BGPSec RFC should be standar= ds track >> or experimental. >>=20 >> I believe standards track is the right approach here. This document has b= een >> viewed as standards track since we began work on it long ago. It is the s= uccessor >> to the origin validation standards, addressing the residual vulnerabiliti= es that >> persist based on that use of the RPKI. =46rom the perspective of promotin= g adoption >> it is critical that this remain a standards track document; router vendor= s will >> be unlikely to devote resources to design and implementation if BGPsec is= labeled >> experimental. I agree that this is new technology, but I heard that we al= ready have >> a couple of implementations already, and we may discourage others from c= ontinuing to >> work on BGPSec implementations if we downgrade the status of the RFC. The= design has >> evolved to accommodate real-world routing deployment topics such as the r= ole of IXPs >> and AS migration. In my long experience in the IETF experience, the level= of attention >> to these an analogous details makes BGPsec a very solid candidate for sta= ndards track >> publication. >>=20 >> Steve >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Mon Apr 18 14:11:20 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 110E712E802; Mon, 18 Apr 2016 14:11:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160418211119.11079.58462.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 14:11:19 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 21:11:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPSec Considerations for AS Migration Authors : Wesley George Sandy Murphy Filename : draft-ietf-sidr-as-migration-05.txt Pages : 15 Date : 2016-04-18 Abstract: This document discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-as-migration-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 15:31:38 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64E12E7A1 for ; Tue, 19 Apr 2016 15:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 jo4cxSVwPx-X for ; Tue, 19 Apr 2016 15:31:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEF112E744 for ; Tue, 19 Apr 2016 15:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2364; q=dns/txt; s=iport; t=1461105094; x=1462314694; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BvnZGD+5HODWqTyGm3ar4enmGeewRc6gHrTMrCArZMA=; b=e2MaPCaYKXx0RlyxVpGAjdO59oOQnVO5DJDKOm/2vpFqx7bnbkJZ/IVH ERYsZWvS5flekDr2A4S4YByYGIcxfmn/C/8w/l+9/epaih45XJ9LmaHfZ b3o5+8sNPQAzIpzJkw3CglMLgf6F80KqWIQoM9k2unD2jhvluAGRFE95p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgCdsRZX/4UNJK1egzhTfQa5cAENg?= =?us-ascii?q?XEXC4VnAQIBAQKBSzgUAQEBAQEBAWUnhEEBAQEDAQEBAWsbAgEIGC4nCyUCBBM?= =?us-ascii?q?UiA0IDr1fAQEBAQEBAQECAQEBAQEBAQEUBIYhhEuKFQWOC4oDAY4RgWaHd4Uzj?= =?us-ascii?q?yoBHgEBQoIEGoFKbIgVfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,507,1454976000"; d="scan'208";a="99118796" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2016 22:31:23 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3JMVNZs024672 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Apr 2016 22:31:23 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 18:31:22 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1104.009; Tue, 19 Apr 2016 18:31:22 -0400 From: "Roque Gagliano (rogaglia)" To: sidr Thread-Topic: [sidr] BGPSec RFC status Thread-Index: AQHRmoszlHYu8eSboE2+sKRlZsym3A== Date: Tue, 19 Apr 2016 22:31:22 +0000 Message-ID: References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> In-Reply-To: <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.246.207] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F2A0928AA2E1E48A35576C2B3F76012@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 22:31:36 -0000 +1 with Standard Track. The question could have been relevant six years ago and we may not have debated it that much then. Today, we are clearly beyond experimental draft definition and we do not want to stop people working on the topic. Roque On 14/04/16 22:20, "sidr on behalf of Geoff Huston" wrote: > >> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: >>=20 >> I didn't attend the IETF meeting, but I did listen to the Wednesday >>SIDR session, at >> which the issue was raised as to whether the BGPSec RFC should be >>standards track >> or experimental. >>=20 > >I was in the room, but did not speak to this topic. > >> I believe standards track is the right approach here. > >I consulted the oracle of RFC2026 and read the following: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > >This seems to fit well, including the caveats at the end. > >On the other hand: > > The "Experimental" designation typically denotes a specification that > is part of some research or development effort. Such a specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). > >Which seems to fall short. > >The exercise of RFC publication of BGPSec is more than archival, and the >process >has been much more than a cursory exercise of coordination with the SIDR >WG. While >BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=B9s >Internet, that >future uncertainty applies to most of the IETF=B9s work, and that >consideration=20 >should not preclude its publication as a Proposed Standard, as I >interpret RFC2026. > >Geoff > > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Apr 20 01:07:31 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E91212E866 for ; Wed, 20 Apr 2016 01:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jZyqQQhcUlC for ; Wed, 20 Apr 2016 01:07:29 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 BA27812E0FA for ; Wed, 20 Apr 2016 01:01:21 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1asn4X-0003cG-WB; Wed, 20 Apr 2016 10:01:20 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-197.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1asn4X-0004rt-Qn; Wed, 20 Apr 2016 10:01:17 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=iso-8859-1 From: Tim Bruijnzeels In-Reply-To: Date: Wed, 20 Apr 2016 10:01:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.3112) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719ed4ad4a9353f674b6791de494c620dc4 Archived-At: Cc: sidr Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:07:30 -0000 > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) = wrote: >=20 > +1 with Standard Track. +1 >=20 > The question could have been relevant six years ago and we may not = have > debated it that much then. Today, we are clearly beyond experimental = draft > definition and we do not want to stop people working on the topic. >=20 > Roque >=20 >=20 >=20 > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" = on behalf of gih@apnic.net> wrote: >=20 >>=20 >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: >>>=20 >>> I didn't attend the IETF meeting, but I did listen to the Wednesday >>> SIDR session, at >>> which the issue was raised as to whether the BGPSec RFC should be >>> standards track >>> or experimental. >>>=20 >>=20 >> I was in the room, but did not speak to this topic. >>=20 >>> I believe standards track is the right approach here. >>=20 >> I consulted the oracle of RFC2026 and read the following: >>=20 >> A Proposed Standard specification is generally stable, has resolved >> known design choices, is believed to be well-understood, has = received >> significant community review, and appears to enjoy enough community >> interest to be considered valuable. However, further experience >> might result in a change or even retraction of the specification >> before it advances. >>=20 >> This seems to fit well, including the caveats at the end. >>=20 >> On the other hand: >>=20 >> The "Experimental" designation typically denotes a specification that >> is part of some research or development effort. Such a = specification >> is published for the general information of the Internet technical >> community and as an archival record of the work, subject only to >> editorial considerations and to verification that there has been >> adequate coordination with the standards process (see below). >>=20 >> Which seems to fall short. >>=20 >> The exercise of RFC publication of BGPSec is more than archival, and = the >> process >> has been much more than a cursory exercise of coordination with the = SIDR >> WG. While >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=B9s >> Internet, that >> future uncertainty applies to most of the IETF=B9s work, and that >> consideration=20 >> should not preclude its publication as a Proposed Standard, as I >> interpret RFC2026. >>=20 >> Geoff >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 21 08:26:49 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D5012EB55 for ; Thu, 21 Apr 2016 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 kMkcs8z873dq for ; Thu, 21 Apr 2016 08:26:46 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77CA12EB36 for ; Thu, 21 Apr 2016 08:26:45 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 559C328B00B9 for ; Thu, 21 Apr 2016 11:26:44 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4FD381F801E; Thu, 21 Apr 2016 11:26:44 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_01C32D02-5860-42AB-B7D5-CFDC67DEAD92"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <1C34B13A-A444-4EB5-A1A9-7933E67992FA@tislabs.com> Date: Thu, 21 Apr 2016 11:26:38 -0400 Message-Id: <14815801-1BD6-4773-B27C-2CF407E04745@tislabs.com> References: <1C34B13A-A444-4EB5-A1A9-7933E67992FA@tislabs.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:26:47 -0000 --Apple-Mail=_01C32D02-5860-42AB-B7D5-CFDC67DEAD92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This wglc ended a very long time ago. The chairs believe that the wg consensus supports publication of this = draft. The draft was waiting for the draft-ietf-sidr-rfc6485bis draft, which it = updates. Unfortunately, this draft uses the same language in the Additional = Requirements section that draft-ietf-sidr-rfc6485bis used. Now that the = wg has reached consensus on new text for that section, the draft authors = are directed to change the Additional Requirements section to the = language used in draft-ietf-sidr-rfc6485bis. The draft authors are also reminded of the agreement to revise text in = the IANA registry section (see message = https://mailarchive.ietf.org/arch/msg/sidr/ArfOCMbpG0X9JGDFH2d6StBSBLs). When a new version is posted, the wg chairs can request publication. =97Sandy, speaking as one of the wg co-chairs On Oct 16, 2015, at 6:47 PM, Sandra Murphy wrote: > The chairs and the authors believe that draft-ietf-sidr-bgpsec-algs-11 = is mature and has stabilized. >=20 > This message starts a WGLC for draft-ietf-sidr-bgpsec-algs-11, which = will end 30-October-2015. >=20 > Please review the draft and send comments to the list, and say whether = you believe it is ready for publication. >=20 > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs >=20 > BGPsec Algorithms, Key Formats, & Signature Formats >=20 > Abstract >=20 > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format = used > in BGPsec (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >=20 > =97Sandy, speaking as one of the wg co-chairs >=20 >=20 >=20 --Apple-Mail=_01C32D02-5860-42AB-B7D5-CFDC67DEAD92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXGPE0AAoJEHplpQeet0IZXbcQAJ7N/zc2dsrddCDxmult+KzI Gr9YYuJeItIs6go1gH9JHwVhR0+Fcd3X9qMAlzgbAk0VmREr6hLFCowJb+3ln3Nw MhMjRxJldDI/9JNV1uGA0VwmB65vF811zZCQCgkIVwMKMy0+lHkKyi5zOzttLQPq ghC+TZzv96jFOTXK+h3wjaqnHjUqe2mK6Rq+gbHlNloJkLmbnaLr4Osw7ryfF5V/ Muo7tFmrmUEfPPlvaqtuqtBVsGN/5ThfrtJ2Y45PchUSJPdNCF+vjrBC7NGi6Xz5 vhsHQQVdnvq51WyRNjPu9y3ruypc35YRo58uQwRfWmE9rv+e95esowrpYNseVwT3 o0wIziPzuWR9RZ4XzP6ymCZCNogLOstN4P/ux0KBhdZ+vfPZUdMmRNa3TZa+2WyJ yyujdrP2NTO0Uo9mN6Wl8E50l141Z3WJc6yi9UC7u4AMpjQPyFBVQxzw19fK/qXa pIxtUtkomlBGHct2/JJpv7CQ6oYxwfFMtHyXYPE96ga/3oSHm4rFHqkz+8fXiSEX P3bXMoLEJKBBAXY2fGAO8hl/Ejj5S2p4Fak6FJ3MctCkXXBpSbzufjOAb7LfINLc HfyJjqabwRgBRWj3Q4U4hRlt5ppwr/mi8gxFsXMaTOTVVc5UGYlfjM9FBmvhOoYg spRlD9FF6/nQh1ELtXkP =Yyyb -----END PGP SIGNATURE----- --Apple-Mail=_01C32D02-5860-42AB-B7D5-CFDC67DEAD92-- From nobody Thu Apr 21 08:40:15 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EC612EC5E for ; Thu, 21 Apr 2016 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 USQEEgjlNxcG for ; Thu, 21 Apr 2016 08:40:12 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 CAA2B12EC2C for ; Thu, 21 Apr 2016 08:40:11 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id d90so16162947qgd.3 for ; Thu, 21 Apr 2016 08:40:11 -0700 (PDT) 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=sH636bxdxnOK6aovROikxyIPyA5RA9XbheGl/BOIL1U=; b=Rd5Fll+0sVmKv4MT9r4nLgFBjz6U0lD4l4Nnt91Z6NNKG8Z3p69j99jH9fTUuYZkoo W4L8blCAyQUjfIVKG/uixobuIVUD2BW4u2aYix/XywSCUUZ1WrJIiT2QFE1lnGvYnXJq p47ApF57yI5F1x241W1dZLWuVDc/4ANFlu45Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sH636bxdxnOK6aovROikxyIPyA5RA9XbheGl/BOIL1U=; b=Gzvf5M03XYzjxXzXAwnfSHb7MtSSYRotKrFEbAgbSd5066tk4/VuVEnIw6nrNIhU0C eBCUQa2sWUDTNoX7FYMfmPql9q+JpAEgu1MM+BjgPiU+286NikjU83azXnomp2gOOxJH U4F6NsxfJPhH4s+Yn9SQHa26jJP+AcWuO/6nQ/eDjQFY/R31hZxTv2SIdJKsC3STL1fI socG0Zx2nlj3x97QX1URLWfDRISMBg0rrF57BvETCXtD0HoedzrELSxtej2gIqu6KTDF VCoyPyPHw24GXKuRB42YQP5g5j3hqJvX/iUxBoYRYZTBFs6yNx+/xnsUqOAWe1UgXqlW Y+fw== X-Gm-Message-State: AOPr4FVs1V9q2+D/FU5ycpAEQe17qq3UqFZROboUwAYVo+XnghI689R1i2QWlivdeEoi0A== X-Received: by 10.141.46.71 with SMTP id x68mr18897781qhe.70.1461253211008; Thu, 21 Apr 2016 08:40:11 -0700 (PDT) Received: from [5.5.33.69] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id s85sm500798qke.29.2016.04.21.08.40.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 08:40:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <14815801-1BD6-4773-B27C-2CF407E04745@tislabs.com> Date: Thu, 21 Apr 2016 11:40:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <59FDB682-67C4-442A-807E-8FF2E0F8D693@sn3rd.com> References: <1C34B13A-A444-4EB5-A1A9-7933E67992FA@tislabs.com> <14815801-1BD6-4773-B27C-2CF407E04745@tislabs.com> To: sidr wg list X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:40:14 -0000 I=92ll post a new version shortly. There were also some other tweaks that got added to better future proof = the draft like deleting the paragraph in s1 that said what other drafts = point to the draft. I also finally read the id-nits and addresses the = out-dated, missing, and extra references. spt > On Apr 21, 2016, at 11:26, Sandra Murphy wrote: >=20 > This wglc ended a very long time ago. >=20 > The chairs believe that the wg consensus supports publication of this = draft. >=20 > The draft was waiting for the draft-ietf-sidr-rfc6485bis draft, which = it updates. >=20 > Unfortunately, this draft uses the same language in the Additional = Requirements section that draft-ietf-sidr-rfc6485bis used. Now that the = wg has reached consensus on new text for that section, the draft authors = are directed to change the Additional Requirements section to the = language used in draft-ietf-sidr-rfc6485bis. >=20 > The draft authors are also reminded of the agreement to revise text in = the IANA registry section (see message = https://mailarchive.ietf.org/arch/msg/sidr/ArfOCMbpG0X9JGDFH2d6StBSBLs). >=20 > When a new version is posted, the wg chairs can request publication. >=20 > =97Sandy, speaking as one of the wg co-chairs >=20 > On Oct 16, 2015, at 6:47 PM, Sandra Murphy wrote: >=20 >> The chairs and the authors believe that = draft-ietf-sidr-bgpsec-algs-11 is mature and has stabilized. >>=20 >> This message starts a WGLC for draft-ietf-sidr-bgpsec-algs-11, which = will end 30-October-2015. >>=20 >> Please review the draft and send comments to the list, and say = whether you believe it is ready for publication. >>=20 >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs >>=20 >> BGPsec Algorithms, Key Formats, & Signature Formats >>=20 >> Abstract >>=20 >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format = used >> in BGPsec (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >>=20 >> =97Sandy, speaking as one of the wg co-chairs >>=20 >>=20 >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 21 09:09:52 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F8412D57C; Thu, 21 Apr 2016 09:09:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421160949.19638.47165.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 09:09:49 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:09:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-15.txt Pages : 7 Date : 2016-04-21 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key size and signature format used in BGPsec (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (ID.sidr-rfc6485bis). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 21 09:11:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8FE12DCBF for ; Thu, 21 Apr 2016 09:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 pghC7lBxZOgS for ; Thu, 21 Apr 2016 09:11:06 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4DB12D8A7 for ; Thu, 21 Apr 2016 09:11:06 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8F5B628B00CB; Thu, 21 Apr 2016 12:11:05 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 832DB1F8051; Thu, 21 Apr 2016 12:11:05 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1D90EEEA-AD69-4793-A7E2-DCF7C3B21EF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Sandra Murphy In-Reply-To: <59FDB682-67C4-442A-807E-8FF2E0F8D693@sn3rd.com> Date: Thu, 21 Apr 2016 12:11:01 -0400 Message-Id: References: <1C34B13A-A444-4EB5-A1A9-7933E67992FA@tislabs.com> <14815801-1BD6-4773-B27C-2CF407E04745@tislabs.com> <59FDB682-67C4-442A-807E-8FF2E0F8D693@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:11:10 -0000 --Apple-Mail=_1D90EEEA-AD69-4793-A7E2-DCF7C3B21EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the diligence, especially the nits check. Always a bummer to = find nits when creating the publication request. =97Sandy, speaking as one of the wg co-chairs On Apr 21, 2016, at 11:40 AM, Sean Turner wrote: > I=92ll post a new version shortly. >=20 > There were also some other tweaks that got added to better future = proof the draft like deleting the paragraph in s1 that said what other = drafts point to the draft. I also finally read the id-nits and = addresses the out-dated, missing, and extra references. >=20 > spt >=20 >> On Apr 21, 2016, at 11:26, Sandra Murphy wrote: >>=20 >> This wglc ended a very long time ago. >>=20 >> The chairs believe that the wg consensus supports publication of this = draft. >>=20 >> The draft was waiting for the draft-ietf-sidr-rfc6485bis draft, which = it updates. >>=20 >> Unfortunately, this draft uses the same language in the Additional = Requirements section that draft-ietf-sidr-rfc6485bis used. Now that the = wg has reached consensus on new text for that section, the draft authors = are directed to change the Additional Requirements section to the = language used in draft-ietf-sidr-rfc6485bis. >>=20 >> The draft authors are also reminded of the agreement to revise text = in the IANA registry section (see message = https://mailarchive.ietf.org/arch/msg/sidr/ArfOCMbpG0X9JGDFH2d6StBSBLs). >>=20 >> When a new version is posted, the wg chairs can request publication. >>=20 >> =97Sandy, speaking as one of the wg co-chairs >>=20 >> On Oct 16, 2015, at 6:47 PM, Sandra Murphy wrote: >>=20 >>> The chairs and the authors believe that = draft-ietf-sidr-bgpsec-algs-11 is mature and has stabilized. >>>=20 >>> This message starts a WGLC for draft-ietf-sidr-bgpsec-algs-11, = which will end 30-October-2015. >>>=20 >>> Please review the draft and send comments to the list, and say = whether you believe it is ready for publication. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs >>>=20 >>> BGPsec Algorithms, Key Formats, & Signature Formats >>>=20 >>> Abstract >>>=20 >>> This document specifies the algorithms, algorithms' parameters, >>> asymmetric key formats, asymmetric key size and signature format = used >>> in BGPsec (Border Gateway Protocol Security). This document updates >>> the Profile for Algorithms and Key Sizes for use in the Resource >>> Public Key Infrastructure (draft-ietf-sidr-rfc6485bis). >>>=20 >>> =97Sandy, speaking as one of the wg co-chairs >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_1D90EEEA-AD69-4793-A7E2-DCF7C3B21EF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXGPuVAAoJEHplpQeet0IZy/MQAMJIx1CU1rvWrmDUVUlfWLfH pYVc/h2FQVrNn9El94lhgZRj+ZjYBCFQwQ5XH9i1SwYp/kxdS7SG4JD4KjWwSZtK rEFiKE/i1eG0OCKqH95BTDIox0K9KJ00iHgRp5peJXAl1SzG618SVg8jefykJ2BA ROG0T/DYjx7erMWfdoiVDRlmOadtHvSdgXXheldR0BvRVnGwtTQu+Iit6u5iWENu cG1bWjxOG9MQLRXHKOSYdU9pBby/6ae2nNClcNi/bwFaErq0iAbXyiBejdVDjsQ0 w6UcIremPjXUnpf9uVusV4Yc4ar56izGycQagQtT7RJNvvrEQoH39rThZp0j1ilo kk0HTBGK8F00xg8rFbBSKGHAoTy/R9YdF3R+BA1uLg9KJYr8tNyqrpKS+p54HWGK UEHU67uxAv713Qtq8+LtJRrXnpPmWF34Y7hm7dnTd4KjYllGFGcsO3NelK/uG1dq QACfQvH2EHMdhxSIKGEquI6LoS1O8gXuwYJfIk69jSDJfS2vBXc78BbGuANpK7GU prq7VVqbj66wrMMiK/JVli9SprTpFI00aCbLCjoMwOyFvqngly5xonYyRoaTuTpR pN3V+pg49dCasAa5v+5ijiSIgZef+LpDNKRCxtxT26lPcSBzW7JtvMo+aJYrrl/z wzN8jJNr3zVo8XSzxLsd =0ASt -----END PGP SIGNATURE----- --Apple-Mail=_1D90EEEA-AD69-4793-A7E2-DCF7C3B21EF8-- From nobody Thu Apr 21 10:40:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494312DC6A for ; Thu, 21 Apr 2016 10:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 duoM6XK0_u_g for ; Thu, 21 Apr 2016 10:40:15 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C0212DAE1 for ; Thu, 21 Apr 2016 10:40:14 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 9C9C417033 for ; Thu, 21 Apr 2016 17:40:14 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D13A73ECA011 for ; Thu, 21 Apr 2016 13:39:43 -0400 (EDT) Date: Thu, 21 Apr 2016 13:39:43 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <857C3D49-6B72-4342-BBFE-9DF9DA25D956@sn3rd.com> References: <20160321180031.31949.99113.idtracker@ietfa.amsl.com> <857C3D49-6B72-4342-BBFE-9DF9DA25D956@sn3rd.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160421173943.D13A73ECA011@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:40:16 -0000 -16 addresses my issues with PKCS #10 SIA and EKU extensions. From nobody Fri Apr 22 08:40:49 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FCB12DA43; Fri, 22 Apr 2016 08:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0V13QKw00PwS; Fri, 22 Apr 2016 08:40:46 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 D50FD12DA1F; Fri, 22 Apr 2016 08:40:45 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t10so126608125ywa.0; Fri, 22 Apr 2016 08:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1e66CUaXcP+31SOCgm5kNLw2hNP5vjSd2WNrJV/qJfY=; b=IMzgmrNoA73EcEf24DBQIpFfQRk+aVTW8kTocwXaIoqyQA+QNhg5hDFpxmzwFP9aAD cNh0zcLHujESj67CjiUM3SImOSr9WvFRPHFKa+4152KsQ9HPdlJ2duA/bH3d5owGW47U tIu4iYj0Xal6yW6oQTkRgg25wtBb5YnBDvViZ0OF3Vy2Op6fdwmmOLFPT8KMnCi5jin1 uYLuQdxncCir5wfsdeOpGY6mP5moxfKAacU9neiny/tgtv2QZVGmFzt4zZfFyzJGtKV1 KrBoVk19Uu9lnc8B7dw7Xtuk9dnpEiY/GwqgMncXARthLLzLNeYOKyFoSTkrOCHzau/7 VWJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1e66CUaXcP+31SOCgm5kNLw2hNP5vjSd2WNrJV/qJfY=; b=gpIasWm7DHGiWmRkDzjJYS6IaHnUBAidBLppydzM8oFFurd304H462ch/QFYATjwsD TJPkfLzx9Uj/pPQWb7NaHohuWx3MThDO+MjvKhuV3rTieUARYJl4rpoXiJ5b7mT6rbRI 5mcX74tup47U21Ek+F1fIXVQCxk3C7lsod0N9uGMHkwsE+qKM2KhK2HiU2S0SNrKEZPA JnmbD307YS2b7jV4/RdMZRYERdGWeICchxZgba5QsDi3bgpWpZHQoTBblxHDnzSOsrEG aHh8XJtMnb3+4Gy5UsY7JHsgXjDNZCxBR/fTXOTnB7GS24WDLMxUWLCUVhbtDh4DY1VH Zs6A== X-Gm-Message-State: AOPr4FVgG0SVk1Q4GSCM2usydTOvNx7lX9VBQBSWQd4AfupXWnW8QvnU+ptSP1q4c2qTM+pGcrN9BaCOKGmYJg== MIME-Version: 1.0 X-Received: by 10.129.85.134 with SMTP id j128mr5833912ywb.177.1461339645093; Fri, 22 Apr 2016 08:40:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.209.198 with HTTP; Fri, 22 Apr 2016 08:40:44 -0700 (PDT) In-Reply-To: <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> Date: Fri, 22 Apr 2016 11:40:44 -0400 X-Google-Sender-Auth: VKP57mhPlen_WJlvWj8zRpZFrF4 Message-ID: From: Christopher Morrow To: sidr Content-Type: multipart/alternative; boundary=001a113f1f8e71339b053114a6a5 Archived-At: Cc: "sidr-chairs@ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:40:48 -0000 --001a113f1f8e71339b053114a6a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There's been some good discussion on this, i think we (chairs) didn't expect the list to jump on this without some prompting... but it's nice to see :) So, in service of 'coming to a decision' I think we should debate/discuss for another bit, and close discussion Fri 4/29/2016 - April 29th 2016. thanks! -chris On Wed, Apr 20, 2016 at 4:01 AM, Tim Bruijnzeels wrote: > > > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) > wrote: > > > > +1 with Standard Track. > > +1 > > > > > The question could have been relevant six years ago and we may not have > > debated it that much then. Today, we are clearly beyond experimental > draft > > definition and we do not want to stop people working on the topic. > > > > Roque > > > > > > > > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" < > sidr-bounces@ietf.org > > on behalf of gih@apnic.net> wrote: > > > >> > >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: > >>> > >>> I didn't attend the IETF meeting, but I did listen to the Wednesday > >>> SIDR session, at > >>> which the issue was raised as to whether the BGPSec RFC should be > >>> standards track > >>> or experimental. > >>> > >> > >> I was in the room, but did not speak to this topic. > >> > >>> I believe standards track is the right approach here. > >> > >> I consulted the oracle of RFC2026 and read the following: > >> > >> A Proposed Standard specification is generally stable, has resolved > >> known design choices, is believed to be well-understood, has received > >> significant community review, and appears to enjoy enough community > >> interest to be considered valuable. However, further experience > >> might result in a change or even retraction of the specification > >> before it advances. > >> > >> This seems to fit well, including the caveats at the end. > >> > >> On the other hand: > >> > >> The "Experimental" designation typically denotes a specification that > >> is part of some research or development effort. Such a specification > >> is published for the general information of the Internet technical > >> community and as an archival record of the work, subject only to > >> editorial considerations and to verification that there has been > >> adequate coordination with the standards process (see below). > >> > >> Which seems to fall short. > >> > >> The exercise of RFC publication of BGPSec is more than archival, and t= he > >> process > >> has been much more than a cursory exercise of coordination with the SI= DR > >> WG. While > >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2=B9s > >> Internet, that > >> future uncertainty applies to most of the IETF=C2=B9s work, and that > >> consideration > >> should not preclude its publication as a Proposed Standard, as I > >> interpret RFC2026. > >> > >> Geoff > >> > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a113f1f8e71339b053114a6a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The= re's been some good discussion on this, i think we (chairs) didn't = expect the list to jump on this without some prompting... but it's nice= to see :)

= So, in service of 'coming to a decision' I think we should debate/d= iscuss for another bit, and close discussion Fri 4/29/2016 - April 29th 201= 6.

thanks!
-chris

On Wed, Apr 20, 2016 at 4:01 AM, T= im Bruijnzeels <tim@ripe.net> wrote:

> On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:
>
> +1 with Standard Track.

+1

>
> The question could have been relevant six years ago and we may not hav= e
> debated it that much then. Today, we are clearly beyond experimental d= raft
> definition and we do not want to stop people working on the topic.
>
> Roque
>
>
>
> On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <sidr-bounces@ietf.org
> on behalf of gih@apnic.net> wr= ote:
>
>>
>>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@bbn.com> wrote:
>>>
>>> I didn't attend the IETF meeting, but I did listen to the = Wednesday
>>> SIDR session, at
>>> which the issue was raised as to whether the BGPSec RFC should= be
>>> standards track
>>> or experimental.
>>>
>>
>> I was in the room, but did not speak to this topic.
>>
>>> I believe standards track is the right approach here.
>>
>> I consulted the oracle of RFC2026 and read the following:
>>
>>=C2=A0 A Proposed Standard specification is generally stable, has r= esolved
>>=C2=A0 known design choices, is believed to be well-understood, has= received
>>=C2=A0 significant community review, and appears to enjoy enough co= mmunity
>>=C2=A0 interest to be considered valuable.=C2=A0 However, further e= xperience
>>=C2=A0 might result in a change or even retraction of the specifica= tion
>>=C2=A0 before it advances.
>>
>> This seems to fit well, including the caveats at the end.
>>
>> On the other hand:
>>
>> The "Experimental" designation typically denotes a speci= fication that
>>=C2=A0 is part of some research or development effort.=C2=A0 Such a= specification
>>=C2=A0 is published for the general information of the Internet tec= hnical
>>=C2=A0 community and as an archival record of the work, subject onl= y to
>>=C2=A0 editorial considerations and to verification that there has = been
>>=C2=A0 adequate coordination with the standards process (see below)= .
>>
>> Which seems to fall short.
>>
>> The exercise of RFC publication of BGPSec is more than archival, a= nd the
>> process
>> has been much more than a cursory exercise of coordination with th= e SIDR
>> WG. While
>> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2= =B9s
>> Internet, that
>> future uncertainty applies to most of the IETF=C2=B9s work, and th= at
>> consideration
>> should not preclude its publication as a Proposed Standard, as I >> interpret RFC2026.
>>
>> Geoff
>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr >
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

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

--001a113f1f8e71339b053114a6a5-- From nobody Fri Apr 22 17:09:16 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA84012D0FE; Fri, 22 Apr 2016 17:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 QtBIetDYThbv; Fri, 22 Apr 2016 17:09:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40CF12D1C0; Fri, 22 Apr 2016 17:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8907; q=dns/txt; s=iport; t=1461370153; x=1462579753; h=from:to:cc:subject:date:message-id:mime-version; bh=vO93JJ2KQC/46jk7nlRGi0dZ6M7ZRUhwRPikCrixYGw=; b=l2AjEZU+UvmGKCwcG/xYuHAt67UQueIUMTKLHvf5n6FCJQ0Bv6VXdl6S KvUVzxJHT5G05XhZDfNq9SGhV+nyRyyHTYYjLjbGd4YXDLyUS4yXzvJ6a jscRh670jLSPhK91Y+IMQkDaiXtSEtKYm2p3SYRZ5p3gd3W3mSO8uQKVA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AgCyvBpX/5FdJa1egmxMgVa1DIRzA?= =?us-ascii?q?Q2BdYYOgSY4FAEBAQEBAQFlHAuERAR5EgGBACcEDogvv0cBAQEBAQEEAQEBAQE?= =?us-ascii?q?BARmGIY5gBY4LhROEcQGOE4FmjSqGI4kLAR4BAUKCBhqBS4hofwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,519,1454976000"; d="scan'208,217";a="263176162" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2016 00:09:08 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3N098qW007872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Apr 2016 00:09:08 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 19:09:07 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 19:09:07 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org" Thread-Topic: AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 Thread-Index: AQHRnPRan3y40yRdEkS30+qNsvqUUg== Date: Sat, 23 Apr 2016 00:09:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.183.80] Content-Type: multipart/alternative; boundary="_000_D321EEDD11B911aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 00:09:15 -0000 --_000_D321EEDD11B911aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I have a couple of Major comments related to the existence/co-existence of = two versions of the protocol. I would like to see the comments discussed/a= ddressed before starting the IETF Last Call. Thanks!! Alvaro. Major: 1. RFC6810. * Section 1.2. (Changes from RFC 6810): "The protocol described in = this document is largely compatible with [RFC6810]." What does "largely co= mpatible" mean? It either is compatible or it isn't. From Section 7. (Pro= tocol Version Negotiation), it looks like there's no way for a router that = only supports version 0 to talk a cache that only supports version 1, and v= iceversa. Even though the PDUs are mostly the same, that doesn't seem to m= atter...in the end it looks like the versions are not compatible and in rea= lity version 1 is simply an update to version 0. * This document is marked as obsoleting rfc6810, but it mandates its= use in section 7 ("...the cache MUST downgrade to protocol version 0 [RFC6= 810]..."). There are a couple of paths forward: * It seems to me that this document should simply be called "RPKI= to Router Protocol version 1" and not change the status of rfc6810 - we ca= n always declare version 0 historic later. * If you really want to obsolete version 0, then an alternative i= s to eliminate the normative language when it refers to it... For example, * OLD> "If a cache which supports version 1 receives a query f= rom a router which specifies version 0, the cache MUST downgrade to protoco= l version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code = 4 ("Unsupported Protocol Version") and terminate the connection." * NEW> "If a cache which supports version 1 receives a query f= rom a router which specifies version 0, the cache SHOULD send a version 1 E= rror Report PDU with Error Code 4 ("Unsupported Protocol Version") and term= inate the connection." 2. Section 7. (Protocol Version Negotiation) Related to the points abov= e... Are other versions of this protocol expected? I know the answer may = come from a crystal ball at this point...but can the process defined here b= e generalized? Minor: 1. Implementation * In Section 1. (Introduction) you reference rfc7128 for an implemen= tation report, but that RFC reports on the implementation of rfc6810, and n= ot this new version. * It would be nice to include a section according to rfc6982 about i= mplementations of this version. 2. Section 9. (Transport) I think this sentence is superfluous: "Caches= and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPSec transport.", becau= se a couple of paragraphs later the text also says "...caches and routers M= UST use one of the following more protected protocols" (and the same protoc= ols are revisited). --_000_D321EEDD11B911aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi!

I have a couple of Major comments related to the existence/co-existence of = two versions of the protocol.  I would like to see the comments discus= sed/addressed before starting the IETF Last Call.

Thanks!!

Alvaro.


Major:
  1. RFC6810.
    • Section 1.2. (Changes from RF= C 6810):  "The protocol described in this document is largely com= patible with [RFC6810]."  What does "largely compatible"= ; mean?  It either is compatible or it isn't.  From Section = 7. (Protocol Version Negotiation), it looks like there's no way for a router that only = supports version 0 to talk a cache that only supports version 1, and viceve= rsa.  Even though the PDUs are mostly the same, that doesn't seem to m= atter…in the end it looks like the versions are not compatible and in reality version 1 is simply an update to version= 0.
    • This document is marke= d as obsoleting rfc6810, but it mandates its use in section 7 ("…= ;the cache MUST downgrade to protocol version 0 [RFC6810]…").  There are a= couple of paths forward:
      1. It seems to me that this document sho= uld simply be called "RPKI to Router Protocol version 1" and not = change the status of rfc6810 — we can always declare versio= n 0 historic later.
      2. If you really want to obsolete version 0= , then an alternative is to eliminate the normative language when it refers= to it...  For example, 
        • OLD> "If a cache which supports version 1 receives a query from= a router which specifies version 0, the cache MUST downgrade to protocol v= ersion 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 (= "Unsupported Protocol Version") and terminate the connection."
        • NEW> "If a cache which supports vers= ion 1 receives a query from a router which specifies version 0, the cache S= HOULD send a version 1 Error Report PDU with Error Code 4 ("Unsupporte= d Protocol Version") and terminate the connection."
  2. Section 7. (Protocol Version Negotiation)  Related to the points above= …  Are other versions of this protocol expected?  I know th= e answer may come from a crystal ball at this point…but can the proce= ss defined here be generalized?
Minor:
  1. Implementation
    • In Section 1. (Introduction) you reference rfc7128 for an implemen= tation report, but that RFC reports on the implementation of rfc6810, and n= ot this new version.  
    • It would be nice to include a section a= ccording to rfc6982 about implementations of this version.
  2. Section 9. (Transport) &nbs= p;I think this sentence is superfluous: "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or I= PSec transport.", b= ecause a couple of paragraphs later the text also says "…caches and routers MUST use one of the following more protected protocols" (and the same protocols are revisited).
--_000_D321EEDD11B911aretanaciscocom_-- From nobody Mon Apr 25 07:53:39 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDA12D5DC for ; Mon, 25 Apr 2016 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rUaei1HWCyxn for ; Mon, 25 Apr 2016 07:53:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 B44BD12D606 for ; Mon, 25 Apr 2016 07:53:30 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x7so63056668qkd.3 for ; Mon, 25 Apr 2016 07:53:30 -0700 (PDT) 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=PuUsD16MCvXJF8JvGyVbRnHrTTLLDE/IPNDADP+Fato=; b=XZoiWG/aX8kDSbObV1Q2lPQS4iCpH6a5tPjiJ7dp0gm8jGTPoYQqNaKjJx5O3aEEQd ZNEEvoyJ5Wct3E2p9OXQt99bqN6llwMTG4tTQAxIfDyFSza5hUDFwrEb3SjqaV9iLpo5 0eQ64wmsOGmSYUfxSi/PSwqMWzBoYdtEBdpI7SoyVPiW2LtUE3Dzxdn3ThgxNgz234ae 5jUna3C58P+VfkMhjaRkgNqGCSYreMfYSMg/JC6QkAvHSrgFUtdeYEgHW5iEDCAGZNNG +ICuNRREtGYo8/Og9e9GBb2e7R2SLEw+adDzsNS5mYnMjSEBW9klGdSI9J7IjPUp/CsL jFkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PuUsD16MCvXJF8JvGyVbRnHrTTLLDE/IPNDADP+Fato=; b=Q6+85fP7JcLzCyZAz+TzqE4sVGhJnzLpYM2j1aO0FBnZhA7Ka+CARsMKxUzv6m4+OP OPHLwVgP1dceR7e9VojmxcZ1XAD9c1Z5EjNsXB/SbSv3pBTeII9FWl1MCLnjV6n5LByM Ltf4sTpYRKXGyqk0ap6fXeaayPDiOc435C0JQ5heLFiWFDlRjicN2qPTIdfoD5MzU2h+ Pw5ta9AtNOereENrxxJI/qNKAhshjA1jDyKlmOnWGVATd+YLSES3xj/0or8Z8B/Rmo04 YDv0aQqve8klEglsMB5dOQaP3an/XcxxyaqgGGrs6Uas1ZeuiutLB5hYQSJoCxQdHk02 h4Ng== X-Gm-Message-State: AOPr4FU0ziZEtkvlhjo5/TYUpCQ7PT47KAkbKwPNeYZjSHLj1LpQO5sVD6navAnncl0Okjzpx0DAONUsRfs4IpRG X-Received: by 10.55.203.8 with SMTP id d8mr18492688qkj.124.1461596009825; Mon, 25 Apr 2016 07:53:29 -0700 (PDT) MIME-Version: 1.0 References: <570E8D44.1080208@bbn.com> <04F2C4EA-BF87-45A1-904F-350455D11FDE@apnic.net> <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> In-Reply-To: <4B179E5E-0BB3-401A-B968-3415EB7C5760@ripe.net> From: Warren Kumari Date: Mon, 25 Apr 2016 14:53:20 +0000 Message-ID: To: Tim Bruijnzeels , "Roque Gagliano (rogaglia)" Content-Type: multipart/alternative; boundary=001a113a3a50f89feb05315056af Archived-At: Cc: sidr Subject: Re: [sidr] BGPSec RFC status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 14:53:39 -0000 --001a113a3a50f89feb05315056af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ... and another +1. W On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels wrote: > > > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) > wrote: > > > > +1 with Standard Track. > > +1 > > > > > The question could have been relevant six years ago and we may not have > > debated it that much then. Today, we are clearly beyond experimental > draft > > definition and we do not want to stop people working on the topic. > > > > Roque > > > > > > > > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" < > sidr-bounces@ietf.org > > on behalf of gih@apnic.net> wrote: > > > >> > >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent wrote: > >>> > >>> I didn't attend the IETF meeting, but I did listen to the Wednesday > >>> SIDR session, at > >>> which the issue was raised as to whether the BGPSec RFC should be > >>> standards track > >>> or experimental. > >>> > >> > >> I was in the room, but did not speak to this topic. > >> > >>> I believe standards track is the right approach here. > >> > >> I consulted the oracle of RFC2026 and read the following: > >> > >> A Proposed Standard specification is generally stable, has resolved > >> known design choices, is believed to be well-understood, has received > >> significant community review, and appears to enjoy enough community > >> interest to be considered valuable. However, further experience > >> might result in a change or even retraction of the specification > >> before it advances. > >> > >> This seems to fit well, including the caveats at the end. > >> > >> On the other hand: > >> > >> The "Experimental" designation typically denotes a specification that > >> is part of some research or development effort. Such a specification > >> is published for the general information of the Internet technical > >> community and as an archival record of the work, subject only to > >> editorial considerations and to verification that there has been > >> adequate coordination with the standards process (see below). > >> > >> Which seems to fall short. > >> > >> The exercise of RFC publication of BGPSec is more than archival, and t= he > >> process > >> has been much more than a cursory exercise of coordination with the SI= DR > >> WG. While > >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2=B9s > >> Internet, that > >> future uncertainty applies to most of the IETF=C2=B9s work, and that > >> consideration > >> should not preclude its publication as a Proposed Standard, as I > >> interpret RFC2026. > >> > >> Geoff > >> > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a113a3a50f89feb05315056af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
... and another=C2=A0+1.
W

On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels <= ;tim@ripe.net> wrote:

> On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:=
>
> +1 with Standard Track.

+1

>
> The question could have been relevant six years ago and we may not hav= e
> debated it that much then. Today, we are clearly beyond experimental d= raft
> definition and we do not want to stop people working on the topic.
>
> Roque
>
>
>
> On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <sidr-bounces@ietf.or= g
> on behalf of gih@ap= nic.net> wrote:
>
>>
>>> On 14 Apr 2016, at 4:17 AM, Stephen Kent <kent@bbn.com> wrote:
>>>
>>> I didn't attend the IETF meeting, but I did listen to the = Wednesday
>>> SIDR session, at
>>> which the issue was raised as to whether the BGPSec RFC should= be
>>> standards track
>>> or experimental.
>>>
>>
>> I was in the room, but did not speak to this topic.
>>
>>> I believe standards track is the right approach here.
>>
>> I consulted the oracle of RFC2026 and read the following:
>>
>>=C2=A0 A Proposed Standard specification is generally stable, has r= esolved
>>=C2=A0 known design choices, is believed to be well-understood, has= received
>>=C2=A0 significant community review, and appears to enjoy enough co= mmunity
>>=C2=A0 interest to be considered valuable.=C2=A0 However, further e= xperience
>>=C2=A0 might result in a change or even retraction of the specifica= tion
>>=C2=A0 before it advances.
>>
>> This seems to fit well, including the caveats at the end.
>>
>> On the other hand:
>>
>> The "Experimental" designation typically denotes a speci= fication that
>>=C2=A0 is part of some research or development effort.=C2=A0 Such a= specification
>>=C2=A0 is published for the general information of the Internet tec= hnical
>>=C2=A0 community and as an archival record of the work, subject onl= y to
>>=C2=A0 editorial considerations and to verification that there has = been
>>=C2=A0 adequate coordination with the standards process (see below)= .
>>
>> Which seems to fall short.
>>
>> The exercise of RFC publication of BGPSec is more than archival, a= nd the
>> process
>> has been much more than a cursory exercise of coordination with th= e SIDR
>> WG. While
>> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow=C2= =B9s
>> Internet, that
>> future uncertainty applies to most of the IETF=C2=B9s work, and th= at
>> consideration
>> should not preclude its publication as a Proposed Standard, as I >> interpret RFC2026.
>>
>> Geoff
>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr >
> _______________________________________________
> sidr mailing list
> sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--001a113a3a50f89feb05315056af-- From nobody Mon Apr 25 11:45:12 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D54212D0A0; Mon, 25 Apr 2016 11:45:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 11:45:08 -0700 Archived-At: Cc: sandy@tislabs.com, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:45:08 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Securing RPSL Objects with RPKI Signatures' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-05-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method to allow parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have Routing Policy System Security-based authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFC 2622 and RFC 4012 to add the signature attribute to supported RPSL objects. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 26 02:25:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2A12D0DB for ; Tue, 26 Apr 2016 02:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF35n01dwnSk for ; Tue, 26 Apr 2016 02:25:32 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C3512B069 for ; Tue, 26 Apr 2016 02:25:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,536,1454972400"; d="scan'208";a="2822753" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP; 26 Apr 2016 11:25:29 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 4933AB009D; Tue, 26 Apr 2016 11:25:29 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 26 Apr 2016 11:25:28 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Tue, 26 Apr 2016 11:25:28 +0200 From: Thomas King To: "Sriram, Kotikalapudi (Fed)" , "John G. Scudder" Thread-Topic: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt Thread-Index: AQHRn52SzdB4iNpq/Ee01GU1Y2aqTg== Date: Tue, 26 Apr 2016 09:25:28 +0000 Message-ID: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> Accept-Language: en-US, de-DE 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: [192.168.140.65] Content-Type: text/plain; charset="utf-8" Content-ID: <16EE4E47E7D856489E6654D8B0DEEB37@for-the-inter.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 09:25:36 -0000 SGkgYWxsLA0KDQpGb2xsb3dpbmcgdXAgb24gdGhlIGRpc2N1c3Npb24gd2UgaGFkIGR1cmluZyB0 aGUgbGFzdCBJRVRGIG1lZXRpbmcgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3Mgd2l0aCB5b3UgaG93 IHdlIHByb2NlZWQgd2l0aCB0aGUg4oCcRGlkIG5vdCBwZXJmb3JtIHZhbGlkYXRpb27igJ0gdmFs dWUuIEkgdGhpbmsgdGhpcyB2YWx1ZSBpcyB2ZXJ5IGltcG9ydGFudCBhbmQgc2hvdWxkIGJlIGFk ZGVkIHRvIGlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxpbmcuDQoNCkJlc3QgcmVn YXJkcywNClRob21hcw0K From nobody Tue Apr 26 04:32:31 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012CD12D0B3 for ; Tue, 26 Apr 2016 04:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 9EbvZFskJmZ2 for ; Tue, 26 Apr 2016 04:32:28 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 806AB12D0EF for ; Tue, 26 Apr 2016 04:32:28 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1av1E7-001QnK-4w>; Tue, 26 Apr 2016 13:32:23 +0200 Received: from ze304.pia.fu-berlin.de ([87.77.227.4] helo=mw-PC.zedat.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from ) id <1av1E6-003Eh4-To>; Tue, 26 Apr 2016 13:32:23 +0200 Date: Tue, 26 Apr 2016 13:32:16 +0200 From: Matthias Waehlisch To: Thomas King In-Reply-To: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> Message-ID: References: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="44968713-28680-1461667253=:4044" Content-ID: X-Originating-IP: 87.77.227.4 Archived-At: Cc: "John G. Scudder" , "Sriram, Kotikalapudi \(Fed\)" , "sidr@ietf.org" Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 11:32:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --44968713-28680-1461667253=:4044 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: There was a quite similar discussion in 2013, for the thread see https://mailarchive.ietf.org/arch/msg/sidr/zvSP_-iiEfu_acYInK5lOMnys5U As far as I remember w/o a final conclusion (or the conclusion was leave it as is). Cheers matthias On Tue, 26 Apr 2016, Thomas King wrote: > Hi all, > > Following up on the discussion we had during the last IETF meeting I would like to discuss with you how we proceed with the “Did not perform validation” value. I think this value is very important and should be added to ietf-sidr-origin-validation-signaling. > > Best regards, > Thomas > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net --44968713-28680-1461667253=:4044-- From nobody Tue Apr 26 05:34:07 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C1712D18D for ; Tue, 26 Apr 2016 05:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFgphKodJwvk for ; Tue, 26 Apr 2016 05:34:04 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3249012D193 for ; Tue, 26 Apr 2016 05:34:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,536,1454972400"; d="scan'208";a="2823628" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP; 26 Apr 2016 14:34:00 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 5F396B009D; Tue, 26 Apr 2016 14:34:00 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 26 Apr 2016 14:34:00 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Tue, 26 Apr 2016 14:34:00 +0200 From: Thomas King To: "sidr@ietf.org" Thread-Topic: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt Thread-Index: AQHRn52SzdB4iNpq/Ee01GU1Y2aqTp+b/c8AgAAyxYA= Date: Tue, 26 Apr 2016 12:33:59 +0000 Message-ID: References: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> In-Reply-To: Accept-Language: en-US, de-DE 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: [192.168.140.65] Content-Type: text/plain; charset="utf-8" Content-ID: <7AA02E664806CB44AE5902FBA19F723C@for-the-inter.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "John G. Scudder" , "Sriram, Kotikalapudi \(Fed\)" , Matthias Waehlisch Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 12:34:06 -0000 SSB3b3VsZCBsaWtlIHRvIGNvbWUgYmFjayB0byBhIHNvbHV0aW9uIHRoYXQgd2FzIGRpc2N1c3Nl ZCBhbHJlYWR5OiBJZiB0aGUgcm91dGUtc2VydmVyIGlzIG5vdCBhYmxlIHRvIHBlcmZvcm0gdGhl IG9yaWdpbiBwcmVmaXggdmFsaWRhdGlvbiB0aGUgQkdQIGNvbW11bml0eSBpcyBub3QgYWRkZWQg dG8gdGhlIEJHUCB1cGRhdGUuIFRoZSBCR1AgY29tbXVuaXR5IGlzIG9ubHkgYWRkZWQgaWYgdGhl IG9yaWdpbiBwcmVmaXggdmFsaWRhdGlvbiBjb3VsZCBiZSBleGVjdXRlZC4NCg0KVGhpcyBzb2x1 dGlvbiBhbGxvd3MgYSBjbGVhciBzaWduYWxsaW5nLiBUaGlzIHdvdWxkIGFsc28gYmUgY29tcGF0 aWJsZSB3aXRoIHRoZSBjdXJyZW50IGlldGYtc2lkci1vcmlnaW4tdmFsaWRhdGlvbi1zaWduYWxp bmcgZG9jdW1lbnQgYW5kIGNvdWxkIGJlIGVhc2lseSBzdGF0ZWQgaW4gZHJhZnQta2tsZi1zaWRy LXJvdXRlLXNlcnZlci1ycGtpLWxpZ2h0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpUaG9tYXMNCg0KDQoN Cg0KT24gMjYvMDQvMjAxNiwgMTM6MzIsICJNYXR0aGlhcyBXYWVobGlzY2giIDxtLndhZWhsaXNj aEBmdS1iZXJsaW4uZGU+IHdyb3RlOg0KDQo+VGhlcmUgd2FzIGEgcXVpdGUgc2ltaWxhciBkaXNj dXNzaW9uIGluIDIwMTMsIGZvciB0aGUgdGhyZWFkIHNlZQ0KPg0KPmh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2lkci96dlNQXy1paUVmdV9hY1lJbks1bE9NbnlzNVUNCj4N Cj5BcyBmYXIgYXMgSSByZW1lbWJlciB3L28gYSBmaW5hbCBjb25jbHVzaW9uIChvciB0aGUgY29u Y2x1c2lvbiB3YXMgDQo+bGVhdmUgaXQgYXMgaXMpLg0KPg0KPg0KPkNoZWVycw0KPiAgbWF0dGhp YXMNCj4NCj5PbiBUdWUsIDI2IEFwciAyMDE2LCBUaG9tYXMgS2luZyB3cm90ZToNCj4NCj4+IEhp IGFsbCwNCj4+IA0KPj4gRm9sbG93aW5nIHVwIG9uIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBkdXJp bmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nIEkgd291bGQgbGlrZSB0byBkaXNjdXNzIHdpdGggeW91 IGhvdyB3ZSBwcm9jZWVkIHdpdGggdGhlIOKAnERpZCBub3QgcGVyZm9ybSB2YWxpZGF0aW9u4oCd IHZhbHVlLiBJIHRoaW5rIHRoaXMgdmFsdWUgaXMgdmVyeSBpbXBvcnRhbnQgYW5kIHNob3VsZCBi ZSBhZGRlZCB0byBpZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nLg0KPj4gDQo+ PiBCZXN0IHJlZ2FyZHMsDQo+PiBUaG9tYXMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBzaWRyIG1haWxpbmcgbGlzdA0KPj4gc2lkckBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQo+PiAN Cj4NCj4NCj4tLSANCj5Eci4gTWF0dGhpYXMgV2FlaGxpc2NoDQo+LiAgRnJlaWUgVW5pdmVyc2l0 YWV0IEJlcmxpbiwgSW5zdC4gZnVlciBJbmZvcm1hdGlrLCBBRyBDU1QNCj4uICBUYWt1c3RyLiA5 LCBELTE0MTk1IEJlcmxpbiwgR2VybWFueQ0KPi4uIG1haWx0bzptLndhZWhsaXNjaEBmdS1iZXJs aW4uZGUgLi4gaHR0cDovL3d3dy5pbmYuZnUtYmVybGluLmRlL353YWVobA0KPjouIEFsc286IGh0 dHA6Ly9pbmV0Lmhhdy1oYW1idXJnLmRlIC4uIGh0dHA6Ly93d3cubGluay1sYWIubmV0DQo= From nobody Tue Apr 26 08:06:34 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC36912D14C for ; Tue, 26 Apr 2016 08:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 bgkKqKq2Ws4h for ; Tue, 26 Apr 2016 08:06:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED3F12D1DB for ; Tue, 26 Apr 2016 08:06:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1av4ZH-00067N-C4; Tue, 26 Apr 2016 15:06:27 +0000 Date: Wed, 27 Apr 2016 00:06:25 +0900 Message-ID: From: Randy Bush To: Thomas King In-Reply-To: References: <5B8B8060-A9ED-427D-85BD-50723DA4CBB9@de-cix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "John G. Scudder" , "Sriram, Kotikalapudi \(Fed\)" , Matthias Waehlisch , "sidr@ietf.org" Subject: Re: [sidr] New Version Notification for draft-kklf-sidr-route-server-rpki-light-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:06:33 -0000 > I would like to come back to a solution that was discussed already: If > the route-server is not able to perform the origin prefix validation > the BGP community is not added to the BGP update. The BGP community is > only added if the origin prefix validation could be executed. > > This solution allows a clear signalling. This would also be compatible > with the current ietf-sidr-origin-validation-signaling document and > could be easily stated in draft-kklf-sidr-route-server-rpki-light. you're welcome randy From nobody Tue Apr 26 18:47:01 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8553F12D59B; Tue, 26 Apr 2016 18:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 CCsZ7JubXhQW; Tue, 26 Apr 2016 18:46:58 -0700 (PDT) Received: from pv33p07im-ztdg10141401.me.com (pv33p07im-ztdg10141401.me.com [17.142.253.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB39712B043; Tue, 26 Apr 2016 18:46:58 -0700 (PDT) Received: from process-dkim-sign-daemon.pv33p07im-ztdg10141401.me.com by pv33p07im-ztdg10141401.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) id <0O6900800R4J0G00@pv33p07im-ztdg10141401.me.com>; Wed, 27 Apr 2016 01:46:58 +0000 (GMT) Received: from [172.20.10.2] (unknown [61.148.243.162]) by pv33p07im-ztdg10141401.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O6900BK5RM0BC20@pv33p07im-ztdg10141401.me.com>; Wed, 27 Apr 2016 01:46:57 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-27_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=7 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1604270019 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Declan Ma Date: Wed, 27 Apr 2016 09:46:47 +0800 Content-transfer-encoding: quoted-printable Message-id: References: <20160412100344.32250.28492.idtracker@ietfa.amsl.com> To: IETF SIDR X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1461721618; bh=z/sHhkVH/MU9nTqWr3oyqmSE05EYYXWZi1nN+CsJduU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=T7BH3K6CQoyVsbzk4Yo7pTlvSz9glFYGSjqeaxdFyYptjWTwR5Uww3QftGExULC+d rBE5KmHG01p2hCwHSAQKxf3PsXpRIgFh/MKURQVR5Ih+WkxfgxkQqflh2f4svmKypw WohuaAQD1VqDqf6kgTWtK6CqzkJxzhchFNuIq171rwYD4PulWJjGaWwXYtb5O1InAa xQWPHFJm5cBmVabBojUaM2B1B0S8nwpMs+PNQ/SMa5+GMsF9d4K3XfCVVsvUMVDi9b SVxyzjf1JGVFQAM/4iJN509RLRtK6yosN/daA6fIG+02scD0Xn7OVD3GCmqStEKJp7 LSy5EULwSdncw== Archived-At: Cc: sidr chairs Subject: [sidr] Fwd: New Version Notification for draft-madi-sidr-rp-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 01:47:00 -0000 Hi, folks, Steve Kent and I have generated this document to try to consolidate RP = requirements in one document, with pointers to all the relevant RFCs.=20 As I mentioned in IETF 95 meeting, there is no standards language (e.g., = MUST, SHOULD, MAY, ...) in this doc, as it is just POINTING to the docs = that have the real requirements.=20 This doc outlines the RP functions, summarizes them and then gives = reference to those precise sections or paragraphs, in order to make life = easier for implementers to make sure he/she has addressed all of these = requirements.=20 Any comments and feedbacks are appreciated. Di ZDNS > =CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA >=20 > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org > =D6=F7=CC=E2: New Version Notification for draft-madi-sidr-rp-00.txt > =C8=D5=C6=DA: 2016=C4=EA4=D4=C212=C8=D5 GMT+8 18:03:44 > =CA=D5=BC=FE=C8=CB: "Dr. Stephen T. Kent" , "Di Ma" = , "Stephen Kent" >=20 >=20 > A new version of I-D, draft-madi-sidr-rp-00.txt > has been successfully submitted by Di Ma and posted to the > IETF repository. >=20 > Name: draft-madi-sidr-rp > Revision: 00 > Title: Requirements for Resource Public Key = Infrastructure (RPKI) Relying Parties > Document date: 2016-04-12 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-madi-sidr-rp-00.txt > Status: https://datatracker.ietf.org/doc/draft-madi-sidr-rp/ > Htmlized: https://tools.ietf.org/html/draft-madi-sidr-rp-00 >=20 >=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). It cites requirements that appear in several > RPKI RFCs, making it easier for implementers to become aware of = these > requirements. >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Tue Apr 26 18:57:29 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1812D5C4; Tue, 26 Apr 2016 18:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 PlXxbopiKbPi; Tue, 26 Apr 2016 18:57:26 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF3E12D5B4; Tue, 26 Apr 2016 18:57:23 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 1006117046; Wed, 27 Apr 2016 01:57:23 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 9591B3EEED13; Tue, 26 Apr 2016 21:58:28 -0400 (EDT) Date: Tue, 26 Apr 2016 21:58:28 -0400 From: Rob Austein To: "Alvaro Retana (aretana)" References: MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160427015828.9591B3EEED13@minas-ithil.hactrn.net> Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 01:57:28 -0000 At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote: > > * Section 1.2. (Changes from RFC 6810): "The protocol > described in this document is largely compatible with > [RFC6810]." What does "largely compatible" mean? It > either is compatible or it isn't. It means that most of the code one needs to deal with version one is the same as the code one needs to deal with version zero. Feel free to suggest better text. > From Section 7. (Protocol Version Negotiation), it looks > like there's no way for a router that only supports version > 0 to talk a cache that only supports version 1, and > viceversa. Correct. This is implicit in the original PDU design in RFC 6810, the current draft doesn't change anything in that part of the design. > Even though the PDUs are mostly the same, that doesn't seem > to matter...in the end it looks like the versions are not > compatible and in reality version 1 is simply an update to > version 0. I don't know how to parse that last sentence. If there's a change you want made here, please send text. > * This document is marked as obsoleting rfc6810, but it > mandates its use in section 7 ("...the cache MUST downgrade > to protocol version 0 [RFC6810]..."). There are a couple > of paths forward: > > * It seems to me that this document should simply be > called "RPKI to Router Protocol version 1" and not > change the status of rfc6810 - we can always declare > version 0 historic later. > > * If you really want to obsolete version 0, then an > alternative is to eliminate the normative language when > it refers to it... For example, > > * OLD> "If a cache which supports version 1 receives a > query from a router which specifies version 0, the > cache MUST downgrade to protocol version 0 [RFC6810] > or send a version 1 Error Report PDU with Error Code > 4 ("Unsupported Protocol Version") and terminate the > connection." > > * NEW> "If a cache which supports version 1 receives a > query from a router which specifies version 0, the > cache SHOULD send a version 1 Error Report PDU with > Error Code 4 ("Unsupported Protocol Version") and > terminate the connection." The intent is to deprecate version zero, because it lacks features we think are important. But version zero is already in the field and we have no control over how long it will take to upgrade all existing copies. So we have to specify how versions zero and one are intended to interoperate. I don't know how to specify that without normative references to the older version. > 2. Section 7. (Protocol Version Negotiation) Related to the > points above... Are other versions of this protocol expected? No way of knowing, but the users aren't all dead yet, so assume yes. > I know the answer may come from a crystal ball at this > point...but can the process defined here be generalized? The omission was deliberate. We don't know what changes might occur in the future, and while we'd like to think that the version mechanism is sufficiently flexible to handle any likely changes, there is no way to know what backwards compatibility rules might be needed before we know what the associated changes will be. So we deliberately refrained from specifying behavior for any version other than the ones currently assigned, in order to avoid unnecessarily constraining our options in hypothetical future transitions. I expect that any future updates will follow this pattern (saying nothing about future versions, but specifying what to do with all know versions, even if it's just drop or reject stuff older than version N. > 1. Implementation > * In Section 1. (Introduction) you reference rfc7128 for an > implementation report, but that RFC reports on the > implementation of rfc6810, and not this new version. Seems safe to remove that. > * It would be nice to include a section according to rfc6982 > about implementations of this version. Seems a bit late, given that the WG thinks it's done with this already and that section would need to be removed before RFC publication? Don't feel strongly about this, just not sure I see much value. > 2. Section 9. (Transport) I think this sentence is superfluous: > "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or > IPSec transport.", because a couple of paragraphs later the > text also says "...caches and routers MUST use one of the > following more protected protocols" (and the same protocols > are revisited). Seems safe to remove that. Thanks for the review! From nobody Wed Apr 27 05:11:58 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1EF12D7F8 for ; Wed, 27 Apr 2016 05:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 GKmeMVSsgklw for ; Wed, 27 Apr 2016 05:11:55 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B1412D7FA for ; Wed, 27 Apr 2016 05:11:50 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1229C28B003D for ; Wed, 27 Apr 2016 08:11:50 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id F25781F8051; Wed, 27 Apr 2016 08:11:49 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_B28EA346-12D4-42D9-8A70-A1124B29DF80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 27 Apr 2016 08:11:46 -0400 Message-Id: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 12:11:56 -0000 --Apple-Mail=_B28EA346-12D4-42D9-8A70-A1124B29DF80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The authors have requested working group adoption for = draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin = Validation Results from a Route-Server to Peers=94. This message starts an adoption call that will end in two weeks on 11 = May 2016. Please respond on the list to say whether you support adoption of this = work as a working group work item AND whether you will participate in = the discussion. Remember that working group consensus to adopt the work needs responses, = not just absence of objection, so speak up. The draft is available at = https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_B28EA346-12D4-42D9-8A70-A1124B29DF80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXIKyCAAoJEHplpQeet0IZCTUQALO0GkVnhy+8qltCToTq5jat 6M59JGfBmqbDc8Vr150GQZyuZjEgma7FE1nRUVYv+B0qb/IjqDjmCKXUSMUjPHE1 3/Qn2zLb63jApt1it3hyg0UxMgi3tMiHywsM+l2Cc6OlGglizWz9rTwX7ocrEUhv SMLDdVmJabIq3L94ne5rhSn3g6ZyfLkf/peRb9rpitQhmKvM2/ENIlMu5I4I9oLw g4oGAhiF08rjYFomcYugJJPBynQCkAu4YDGk2tAOgctdSZf9v1rVneH4RhCxOojE sy4vA8Xe2Cw/kuayDbXEqBHOjsbwYn06yHmPRDvRpbXenKDXbxyMWrG1K6VyrE9C 3R15Rhrpqtaou7EY7fnoFPCHgMmF1JHaTnbtZjEnJRd59qynUAqI8dftCG6HiFhZ bs5DtlgS+QTdGqUMLkSqEm5bKdj6hnVBL4U8RaIkceSB6oi80NSHk402+lHjYgZo 6Qr7wRdOhb4LOShWnYouWVHGPHZgYY9Y36JR3EZn3zshlW6F2GNF5zhR8rLWxxou ryvcNfOPNcSf3M3+9C9ijWE24jHvtcM7pbjGUCHU5gN1wpiAAulWANx0tKHONPfP XKWjae/QnT0Ha9ZiaYhm+P3Hid63E7ljOjwFaJKhey6sX2Q/nuJitOp8B+fDDtMl QJN8LQFgwMq9EelmL7DI =NgyF -----END PGP SIGNATURE----- --Apple-Mail=_B28EA346-12D4-42D9-8A70-A1124B29DF80-- From nobody Wed Apr 27 07:21:48 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475F512D81A for ; Wed, 27 Apr 2016 07:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 GlHoc1biAdx0 for ; Wed, 27 Apr 2016 07:21:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445A512D80B for ; Wed, 27 Apr 2016 07:21:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1avQLU-0002Vv-Rl; Wed, 27 Apr 2016 14:21:41 +0000 Date: Wed, 27 Apr 2016 23:21:38 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 14:21:47 -0000 > Please respond on the list to say whether you support adoption of this > work as a working group work item yes > AND whether you will participate in the discussion. i see no need to answer randy From nobody Wed Apr 27 07:42:13 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ED112D835 for ; Wed, 27 Apr 2016 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2NhSbaiMU6V for ; Wed, 27 Apr 2016 07:42:10 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0126.outbound.protection.outlook.com [23.103.201.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0579E12D83A for ; Wed, 27 Apr 2016 07:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ooiyQ1oddexCo97G+vYvH8qctcm2r2XHjmQRpI5nRNk=; b=C8r+tVkrlUVFZOew8TX5prxB7w+b46258nUwGj2By9AFkAj39cRCp2mU+xZqb7x4buIIKzD2Kd495zYf5bYMEwxFFw0tF5OyozkfieibRbEkZ7sahWg97m2/LJs47oCU00kkep2cs1O73oBYI64PdC68cleomr3AcW47HOIa5t4= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1121.namprd09.prod.outlook.com (10.167.102.149) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 27 Apr 2016 14:42:08 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0477.012; Wed, 27 Apr 2016 14:42:08 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Sandra Murphy , sidr Thread-Topic: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 Thread-Index: AQHRoH4CV9vVO2li2USxJ9/ThUA4kp+d5AIg Date: Wed, 27 Apr 2016 14:42:08 +0000 Message-ID: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tislabs.com; dkim=none (message not signed) header.d=none;tislabs.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 0e092c1f-34cf-4bfb-0a4a-08d36eaa1c31 x-microsoft-exchange-diagnostics: 1; BL2PR09MB1121; 5:xW8/Kqf76SG9LBpf91KZTNhee6GWbSPShr2TRwAn94bM+QD8W4tN+JTcJbKxQNfHRpoPrAS7BLc5PejJZSL/1C9n831shM31FegFlLVr+vrUS+Vpq6DgM/QRYQi5skhDcxsbn4PIMaBIMGWShPen3w==; 24:GDLChAAZa0cJvVsT0qSGCq8P79KMJnzw8NbS8iQIImA2n/yx7o5BdmhhHUAytHULIw9n5XN/2hOEpaA9v8QBoe10um038khHYZxTwg+xtHs=; 7:V8nGn5Te7sx/HKTBR72xU2AbFqt0QIxuH2Cp1qe5gtV9UN5jKMdMbKWSjTDGkyZJXLDQQZ3x3EVdFI4/Tm88citCwfdWMzOqBv5XL/9pqNFVXzcINVW5xCAt/RtCy0lmsCxr8gVj7dv1ehTdbbpzmbd2fzrfs90zalnBtkfJWxowDgTB9P4eBhBi+bapRhtM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BL2PR09MB1121; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1121; x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54356999)(92566002)(2950100001)(77096005)(2900100001)(10400500002)(33656002)(558084003)(76176999)(50986999)(74316001)(87936001)(122556002)(86362001)(66066001)(5008740100001)(99286002)(5002640100001)(76576001)(3660700001)(230783001)(5003600100002)(3280700002)(2906002)(106116001)(1096002)(189998001)(81166005)(11100500001)(6116002)(102836003)(5004730100002)(1220700001)(3846002)(9686002)(586003)(5001770100001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1121; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2016 14:42:08.1624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1121 Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 14:42:11 -0000 >Please respond on the list to say whether you support adoption of this wor= k as a working group work item AND whether you will participate in the disc= ussion. yes and yes Sriram From nobody Thu Apr 28 02:11:22 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B8D12D5ED for ; Thu, 28 Apr 2016 02:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yo0hB1rNnAg for ; Thu, 28 Apr 2016 02:11:18 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E9A12D5A8 for ; Thu, 28 Apr 2016 02:11:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,546,1454972400"; d="scan'208";a="2829296" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP; 28 Apr 2016 11:11:14 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 612B1B009D for ; Thu, 28 Apr 2016 11:11:14 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 28 Apr 2016 11:11:14 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Thu, 28 Apr 2016 11:11:14 +0200 From: Thomas King To: sidr Thread-Topic: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 Thread-Index: AQHRoH4Cqkdkw603GEe1x7bLBM6xt5+fGtaA Date: Thu, 28 Apr 2016 09:11:13 +0000 Message-ID: <236C3CFD-BA4B-4839-976C-AADC1ED7A34D@de-cix.net> References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> Accept-Language: en-US, de-DE 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: [192.168.140.84] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 09:11:21 -0000 WWVzIGFuZCB5ZXMuDQoNCihJIGFtIG9uZSBvZiB0aGUgYXV0aG9ycykuDQoNCkJlc3QgcmVnYXJk cywNClRob21hcw0KDQoNCg0KT24gMjcvMDQvMjAxNiwgMTQ6MTEsICJzaWRyIG9uIGJlaGFsZiBv ZiBTYW5kcmEgTXVycGh5IiA8c2lkci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzYW5k eUB0aXNsYWJzLmNvbT4gd3JvdGU6DQoNCj5UaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCB3b3Jr aW5nIGdyb3VwIGFkb3B0aW9uIGZvciBkcmFmdC1ra2xmLXNpZHItcm91dGUtc2VydmVyLXJwa2kt bGlnaHQtMDEsICJTaWduYWxpbmcgUHJlZml4IE9yaWdpbiBWYWxpZGF0aW9uIFJlc3VsdHMgZnJv bSBhIFJvdXRlLVNlcnZlciB0byBQZWVyc+KAnS4NCj4NCj5UaGlzIG1lc3NhZ2Ugc3RhcnRzIGFu IGFkb3B0aW9uIGNhbGwgdGhhdCB3aWxsIGVuZCBpbiB0d28gd2Vla3Mgb24gMTEgTWF5IDIwMTYu DQo+DQo+UGxlYXNlIHJlc3BvbmQgb24gdGhlIGxpc3QgdG8gc2F5IHdoZXRoZXIgeW91IHN1cHBv cnQgYWRvcHRpb24gb2YgdGhpcyB3b3JrIGFzIGEgd29ya2luZyBncm91cCB3b3JrIGl0ZW0gQU5E IHdoZXRoZXIgeW91IHdpbGwgcGFydGljaXBhdGUgaW4gdGhlIGRpc2N1c3Npb24uDQo+DQo+UmVt ZW1iZXIgdGhhdCB3b3JraW5nIGdyb3VwIGNvbnNlbnN1cyB0byBhZG9wdCB0aGUgd29yayBuZWVk cyByZXNwb25zZXMsIG5vdCBqdXN0IGFic2VuY2Ugb2Ygb2JqZWN0aW9uLCBzbyBzcGVhayB1cC4N Cj4NCj5UaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ra2xmLXNpZHItcm91dGUtc2VydmVyLXJwa2ktbGlnaHQtMDENCj4NCj7igJRTYW5k eSwgc3BlYWtpbmcgYXMgb25lIG9mIHRoZSB3ZyBjby1jaGFpcnMNCj4NCj4NCg== From nobody Thu Apr 28 03:21:19 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86A312D63B for ; Thu, 28 Apr 2016 03:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 c35I3LECNpCq for ; Thu, 28 Apr 2016 03:21:15 -0700 (PDT) Received: from exchange.ip-it.com (exchange.ip-it.com [185.54.144.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429D712D63A for ; Thu, 28 Apr 2016 03:21:14 -0700 (PDT) Received: from exchange.ip-it.com (185.54.144.4) by exchange.ip-it.com (185.54.144.4) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 28 Apr 2016 12:21:08 +0200 Received: from exchange.ip-it.com ([fe80::9052:900b:8ae0:9469]) by exchange.ip-it.com ([fe80::9052:900b:8ae0:9469%13]) with mapi id 15.00.0913.011; Thu, 28 Apr 2016 12:21:08 +0200 From: Bernd Spiess To: "sidr@ietf.org" Thread-Topic: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 Thread-Index: AQHRoH4Cqkdkw603GEe1x7bLBM6xt5+fG2OAgAASQPA= Date: Thu, 28 Apr 2016 10:21:08 +0000 Message-ID: References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2a01:100:1006:1337:744b:1c5b:882a:7b5c] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0105_01D1A148.5D93F570" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 10:21:18 -0000 ------=_NextPart_000_0105_01D1A148.5D93F570 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi all, I support this Internet draft to be adopted as GROW working group document. Best regards, Bernd Spiess Bernd SPIESS Mobile: +43 676 848267 401 Email: bernd.spiess@ip-it.com ip-it consult GmbH Am Birkengrund 10, A-9073 Klagenfurt FN: 411144z / LG Klagenfurt / ATU 68538567 www.ip-it.com ------=_NextPart_000_0105_01D1A148.5D93F570 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQazCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggYJMIIE8aADAgECAhB0t4ndpdoVq5gErPTuej81MA0G CSqGSIb3DQEBCwUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRp b24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0EgLSBHNTAeFw0xNTExMDUwMDAwMDBaFw0xNjA3MDIyMzU5NTlaMIGpMS4wLAYDVQQDDCVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAxNDQ2NzE4MjUxNjkzMSUwIwYJKoZIhvcNAQkBFhZiZXJu ZC5zcGllc3NAaXAtaXQuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAKNthMO8ytFRrvmlRJcz9wdB/7nPYZZkbT6t18fhJSVcz11QXrz6 pPUrvyb4GvAS7d1Zku+Sc4N3TGvoDKQoW+sgoFaMSM6hccO9AYLv176teIq3nP8of3nlhG/6jFrF iYjvz2ryMzCHfQXoOgwSwfn2ET/WU9cw7TlCvbJy+Klv6VCfsRMtE0Wqsr5liRseKRem122qlG8i NP1qEaLt+5k3AJLsyaSY8Q6zXdINkJeoVjWrAIoVW74PJr8NxZRGYmngGAwK7ONZYSme3MpQ7jWB nxO8mifHzUZR/NQinNef90Rm0QR8gWWPpsu5DDxeF1MMY76MZE8WeBRpkzTmIeMCAwEAAaOCAiww ggIoMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjAdBgNVHQ4EFgQUYl3aeAbrsqhAfXNLz3WPCQ44ZHowIQYDVR0RBBowGIEWYmVy bmQuc3BpZXNzQGlwLWl0LmNvbTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUH AgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGgu Y29tL2NhXzU3ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYI KwYBBQUHAQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9z eW1jYzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBCwUA A4IBAQB+mi1fMjriQ6g9lcZWwcEP6YLE4y4sgK0PQGkLrgEcMafNRXv6qKcG64dUc9WE39zc4J9c 9YxvYwJb+a+bBVMv4CZ/y8hbzLiRhwjagxldzuc5SFjBWc0fd+J2AWBB8ahEGATgdBmfhVE0oAzl UUI5mREcDdM2qksJgfTA6u6IU7dNi+6HRHfThw1L2AedlS5Y0kGEnaYXP5J4m3d14ChrzgKtG1Pg IVEmvAJJgxnL6NegyKmhczqmU0XS6ufzAx7z71uw99xS2Sd9MLCfsBC5woN3CafS/ISZvPlLrQxv Weo0f078dulSZEvBJfPfnATjJSsOCWAlMJmAAL5RCIEIMIIGPDCCBSSgAwIBAgIQBwKiGoW4S2We GApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5 OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp U2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMw HhcNMTUxMDAxMDAwMDAwWhcNMjUwOTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEg SW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDW+w0xSSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5u lpJE7hW5tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvp Tpli/pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqyL/g9 zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3BggrBgEFBQcB AQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTASBgNVHRMBAf8E CDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNv bS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2IuY29tL3BjYTEtZzMuY3JsMA4G A1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRU3ltYW50ZWNQS0ktMi0yMTcw HQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9y aXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0B AQsFAAOCAQEARhnkJ3U7vq/i2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/Y ySp6DlSmg64pSvYrUf09OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK 9qkUAK1+WVUaiSfblKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml 3NkI85CrdHCryqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/y xd9aq7dryru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBHowggR2AgEBMIG7MIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQdLeJ3aXa FauYBKz07no/NTAJBgUrDgMCGgUAoIICkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjA0MjgxMDIwMzVaMCMGCSqGSIb3DQEJBDEWBBQJFcWuqDBxsViM4NFBw2Cl qOrfijCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBzAYJKwYBBAGCNxAEMYG+ MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NQIQdLeJ3aXaFauYBKz07no/NTCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRl YyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhB0t4ndpdoVq5gErPTuej81 MA0GCSqGSIb3DQEBAQUABIIBAHDER5NkYJ/pGMt9C7tRSQZ/YO/+We7Ikl51LyRcJNTrUE0/PJNu tiChX8JS48ZJsLGTIrdAztbktLaqXvGWBbgsjGsNcRGd+atTbGBMm9AX3g3lQhCgkDgrZ1aj9Y/+ QO08hkMS4UD0MStnmmyOxKrsoAaEaxo0FRvw9JTy41rxALgTCeePFD1dbsjR91ExPhtmFCUHATlD 1lNGsgT6GQBlDiswtPGdDATtfaI6pQLorjcWu2L0A/kXPu1GioUKzclV5n4dr87SxrUo3myxaSZl xEKDWSzJbkyunP0GImAtwAH0++QSd2x0qJzEa4SqJgcoKu5RUemYeUgaBRS4BgIAAAAAAAA= ------=_NextPart_000_0105_01D1A148.5D93F570-- From nobody Thu Apr 28 03:57:12 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DEA12D66D for ; Thu, 28 Apr 2016 03:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 fwZtLGkCE2DY for ; Thu, 28 Apr 2016 03:57:09 -0700 (PDT) Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF61F12D66C for ; Thu, 28 Apr 2016 03:57:05 -0700 (PDT) Received: from m2.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m2-bn.bund.de (8.14.5/8.14.5) with ESMTP id u3SAv3uo019955 for ; Thu, 28 Apr 2016 12:57:03 +0200 (CEST) Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 5/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Thu Apr 28 12:57:03 2016 X-P350-Id: 390f63e243c0cec2 X-Virus-Scanned: amavisd-new at bsi.bund.de X-Virus-Scanned: by amavisd-new at bsi.bund.de From: "de =?utf-8?q?Br=C3=BCn?=, Markus" Organization: BSI Bonn To: sidr@ietf.org Date: Thu, 28 Apr 2016 12:56:45 +0200 User-Agent: KMail/1.9.10 (enterprise35 20141209.f66ef9b) References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> In-Reply-To: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <201604281256.45988.markus.debruen@bsi.bund.de> Archived-At: Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 10:57:11 -0000 I support adoption and will participate in discussion. Cheers, Markus __________ urspr=C3=BCngliche Nachricht __________ Von: Sandra Murphy Datum: Mittwoch, 27. April 2016, 14:11:46 An: sidr Kopie: Sandra Murphy Betr.: [sidr] working group adoption call for=20 draft-kklf-sidr-route-server-rpki-light-01 > The authors have requested working group adoption for > draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin > Validation Results from a Route-Server to Peers=E2=80=9D. > > This message starts an adoption call that will end in two weeks on 11 May > 2016. > > Please respond on the list to say whether you support adoption of this wo= rk > as a working group work item AND whether you will participate in the > discussion. > > Remember that working group consensus to adopt the work needs responses, > not just absence of objection, so speak up. > > The draft is available at > https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01 > > =E2=80=94Sandy, speaking as one of the wg co-chairs =2D-=20 Markus de Br=C3=BCn Bundesamt f=C3=BCr Sicherheit in der Informationstechnik (BSI) =46ederal Office for Information Security, Germany Phone: +49 228 9582 5336 Mail: markus.debruen@bsi.bund.de From nobody Thu Apr 28 16:00:04 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C812B038 for ; Thu, 28 Apr 2016 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3OOlhHq3U12 for ; Thu, 28 Apr 2016 16:00:00 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [203.119.110.25]) (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 62A4612D55B for ; Thu, 28 Apr 2016 15:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:received:date:from:to:cc:subject:message-id: mail-followup-to:references:mime-version:content-type:content-disposition: in-reply-to:user-agent:return-path; bh=PCi41aMzEmmnYsILpOAtVHMiBQ9VIeMJPm8dlTApRZc=; b=gmAP9VAzQKQx7NHNi2W2SlltwB2mvCJeVVUZ+koAOknfz/Z2/3NQe9vhUxjWh/a443I4VWEn7v7SE tBmceQChOZ2oEKazQpHK9JiU9FpwBoEKTZzBwVVqXjohVcPxKGUUCEXzogl+GTiQXDB5BYwCn5dphm Te1YGvPs3OsgxdSs= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 29 Apr 2016 08:59:59 +1000 (AEST) Received: from main (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 29 Apr 2016 08:54:51 +1000 Received: from tomh by main with local (Exim 4.87) (envelope-from ) id 1avupf-0000OY-JP; Fri, 29 Apr 2016 08:54:51 +1000 Date: Fri, 29 Apr 2016 08:54:51 +1000 From: Tom Harrison To: Message-ID: <20160428225451.GE123284@main> Mail-Followup-To: ietf@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org Subject: Re: [sidr] Last Call: (Securing RPSL Objects with RPKI Signatures) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 23:00:02 -0000 Section 5 requires that an EE certificate be used for the signing of the RPSL object. An EE certificate must contain an SIA extension that points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does not define a profile for a new type of object, or specify an existing one that may be used instead. There are a number of ways to deal with this: for example, by defining a new profile and changing the signature URL to suit, or by amending RFC 6487 such that object pointers in EE certificates are optional. Section 4 specifies sets of attributes that must be signed. 'org' is included as one of these attributes for the as-block, inet[6]num, and route[6] object types. However, 'org' is not defined in either of the principal RPSL RFCs (2622 and 4012), and there are current implementations (e.g. APNIC's) that do not support it. I think the references to 'org' should be omitted. Section 4 specifies 'signature' as an attribute that must be signed. 'signature' can appear multiple times in a single object, where e.g. two different resource holders sign a route[6] object. Given that the text doesn't explicitly state that only the newest 'signature' must be signed, it would appear to require that any extant 'signature' attributes be signed as well. That in turn would prevent previous signers from re-signing the object independently of the subsequent signers. I think the text should be changed so that only the new signature attribute need be signed. Section 2.4 requires that "the Internet number resources present in [RFC3779] extensions of the certificate referred to in the "c" field of the signature must cover the resources in the primary key of the object". This means that it's not possible to sign a route[6] object for a route where one resource holder has the ASN and another the prefix. In revision 8 (and earlier), the possibility of there being multiple signatures, each with a certificate covering a subset of the primary key resources, was explicitly permitted. I think that the previous text here should be restored. (The above points were the product of much discussion of this draft with Tim and Oleg from RIPE, not that I'm speaking for them. We were able to write interoperable prototype signer/validator implementations, so the document is in pretty good shape on the whole.) -Tom From nobody Sat Apr 30 07:04:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305C812B05C for ; Sat, 30 Apr 2016 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYez6LLmmYvM for ; Sat, 30 Apr 2016 07:04:34 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB18312D0AF for ; Sat, 30 Apr 2016 07:04:34 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0CDC328B003D; Sat, 30 Apr 2016 10:04:34 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E0B061F8051; Sat, 30 Apr 2016 10:04:33 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Apr 2016 10:04:32 -0400 Message-Id: To: sidr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sandra Murphy Subject: [sidr] IETF 95 meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 14:04:36 -0000 The minutes takers in Bueno Aires used the etherpad which is a great = thing and you all have had the opportunity to view it. But the etherpad = will eventually be erased. I have uploaded the etherpad contents as the proceeding=92s minutes. = https://www.ietf.org/proceedings/95/minutes/minutes-95-sidr I added the time in the Meetecho recording at the agenda slots, so if = you want to check something you don=92t have to listen to the entire = recording. I did some minor editing for missing names and such. Please do take a look at the minutes and report errors or omissions to = the mailing list. Thanks very much to Sue and Sriram for volunteering! It is very much = appreciated. =97Sandy