From nobody Wed Dec 6 06:00:07 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9C128B27 for ; Wed, 6 Dec 2017 06:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 eNwnrEWV3gL1 for ; Wed, 6 Dec 2017 06:00:02 -0800 (PST) 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 F0CA8128B51 for ; Wed, 6 Dec 2017 06:00:01 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eMaEx-0007gx-MG; Wed, 06 Dec 2017 15:00:00 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-21.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eMaEx-0003Ig-G9; Wed, 06 Dec 2017 14:59:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Tim Bruijnzeels In-Reply-To: <20171116103441.GB7247@tomh-laptop> Date: Wed, 6 Dec 2017 14:59:51 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151064401825.5985.7789265592065530099@ietfa.amsl.com> <20171116103441.GB7247@tomh-laptop> To: Tom Harrison X-Mailer: Apple Mail (2.3445.4.7) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719304fdb411940db1f40e28b5a795e0e82 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 14:00:05 -0000 Hi Tom, Thank you for your reply. I have been side-tracked for a bit, but let me = comment :) > On 16 Nov 2017, at 11:34, Tom Harrison wrote: >=20 > On Mon, Nov 13, 2017 at 11:20:18PM -0800, internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIDR Operations WG of the IETF. >>=20 >> Title : RPKI signed object for TAL >> Authors : Tim Bruijnzeels >> Carlos Martinez >> Filename : draft-ietf-sidrops-signed-tal-00.txt >> Pages : 10 >> Date : 2017-11-13 >=20 > We've done a fairly basic proof-of-concept implementation of this as > an extension to our RPKI system. The core of it looks good and > functions as expected. Some questions and minor suggestions (all > IMHO): >=20 > Having explicit structure in the SignedTalContent definition would > make implementation a little easier. It would also remove any > possible confusion about whether the public key need be base64-encoded > again (the current text appears to require that). I agree that the double encoding is probably not needed. I hoped to = avoid any chance of having character in the =E2=80=98eContent=E2=80=99 = part that could cause issue. But.. just shooting for encoding again for = good measure was a bit of lazy thinking here.. we don=E2=80=99t need = this for the XML messages in RFC6492 (provisioning) and RFC8181 = (publication) either, so I think we should be safe. There is no structure at the moment because we wanted to use the TAL = format as-is. That said, I think that there may be merit in an explicit json, or XML = (to be consistent with 6492 and 8181) format, e.g.: https://rpki.example.org/rpki/hedgehog/root.cer rsync://rpki.example.org/rpki/hedgehog/root.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB A structure like this will make it easier to add tags or attributes to = communicate other things. See below. > Section 3.3 has "[i]f the above procedure indicates that the manifest > is invalid". It looks like it should be "...that the Signed TAL is > invalid". >=20 > Section 4 has "[t]his EE certificate MUST have a "notBefore" time that > is before the moment that the Signed TAL will be published". Why is > this a MUST? I can imagine somebody prepublishing the new TAL, but > not wanting RPs to switch over until the notBefore time had been > reached, though I guess that would also lead to validation errors for > RPs in the interim due to the object not being in-date. It=E2=80=99s a MUST because otherwise the object is invalid. If we need an explicit staging time, rather than require this implicitly = by publishing it, then I think we are better off with a valid object and = an XML structure like above with an additional tag like: 2019-01-01T00:00:00.000Z > Regarding signed TAL EE certificate validity periods generally, I > think it would be good to add some text about how the new TAL becomes > 'effective' as soon as it is published, and that neither revocation > nor expiry of the associated EE certificate has any implications in > that respect (even though this is implicit from the document as a > whole). True. Whether it=E2=80=99s done implicitly by publishing the signed TAL = (as the document says now), or some explicit tag is = introduced: there is a point of no return by which RPs will have moved = over. And thinking about this a bit more I believe that there should also be = text that forbids a Trust Anchor from pointing RPs back to a previous = key. We should only roll forward. > Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old key > after the staging period as a hint for RPs that missed the key roll". > Although (I think) the only sensible way to read this is that the > signed TAL to which this is referring is that pointing to the new TA, > "for the old key" might make people think the signed TAL should be for > the deprecated key instead. Something like "[t]he TA SHOULD preserve > the Signed TAL pointing to the new TA after the staging period..." > could work. So, here there is a lot of implicit stuff again. We could also think of this differently.. maybe extending the structure = to something like this could help: MIIBIjANBgk=E2=80=A6 MIIBIjdfkhjfd=E2=80=A6 https://rpki.example.org/rpki/hedgehog/root.cer rsync://rpki.example.org/rpki/hedgehog/root.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB This way we can communicate explicitly which previous keys have been = expired. And what the current key is at the time of publishing this. If this is published by old keys in the form of long-lived objects and = CRLs, then RPs could still find their way to the current key. An = argument can also be made that RPs should not care about staleness of = MFT/CRL or expired MFT/TAL EE certificates in this case. > I think 24 hours for the staging period is too short, mainly because > people who don't update their validators to support this may not take > action on the new validation error (something like "unknown type of > object: {name}.tal") within that short a time period. Okay, it=E2=80=99s not clear to me that this is related to the staging = period. But, before any of this could be deployed we do need to be sure that RP = software can be upgraded to support it, or at least not choke on it. If = people do not upgrade their RP software they can still find out that a = new TAL should be used through other means (e.g. mailing lists). And let = me be devil=E2=80=99s advocate here.. if people never, ever upgrade = their RP software, then breaking it and forcing them to upgrade could be = considered a feature by some. Of course, after a reasonable time.. > There are also > other instances like this where manual action might be required, e.g. > where operations staff insist that the validator not have write access > to its configuration and that all updates happen manually. A week or > a month as a mandatory period would be better. I believe that we should insist that key rolls like this are fully = automated and not done manually. I also believe that it would be prudent = that if && when we agree on a mechanism for this, it is done regularly - = at least in some environments to ensure that this works. In short: I = think a planned key roll, signed by a trusted TA, should be a normal = thing. If we leave this as paperware then there will be no guarantee = that it works when we need it. One more thing I wanted to bring up is unplanned key rolls. There may be = merit in having a tag in the structure, like this: MIIBIjANBgk=E2=80=A6 MIIBIjdfkhjfd=E2=80=A6 =E2=80=A6 this key.. standby https://rpki.example.org/rpki/hedgehog/root.cer rsync://rpki.example.org/rpki/hedgehog/root.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB This could alert RPs that a new key exists. It in turn can publish the = same signed TAL structure - confirming that this staging key is not in = use yet. If and when the old key needs to be replaced and the TA = operator lost access to its key, then the staging key can publish a = structure where the old key appears in the list instead.. in = other words it=E2=80=99s empowered to revoke the =E2=80=9Ccurrent=E2=80=9D= key. If access to the =E2=80=9Cstaging" key is lost, then the = =E2=80=9Ccurrent=E2=80=9D key can just remove the section, or = replace it with another staging key. The risk here is that if the new key goes rogue it can revoke the = current key. I don=E2=80=99t think that this is a bigger risk than the = current key going rogue. The advantage is that there is a back-up key = and in a TA can recover if they lose access to either the current, or = the staging key. If Hardware Security Modules (HSMs) are used, the risk = of key theft can be mitigated to a very large degree - typically keys = are protected by an N out of M card set where a quorum of people are = needed to use the key, or migrate it into new hardware. But, losing = keys, broken cards, and sadly loosing people, are real threats that can = lead to situations where a TA no longer has a quorum. Obviously the above is not worked out in full detail, but I would = welcome discussion on the direction. And as a final thought.. it would = be good if the planned and unplanned key roll processes are similar. Thanks Tim >=20 > -Tom >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Wed Dec 6 12:12:01 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13391124207 for ; Wed, 6 Dec 2017 12:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq8WNuAWAipC for ; Wed, 6 Dec 2017 12:11:41 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE60712426E for ; Wed, 6 Dec 2017 12:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12081; q=dns/txt; s=iport; t=1512591101; x=1513800701; h=from:to:cc:subject:date:message-id:mime-version; bh=BcKzdMeSqvYwyOmp6ZgyLkPPwopHk8UHjAfo5xzJtVo=; b=Ki+gWGmBf1xNBKufusemR1O1UG68tw60q/XEBzz+vaaqXvAgZVCsUxRm nZmMl9bDb/WhH7G54dfiSHGbSt6wrwvM9p54SB2xcRMyzVUMuNqxCQU3k ZpYiUt9DA1fP1PK1E6t6DCMsLNwB97rV/5SvF9XTx4C8poLqOa53FRY/b I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AQCMTiha/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKc2ZwJ4QCiiCOe4F9kTqFSxSCAQoYAQqESU8CGoU6PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAwEBASEKQQsFDQEIEQMBAgEqAgQlCx0KBA4FCIk3XAgQq?= =?us-ascii?q?H2CJ4pWAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWFXIFWgWmDK4FJgyBPCYJ1gkM?= =?us-ascii?q?gBYhfmh4Ch3SNGoIfhhGLNIo+gkOJJQIRGQGBOQEfOYFObxU6gimCUhyBZ3gBh?= =?us-ascii?q?yYsghoBAQE?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208,217";a="332309894" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 20:11:26 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB6KBPGh000742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 20:11:25 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 15:11:24 -0500 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.1320.000; Wed, 6 Dec 2017 15:11:24 -0500 From: "Roque Gagliano (rogaglia)" To: Tim Bruijnzeels CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption Thread-Index: AQHTbs5kZfQ1pDjfNk6F/uX9XSbmLg== Date: Wed, 6 Dec 2017 20:11:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_a1ca5abc5f21482caa634126e99c123aXCHRTP011ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 20:11:52 -0000 --_000_a1ca5abc5f21482caa634126e99c123aXCHRTP011ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltLA0KDQpJTUhPLCBJZiBpdCByZXBsYWNlcyByYXRoZXIgdGhhbiBjb21wbGVtZW50cywg aXQgc2hvdWxkIGJlIG9ic29sZXRlcy4NCg0KSSBndWVzcyB0aGVyZSBpcyBhIGZvcm1hbCBkZWZp bml0aW9uIHNvbWV3aGVyZS4NCg0KUm9xdWUNCg0KDQoNCg0KU2VudCBmcm9tIG15IFNhbXN1bmcg R2FsYXh5IHNtYXJ0cGhvbmUuDQoNCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0N CkZyb206IFRpbSBCcnVpam56ZWVscyA8dGltQHJpcGUubmV0Pg0KRGF0ZTogMTEvMzAvMTcgMTQ6 MzkgKEdNVCswMTowMCkNClRvOiAiUm9xdWUgR2FnbGlhbm8gKHJvZ2FnbGlhKSIgPHJvZ2FnbGlh QGNpc2NvLmNvbT4NCkNjOiBzaWRyb3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NpZHJvcHNd IERvY3VtZW50IG9uIEhUVFBTIG9uIFRBTHMgKHVwZGF0ZSB0byBSRkM3NzMwKSAtIHNlZWtpbmcg YWRvcHRpb24NCg0KDQo+IE9uIDMwIE5vdiAyMDE3LCBhdCAxNDozMSwgUm9xdWUgR2FnbGlhbm8g KHJvZ2FnbGlhKSA8cm9nYWdsaWFAY2lzY28uY29tPiB3cm90ZToNCj4NCj4gSGkgVGltLA0KPg0K PiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2h5IHlvdSBhcmUg4oCcdXBkYXRlc+KAnSBSRkMgNzcz MCBhbmQgbm90IOKAnG9ic29sZXRlc+KAnSBSRkM3NzMwLiBDb3VsZCB5b3UgcGxlYXNlIGVsYWJv cmF0ZSBvbiB0aGlzIGRlY2lzaW9uPw0KDQpJIGJlbGlldmUgeW914oCZcmUgcmlnaHQgYW5kIGl0 IHNob3VsZCBpbmRlZWQgc2F5IOKAmG9ic29sZXRlc+KAmSAtIGFzIGluIHJlcGxhY2VzIC0gcmF0 aGVyIHRoYW4gdXBkYXRlcyAocGFydHMpIG9mIGl0LiBUaGF0IHNhaWQsIG1vc3Qgb2YgdGhlIHRl eHQgaXMgYSBzdHJhaWdodCBjb3B5IG9mIHRoZSB0ZXh0IGluIDc3MzAuDQoNClRpbQ0KDQoNCj4N Cj4gUmVnYXJkcywNCj4gUm9xdWUNCj4NCj4NCj4gT24gMzAvMTEvMTcgMTQ6MDIsICJTaWRyb3Bz IG9uIGJlaGFsZiBvZiBUaW0gQnJ1aWpuemVlbHMiIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIHRpbUByaXBlLm5ldD4gd3JvdGU6DQo+DQo+ICAgIERlYXIgd29ya2luZyBn cm91cCwNCj4NCj4gICAgQXMgZGlzY3Vzc2VkIGF0IElFVEY5OSwgYW5kIGluIGluZm9ybWFsIHRh bGtzIHdpdGggc29tZSBvZiB5b3UsIHdlIHdvdWxkIGxpa2UgdG8gdXBkYXRlIHRoZSBUQUwgZm9y bWF0IChSRkM3NzMwKSB0byBhbGxvdyBIVFRQUy4NCj4NCj4gICAgSSB3b3JrZWQgd2l0aCBHZW9y Z2UgTWljaGFlbHNvbiBvbiBhbiB1cGRhdGUuIEJlY2F1c2UgUkZDNzczMCBjb250YWlucyBxdWl0 ZSBhIGZldyByZWZlcmVuY2VzIHRvIOKAmHJzeW5j4oCZIHdlIGZlbHQgdGhhdCBhIG5ldyBkb2N1 bWVudCB1cGRhdGluZyA3NzMwIHdvdWxkIGJlIG1vcmUgcmVhZGFibGUgYW5kIGFwcHJvcHJpYXRl IHRoZW4gZG9jdW1lbnQgdXBkYXRpbmcgbWFueSBzbWFsbCBiaXRzIG9mIHRleHQuIFRoZSAtMDAg dmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGlzIGhlcmU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dA0KPg0KPiAgICBX ZSB3b3VsZCBsaWtlIHRvIGFzayB0aGUgY28tY2hhaXJzIHRvIG1ha2UgYSBjYWxsIHRvIHRoZSB3 b3JraW5nIGdyb3VwIGZvciBhZG9wdGlvbi4NCj4NCj4gICAgSW4gc2hvcnQgdGhpcyB1cGRhdGUg d2lsbCBhbGxvdyB0aGUgdXNlIG9mIEhUVFBTIGluc3RlYWQgb2YsIG9yIGluIGFkZGl0aW9uIHRv LCByc3luYyBvbiBUQUxzLiBPdGhlciB0aGFuIHRoYXQgaXQgY29udGFpbnMgYSBzZWN0aW9uIG9u IFRMUyB2ZXJpZmljYXRpb24gc2ltaWxhciB0byB0aGUgb25lIHRoYXQgaXMgaW5jbHVkZWQgaW4g dGhlIGRlbHRhIHByb3RvY29sIChSRkM4MTgyKSAtIGVzc2VudGlhbGx5IHNheWluZyB0aGF0IFRM UyB2ZXJpZmljYXRpb24gaXMgZG9uZSBvbiBhIGJlc3QgZWZmb3J0IGJhc2lzIC0gYW5kIHdhcm5p bmdzIHNob3VsZCBiZSB1dHRlcmVkIGluIGNhc2Ugb2YgaXNzdWVzIC0gYnV0IGJlY2F1c2UgdGhl IFRBIGNlcnRpZmljYXRlIGNhbiBzdGlsbCBiZSB2YWxpZGF0ZWQgY3J5cHRvZ3JhcGhpY2FsbHkg aXQgTVVTVCBzdGlsbCBiZSBkb3dubG9hZGVkLiBOb3RlIHRoYXQgaXQgaXMgYSBtYXR0ZXIgb2Yg bG9jYWwgcG9saWN5IHdoZXRoZXIgYW4gUlAgY2hvb3NlcyB0byB1c2UgZGlmZmVyZW50IGxvY2F0 aW9ucyBpZiB0aGV5IGFyZSBwcmVzZW50LCBidXQgd2UgbWF5IHdhbnQgdG8gYWRkIHNvbWUgdGV4 dCBoZXJlIHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEhUVFBTIFVSSXMgdGhhdCBoYXZlIG5vIFRM UyB2ZXJpZmljYXRpb24gaXNzdWVzIG92ZXIgb25lcyB0aGF0IGRvIC0gYXQgdGhpcyBwb2ludCBJ IGFtIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyBuZWVkZWQsIG9yIHdvdWxkIG5lZWQgdG8gYmUgbm9y bWF0aXZlIHRleHQsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21lIGRp c2N1c3Npb24gb24gdGhpcy4NCj4NCj4gICAgRm9yIHRoZSByZWNvcmQsIEkgYW0gbm90IHN1cmUg d2hhdCBpcyBjdXN0b21hcnkgaW4gdGhlc2UgY2FzZXMgb2YgcmVsYXRpdmVseSBzbWFsbCB1cGRh dGVzIHRvIGV4aXN0aW5nIHN0YW5kYXJkcy4gQnV0LCBJIHRyaWVkIHRvIGFwcHJvYWNoIHRoZSBv dGhlciBhdXRob3JzIG9mIFJGQzc3MzAgKEdlb3JnZSBpcyBhbHJlYWR5IG9uZSBvZiB0aGVtKSBh bmQgYXNrIHRoZW0gd2hldGhlciB0aGV5IHdhbnQgdG8gcmVtYWluIGF1dGhvcnMgb24gdGhpcyBu ZXcgZG9jdW1lbnQuIEdlb2ZmIEh1c3RvbiBpbmRpY2F0ZWQgdGhhdCBoZSBkb2VzIG5vdCBuZWVk IHRvIGJlIG9uIHRoZSBsaXN0LCBidXQgaGFzIG5vIG9iamVjdGlvbnMgdG8gdXMgZG9pbmcgdGhp cyB3b3JrLiBJIGhhdmUgbm90IHNlZW4gcmVzcG9uc2VzIGZyb20gU2FtIFdlaWxlciBvciBTdGVw aGVuIEtlbnQgLSBpdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgdGhleSBtaXNzZWQgbXkgbWVzc2Fn ZS4gSW4gYW55IGNhc2Ugd2UgaGF2ZSBubyBvYmplY3Rpb25zIGlmIHRoZXkgZG8gd2lzaCB0byBz dGF5IG9uIGFzIGF1dGhvcnMsIGJ1dCBmb3Igbm93IHRoZXkgYXJlIG5vdCBvbiB0aGUgbGlzdCBv ZiB0aGUgZG9jdW1lbnQgbGlua2VkIGFib3ZlLg0KPg0KPiAgICBLaW5kIHJlZ2FyZHMsDQo+DQo+ ICAgIFRpbQ0KPg0KPg0KPg0KPg0KPiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiAgICBTaWRyb3BzIG1haWxpbmcgbGlzdA0KPiAgICBTaWRyb3Bz QGlldGYub3JnDQo+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lk cm9wcw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBTaWRyb3BzIG1haWxpbmcgbGlzdA0KPiBTaWRyb3BzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KDQo= --_000_a1ca5abc5f21482caa634126e99c123aXCHRTP011ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7DF2ECA1DB0A0E43AB49A0311A26DD97@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5IaSBUaW0s PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JTUhPLCBJZiBpdCByZXBsYWNlcyByYXRo ZXIgdGhhbiBjb21wbGVtZW50cywgaXQgc2hvdWxkIGJlIG9ic29sZXRlcy48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZ3Vlc3MgdGhlcmUgaXMgYSBmb3JtYWwgZGVmaW5pdGlvbiBz b21ld2hlcmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Sb3F1ZTwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+DQo8ZGl2IHN0eWxl PSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCBmcm9tIG15IFNh bXN1bmcgR2FsYXh5IHNtYXJ0cGhvbmUuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFs TWVzc2FnZSAtLT4NCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2 Pg0KPGRpdj5Gcm9tOiBUaW0gQnJ1aWpuemVlbHMgJmx0O3RpbUByaXBlLm5ldCZndDsgPC9kaXY+ DQo8ZGl2PkRhdGU6IDExLzMwLzE3IDE0OjM5IChHTVQmIzQzOzAxOjAwKSA8L2Rpdj4NCjxkaXY+ VG86ICZxdW90O1JvcXVlIEdhZ2xpYW5vIChyb2dhZ2xpYSkmcXVvdDsgJmx0O3JvZ2FnbGlhQGNp c2NvLmNvbSZndDsgPC9kaXY+DQo8ZGl2PkNjOiBzaWRyb3BzQGlldGYub3JnIDwvZGl2Pg0KPGRp dj5TdWJqZWN0OiBSZTogW1NpZHJvcHNdIERvY3VtZW50IG9uIEhUVFBTIG9uIFRBTHMgKHVwZGF0 ZSB0byBSRkM3NzMwKSAtIHNlZWtpbmcgYWRvcHRpb24NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+ DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCiZndDsgT24gMzAgTm92IDIwMTcsIGF0IDE0 OjMxLCBSb3F1ZSBHYWdsaWFubyAocm9nYWdsaWEpICZsdDtyb2dhZ2xpYUBjaXNjby5jb20mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBUaW0sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aHkgeW91IGFyZSDigJx1cGRhdGVz4oCdIFJGQyA3NzMw IGFuZCBub3Qg4oCcb2Jzb2xldGVz4oCdIFJGQzc3MzAuIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9y YXRlIG9uIHRoaXMgZGVjaXNpb24/PGJyPg0KPGJyPg0KSSBiZWxpZXZlIHlvdeKAmXJlIHJpZ2h0 IGFuZCBpdCBzaG91bGQgaW5kZWVkIHNheSDigJhvYnNvbGV0ZXPigJkgLSBhcyBpbiByZXBsYWNl cyAtIHJhdGhlciB0aGFuIHVwZGF0ZXMgKHBhcnRzKSBvZiBpdC4gVGhhdCBzYWlkLCBtb3N0IG9m IHRoZSB0ZXh0IGlzIGEgc3RyYWlnaHQgY29weSBvZiB0aGUgdGV4dCBpbiA3NzMwLjxicj4NCjxi cj4NClRpbTxicj4NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZn dDsgUm9xdWU8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAzMC8xMS8xNyAxNDow MiwgJnF1b3Q7U2lkcm9wcyBvbiBiZWhhbGYgb2YgVGltIEJydWlqbnplZWxzJnF1b3Q7ICZsdDtz aWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRpbUByaXBlLm5ldCZndDsgd3Jv dGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlYXIgd29ya2luZyBn cm91cCw8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXMgZGlzY3Vzc2Vk IGF0IElFVEY5OSwgYW5kIGluIGluZm9ybWFsIHRhbGtzIHdpdGggc29tZSBvZiB5b3UsIHdlIHdv dWxkIGxpa2UgdG8gdXBkYXRlIHRoZSBUQUwgZm9ybWF0IChSRkM3NzMwKSB0byBhbGxvdyBIVFRQ Uy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB3b3JrZWQgd2l0aCBH ZW9yZ2UgTWljaGFlbHNvbiBvbiBhbiB1cGRhdGUuIEJlY2F1c2UgUkZDNzczMCBjb250YWlucyBx dWl0ZSBhIGZldyByZWZlcmVuY2VzIHRvIOKAmHJzeW5j4oCZIHdlIGZlbHQgdGhhdCBhIG5ldyBk b2N1bWVudCB1cGRhdGluZyA3NzMwIHdvdWxkIGJlIG1vcmUgcmVhZGFibGUgYW5kIGFwcHJvcHJp YXRlIHRoZW4gZG9jdW1lbnQgdXBkYXRpbmcgbWFueSBzbWFsbCBiaXRzIG9mIHRleHQuIFRoZSAt MDAgdmVyc2lvbiBvZg0KIHRoaXMgZG9jdW1lbnQgaXMgaGVyZTogPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC10YnJ1aWpuemVlbHMtc2lkcm9wcy1odHRwcy10YWwtMDAu dHh0IiB0YXJnZXQ9Il9CTEFOSyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRi cnVpam56ZWVscy1zaWRyb3BzLWh0dHBzLXRhbC0wMC50eHQ8L2E+PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBjby1jaGFpcnMg dG8gbWFrZSBhIGNhbGwgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgZm9yIGFkb3B0aW9uLjxicj4NCiZn dDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJbiBzaG9ydCB0aGlzIHVwZGF0ZSB3aWxs IGFsbG93IHRoZSB1c2Ugb2YgSFRUUFMgaW5zdGVhZCBvZiwgb3IgaW4gYWRkaXRpb24gdG8sIHJz eW5jIG9uIFRBTHMuIE90aGVyIHRoYW4gdGhhdCBpdCBjb250YWlucyBhIHNlY3Rpb24gb24gVExT IHZlcmlmaWNhdGlvbiBzaW1pbGFyIHRvIHRoZSBvbmUgdGhhdCBpcyBpbmNsdWRlZCBpbiB0aGUg ZGVsdGEgcHJvdG9jb2wgKFJGQzgxODIpIC0gZXNzZW50aWFsbHkgc2F5aW5nIHRoYXQgVExTIHZl cmlmaWNhdGlvbg0KIGlzIGRvbmUgb24gYSBiZXN0IGVmZm9ydCBiYXNpcyAtIGFuZCB3YXJuaW5n cyBzaG91bGQgYmUgdXR0ZXJlZCBpbiBjYXNlIG9mIGlzc3VlcyAtIGJ1dCBiZWNhdXNlIHRoZSBU QSBjZXJ0aWZpY2F0ZSBjYW4gc3RpbGwgYmUgdmFsaWRhdGVkIGNyeXB0b2dyYXBoaWNhbGx5IGl0 IE1VU1Qgc3RpbGwgYmUgZG93bmxvYWRlZC4gTm90ZSB0aGF0IGl0IGlzIGEgbWF0dGVyIG9mIGxv Y2FsIHBvbGljeSB3aGV0aGVyIGFuIFJQIGNob29zZXMgdG8gdXNlIGRpZmZlcmVudA0KIGxvY2F0 aW9ucyBpZiB0aGV5IGFyZSBwcmVzZW50LCBidXQgd2UgbWF5IHdhbnQgdG8gYWRkIHNvbWUgdGV4 dCBoZXJlIHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEhUVFBTIFVSSXMgdGhhdCBoYXZlIG5vIFRM UyB2ZXJpZmljYXRpb24gaXNzdWVzIG92ZXIgb25lcyB0aGF0IGRvIC0gYXQgdGhpcyBwb2ludCBJ IGFtIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyBuZWVkZWQsIG9yIHdvdWxkIG5lZWQgdG8gYmUgbm9y bWF0aXZlIHRleHQsIGJ1dCBJIHRoaW5rDQogaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHNvbWUg ZGlzY3Vzc2lvbiBvbiB0aGlzLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBGb3IgdGhlIHJlY29yZCwgSSBhbSBub3Qgc3VyZSB3aGF0IGlzIGN1c3RvbWFyeSBpbiB0aGVz ZSBjYXNlcyBvZiByZWxhdGl2ZWx5IHNtYWxsIHVwZGF0ZXMgdG8gZXhpc3Rpbmcgc3RhbmRhcmRz LiBCdXQsIEkgdHJpZWQgdG8gYXBwcm9hY2ggdGhlIG90aGVyIGF1dGhvcnMgb2YgUkZDNzczMCAo R2VvcmdlIGlzIGFscmVhZHkgb25lIG9mIHRoZW0pIGFuZCBhc2sgdGhlbSB3aGV0aGVyIHRoZXkg d2FudCB0byByZW1haW4gYXV0aG9ycyBvbg0KIHRoaXMgbmV3IGRvY3VtZW50LiBHZW9mZiBIdXN0 b24gaW5kaWNhdGVkIHRoYXQgaGUgZG9lcyBub3QgbmVlZCB0byBiZSBvbiB0aGUgbGlzdCwgYnV0 IGhhcyBubyBvYmplY3Rpb25zIHRvIHVzIGRvaW5nIHRoaXMgd29yay4gSSBoYXZlIG5vdCBzZWVu IHJlc3BvbnNlcyBmcm9tIFNhbSBXZWlsZXIgb3IgU3RlcGhlbiBLZW50IC0gaXQgaXMgYWxzbyBw b3NzaWJsZSB0aGF0IHRoZXkgbWlzc2VkIG15IG1lc3NhZ2UuIEluIGFueSBjYXNlIHdlIGhhdmUN CiBubyBvYmplY3Rpb25zIGlmIHRoZXkgZG8gd2lzaCB0byBzdGF5IG9uIGFzIGF1dGhvcnMsIGJ1 dCBmb3Igbm93IHRoZXkgYXJlIG5vdCBvbiB0aGUgbGlzdCBvZiB0aGUgZG9jdW1lbnQgbGlua2Vk IGFib3ZlLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBLaW5kIHJlZ2Fy ZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpbSA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpZHJvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBTaWRyb3BzQGlldGYub3JnPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJv cHMiIHRhcmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpZHJvcHM8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFNpZHJvcHMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyBTaWRyb3BzQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHMiIHRhcmdldD0iX0JM QU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHM8L2E+PGJy Pg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_a1ca5abc5f21482caa634126e99c123aXCHRTP011ciscocom_-- From nobody Thu Dec 7 01:17:02 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645551293D8 for ; Thu, 7 Dec 2017 01:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSoq7ieFtA3C for ; Thu, 7 Dec 2017 01:16:58 -0800 (PST) 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 53D96120454 for ; Thu, 7 Dec 2017 01:16:58 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eMsIZ-00019V-1h; Thu, 07 Dec 2017 10:16:56 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-199.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eMsIY-0003Iu-Mx; Thu, 07 Dec 2017 10:16:54 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 7 Dec 2017 10:16:43 +0100 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net> References: To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.3445.4.7) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07195c504adb85bfda6b8dc83cbfd86b1494 Archived-At: Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 09:17:01 -0000 Hi Roque, WG, As I said I believe that you=E2=80=99re right and it should say = =E2=80=9Cobsoletes=E2=80=9D. Co-chairs, can you initiate a call for adoption on this? I am happy to change =E2=80=9Cupdates=E2=80=9D to =E2=80=9Cobsoletes=E2=80= =9D when adopted. Tim > On 6 Dec 2017, at 21:11, Roque Gagliano (rogaglia) = wrote: >=20 > Hi Tim, >=20 > IMHO, If it replaces rather than complements, it should be obsoletes. >=20 > I guess there is a formal definition somewhere. >=20 > Roque >=20 >=20 >=20 >=20 > Sent from my Samsung Galaxy smartphone. >=20 > -------- Original message -------- > From: Tim Bruijnzeels > Date: 11/30/17 14:39 (GMT+01:00) > To: "Roque Gagliano (rogaglia)" > Cc: sidrops@ietf.org > Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - = seeking adoption >=20 >=20 > > On 30 Nov 2017, at 14:31, Roque Gagliano (rogaglia) = wrote: > >=20 > > Hi Tim, > >=20 > > Not sure I understand why you are =E2=80=9Cupdates=E2=80=9D RFC 7730 = and not =E2=80=9Cobsoletes=E2=80=9D RFC7730. Could you please elaborate = on this decision? >=20 > I believe you=E2=80=99re right and it should indeed say = =E2=80=98obsoletes=E2=80=99 - as in replaces - rather than updates = (parts) of it. That said, most of the text is a straight copy of the = text in 7730. >=20 > Tim >=20 >=20 > >=20 > > Regards, > > Roque > >=20 > >=20 > > On 30/11/17 14:02, "Sidrops on behalf of Tim Bruijnzeels" = wrote: > >=20 > > Dear working group, > >=20 > > As discussed at IETF99, and in informal talks with some of you, = we would like to update the TAL format (RFC7730) to allow HTTPS. > >=20 > > I worked with George Michaelson on an update. Because RFC7730 = contains quite a few references to =E2=80=98rsync=E2=80=99 we felt that = a new document updating 7730 would be more readable and appropriate then = document updating many small bits of text. The -00 version of this = document is here: = https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt > >=20 > > We would like to ask the co-chairs to make a call to the working = group for adoption. > >=20 > > In short this update will allow the use of HTTPS instead of, or = in addition to, rsync on TALs. Other than that it contains a section on = TLS verification similar to the one that is included in the delta = protocol (RFC8182) - essentially saying that TLS verification is done on = a best effort basis - and warnings should be uttered in case of issues - = but because the TA certificate can still be validated cryptographically = it MUST still be downloaded. Note that it is a matter of local policy = whether an RP chooses to use different locations if they are present, = but we may want to add some text here recommending the use of HTTPS URIs = that have no TLS verification issues over ones that do - at this point I = am not sure that this is needed, or would need to be normative text, but = I think it would be good to have some discussion on this. > >=20 > > For the record, I am not sure what is customary in these cases of = relatively small updates to existing standards. But, I tried to approach = the other authors of RFC7730 (George is already one of them) and ask = them whether they want to remain authors on this new document. Geoff = Huston indicated that he does not need to be on the list, but has no = objections to us doing this work. I have not seen responses from Sam = Weiler or Stephen Kent - it is also possible that they missed my = message. In any case we have no objections if they do wish to stay on as = authors, but for now they are not on the list of the document linked = above. > >=20 > > Kind regards, > >=20 > > Tim=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > >=20 > >=20 > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Dec 7 03:37:45 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79D1287A5 for ; Thu, 7 Dec 2017 03:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 slk3eG-6wJbU for ; Thu, 7 Dec 2017 03:37:42 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22E5129408 for ; Thu, 7 Dec 2017 03:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6340; q=dns/txt; s=iport; t=1512646661; x=1513856261; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BDEzsWAtxZKuHcHhtKyRLml9KEvjlUZMxbHrF+tDlto=; b=mUEMRT4ukLap+qZDrNiip03Ym9cjs4vN07Hl4DzYvvUtaS9Ke/HOCcos YEnJAS9veoX/aGvGj+4jCS+ZEUCdMjJ+ir2IWYklA/NG/ZXD1EkeA3QOb 0qRWXhNvOzRMLivDMX39aPPGzzzq69aoTTRIF5kkNirSEe9Q4P/l7p3Tx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgArJyla/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnInB4N7mR2BVyaXHYIBChgLhElPAhqFPUIVAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQECAQEBGwYROgsQAgEIEQMBAgECAiYCAgIlCxUICAIEDgWKHwgQq?= =?us-ascii?q?ACCJ4pYAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JFggqBVoFpKQuCd4FJgyB?= =?us-ascii?q?Pgn4xghIgBYhfmiICh3aNJYIWhhGLNYpAgkWJJwIRGQGBOgE1I4FPbxU6KgGBf?= =?us-ascii?q?oJSDBCBZ3gBhz4sgQWBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,372,1508803200"; d="scan'208";a="40954801" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 11:37:40 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vB7BbdPf011540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 11:37:39 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.1320.4; Thu, 7 Dec 2017 06:37:38 -0500 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.1320.000; Thu, 7 Dec 2017 06:37:38 -0500 From: "Roque Gagliano (rogaglia)" To: Tim Bruijnzeels CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption Thread-Index: AQHTbs5kZfQ1pDjfNk6F/uX9XSbmLqM37maAgAAnXoA= Date: Thu, 7 Dec 2017 11:37:38 +0000 Message-ID: <1F0086D3-A2C4-4329-8A1C-8338FAE5ECC9@cisco.com> References: <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net> In-Reply-To: <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.220.45] Content-Type: text/plain; charset="utf-8" Content-ID: <6EF952F318FB624F8E9B72D5DFF951B7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 11:37:44 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIHdpdGggdGhpcyBjaGFuZ2UuDQoNClJvcXVlDQoNCg0KIA0KDQpP biAwNy8xMi8xNyAxMDoxNywgIlRpbSBCcnVpam56ZWVscyIgPHRpbUByaXBlLm5ldD4gd3JvdGU6 DQoNCiAgICBIaSBSb3F1ZSwgV0csDQogICAgDQogICAgQXMgSSBzYWlkIEkgYmVsaWV2ZSB0aGF0 IHlvdeKAmXJlIHJpZ2h0IGFuZCBpdCBzaG91bGQgc2F5IOKAnG9ic29sZXRlc+KAnS4NCiAgICAN CiAgICBDby1jaGFpcnMsIGNhbiB5b3UgaW5pdGlhdGUgYSBjYWxsIGZvciBhZG9wdGlvbiBvbiB0 aGlzPw0KICAgIA0KICAgIEkgYW0gaGFwcHkgdG8gY2hhbmdlIOKAnHVwZGF0ZXPigJ0gdG8g4oCc b2Jzb2xldGVz4oCdIHdoZW4gYWRvcHRlZC4NCiAgICANCiAgICBUaW0NCiAgICANCiAgICANCiAg ICANCiAgICANCiAgICA+IE9uIDYgRGVjIDIwMTcsIGF0IDIxOjExLCBSb3F1ZSBHYWdsaWFubyAo cm9nYWdsaWEpIDxyb2dhZ2xpYUBjaXNjby5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBIaSBU aW0sDQogICAgPiANCiAgICA+IElNSE8sIElmIGl0IHJlcGxhY2VzIHJhdGhlciB0aGFuIGNvbXBs ZW1lbnRzLCBpdCBzaG91bGQgYmUgb2Jzb2xldGVzLg0KICAgID4gDQogICAgPiBJIGd1ZXNzIHRo ZXJlIGlzIGEgZm9ybWFsIGRlZmluaXRpb24gc29tZXdoZXJlLg0KICAgID4gDQogICAgPiBSb3F1 ZQ0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBTZW50IGZyb20gbXkgU2Ft c3VuZyBHYWxheHkgc21hcnRwaG9uZS4NCiAgICA+IA0KICAgID4gLS0tLS0tLS0gT3JpZ2luYWwg bWVzc2FnZSAtLS0tLS0tLQ0KICAgID4gRnJvbTogVGltIEJydWlqbnplZWxzIDx0aW1AcmlwZS5u ZXQ+DQogICAgPiBEYXRlOiAxMS8zMC8xNyAxNDozOSAoR01UKzAxOjAwKQ0KICAgID4gVG86ICJS b3F1ZSBHYWdsaWFubyAocm9nYWdsaWEpIiA8cm9nYWdsaWFAY2lzY28uY29tPg0KICAgID4gQ2M6 IHNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbU2lkcm9wc10gRG9jdW1lbnQg b24gSFRUUFMgb24gVEFMcyAodXBkYXRlIHRvIFJGQzc3MzApIC0gc2Vla2luZyBhZG9wdGlvbg0K ICAgID4gDQogICAgPiANCiAgICA+ID4gT24gMzAgTm92IDIwMTcsIGF0IDE0OjMxLCBSb3F1ZSBH YWdsaWFubyAocm9nYWdsaWEpIDxyb2dhZ2xpYUBjaXNjby5jb20+IHdyb3RlOg0KICAgID4gPiAN CiAgICA+ID4gSGkgVGltLA0KICAgID4gPiANCiAgICA+ID4gTm90IHN1cmUgSSB1bmRlcnN0YW5k IHdoeSB5b3UgYXJlIOKAnHVwZGF0ZXPigJ0gUkZDIDc3MzAgYW5kIG5vdCDigJxvYnNvbGV0ZXPi gJ0gUkZDNzczMC4gQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGUgb24gdGhpcyBkZWNpc2lvbj8N CiAgICA+IA0KICAgID4gSSBiZWxpZXZlIHlvdeKAmXJlIHJpZ2h0IGFuZCBpdCBzaG91bGQgaW5k ZWVkIHNheSDigJhvYnNvbGV0ZXPigJkgLSBhcyBpbiByZXBsYWNlcyAtIHJhdGhlciB0aGFuIHVw ZGF0ZXMgKHBhcnRzKSBvZiBpdC4gVGhhdCBzYWlkLCBtb3N0IG9mIHRoZSB0ZXh0IGlzIGEgc3Ry YWlnaHQgY29weSBvZiB0aGUgdGV4dCBpbiA3NzMwLg0KICAgID4gDQogICAgPiBUaW0NCiAgICA+ IA0KICAgID4gDQogICAgPiA+IA0KICAgID4gPiBSZWdhcmRzLA0KICAgID4gPiBSb3F1ZQ0KICAg ID4gPiANCiAgICA+ID4gDQogICAgPiA+IE9uIDMwLzExLzE3IDE0OjAyLCAiU2lkcm9wcyBvbiBi ZWhhbGYgb2YgVGltIEJydWlqbnplZWxzIiA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiB0aW1AcmlwZS5uZXQ+IHdyb3RlOg0KICAgID4gPiANCiAgICA+ID4gICAgRGVhciB3 b3JraW5nIGdyb3VwLA0KICAgID4gPiANCiAgICA+ID4gICAgQXMgZGlzY3Vzc2VkIGF0IElFVEY5 OSwgYW5kIGluIGluZm9ybWFsIHRhbGtzIHdpdGggc29tZSBvZiB5b3UsIHdlIHdvdWxkIGxpa2Ug dG8gdXBkYXRlIHRoZSBUQUwgZm9ybWF0IChSRkM3NzMwKSB0byBhbGxvdyBIVFRQUy4NCiAgICA+ ID4gDQogICAgPiA+ICAgIEkgd29ya2VkIHdpdGggR2VvcmdlIE1pY2hhZWxzb24gb24gYW4gdXBk YXRlLiBCZWNhdXNlIFJGQzc3MzAgY29udGFpbnMgcXVpdGUgYSBmZXcgcmVmZXJlbmNlcyB0byDi gJhyc3luY+KAmSB3ZSBmZWx0IHRoYXQgYSBuZXcgZG9jdW1lbnQgdXBkYXRpbmcgNzczMCB3b3Vs ZCBiZSBtb3JlIHJlYWRhYmxlIGFuZCBhcHByb3ByaWF0ZSB0aGVuIGRvY3VtZW50IHVwZGF0aW5n IG1hbnkgc21hbGwgYml0cyBvZiB0ZXh0LiBUaGUgLTAwIHZlcnNpb24gb2YgdGhpcyBkb2N1bWVu dCBpcyBoZXJlOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRicnVpam56ZWVscy1z aWRyb3BzLWh0dHBzLXRhbC0wMC50eHQNCiAgICA+ID4gDQogICAgPiA+ICAgIFdlIHdvdWxkIGxp a2UgdG8gYXNrIHRoZSBjby1jaGFpcnMgdG8gbWFrZSBhIGNhbGwgdG8gdGhlIHdvcmtpbmcgZ3Jv dXAgZm9yIGFkb3B0aW9uLg0KICAgID4gPiANCiAgICA+ID4gICAgSW4gc2hvcnQgdGhpcyB1cGRh dGUgd2lsbCBhbGxvdyB0aGUgdXNlIG9mIEhUVFBTIGluc3RlYWQgb2YsIG9yIGluIGFkZGl0aW9u IHRvLCByc3luYyBvbiBUQUxzLiBPdGhlciB0aGFuIHRoYXQgaXQgY29udGFpbnMgYSBzZWN0aW9u IG9uIFRMUyB2ZXJpZmljYXRpb24gc2ltaWxhciB0byB0aGUgb25lIHRoYXQgaXMgaW5jbHVkZWQg aW4gdGhlIGRlbHRhIHByb3RvY29sIChSRkM4MTgyKSAtIGVzc2VudGlhbGx5IHNheWluZyB0aGF0 IFRMUyB2ZXJpZmljYXRpb24gaXMgZG9uZSBvbiBhIGJlc3QgZWZmb3J0IGJhc2lzIC0gYW5kIHdh cm5pbmdzIHNob3VsZCBiZSB1dHRlcmVkIGluIGNhc2Ugb2YgaXNzdWVzIC0gYnV0IGJlY2F1c2Ug dGhlIFRBIGNlcnRpZmljYXRlIGNhbiBzdGlsbCBiZSB2YWxpZGF0ZWQgY3J5cHRvZ3JhcGhpY2Fs bHkgaXQgTVVTVCBzdGlsbCBiZSBkb3dubG9hZGVkLiBOb3RlIHRoYXQgaXQgaXMgYSBtYXR0ZXIg b2YgbG9jYWwgcG9saWN5IHdoZXRoZXIgYW4gUlAgY2hvb3NlcyB0byB1c2UgZGlmZmVyZW50IGxv Y2F0aW9ucyBpZiB0aGV5IGFyZSBwcmVzZW50LCBidXQgd2UgbWF5IHdhbnQgdG8gYWRkIHNvbWUg dGV4dCBoZXJlIHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEhUVFBTIFVSSXMgdGhhdCBoYXZlIG5v IFRMUyB2ZXJpZmljYXRpb24gaXNzdWVzIG92ZXIgb25lcyB0aGF0IGRvIC0gYXQgdGhpcyBwb2lu dCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyBuZWVkZWQsIG9yIHdvdWxkIG5lZWQgdG8gYmUg bm9ybWF0aXZlIHRleHQsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21l IGRpc2N1c3Npb24gb24gdGhpcy4NCiAgICA+ID4gDQogICAgPiA+ICAgIEZvciB0aGUgcmVjb3Jk LCBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgY3VzdG9tYXJ5IGluIHRoZXNlIGNhc2VzIG9mIHJlbGF0 aXZlbHkgc21hbGwgdXBkYXRlcyB0byBleGlzdGluZyBzdGFuZGFyZHMuIEJ1dCwgSSB0cmllZCB0 byBhcHByb2FjaCB0aGUgb3RoZXIgYXV0aG9ycyBvZiBSRkM3NzMwIChHZW9yZ2UgaXMgYWxyZWFk eSBvbmUgb2YgdGhlbSkgYW5kIGFzayB0aGVtIHdoZXRoZXIgdGhleSB3YW50IHRvIHJlbWFpbiBh dXRob3JzIG9uIHRoaXMgbmV3IGRvY3VtZW50LiBHZW9mZiBIdXN0b24gaW5kaWNhdGVkIHRoYXQg aGUgZG9lcyBub3QgbmVlZCB0byBiZSBvbiB0aGUgbGlzdCwgYnV0IGhhcyBubyBvYmplY3Rpb25z IHRvIHVzIGRvaW5nIHRoaXMgd29yay4gSSBoYXZlIG5vdCBzZWVuIHJlc3BvbnNlcyBmcm9tIFNh bSBXZWlsZXIgb3IgU3RlcGhlbiBLZW50IC0gaXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IHRoZXkg bWlzc2VkIG15IG1lc3NhZ2UuIEluIGFueSBjYXNlIHdlIGhhdmUgbm8gb2JqZWN0aW9ucyBpZiB0 aGV5IGRvIHdpc2ggdG8gc3RheSBvbiBhcyBhdXRob3JzLCBidXQgZm9yIG5vdyB0aGV5IGFyZSBu b3Qgb24gdGhlIGxpc3Qgb2YgdGhlIGRvY3VtZW50IGxpbmtlZCBhYm92ZS4NCiAgICA+ID4gDQog ICAgPiA+ICAgIEtpbmQgcmVnYXJkcywNCiAgICA+ID4gDQogICAgPiA+ICAgIFRpbSANCiAgICA+ ID4gDQogICAgPiA+IA0KICAgID4gPiANCiAgICA+ID4gDQogICAgPiA+ICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+ICAgIFNpZHJvcHMg bWFpbGluZyBsaXN0DQogICAgPiA+ICAgIFNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+ID4gICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQogICAgPiA+IA0KICAg ID4gPiANCiAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICA+ID4gU2lkcm9wcyBtYWlsaW5nIGxpc3QNCiAgICA+ID4gU2lkcm9wc0BpZXRm Lm9yZw0KICAgID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJv cHMNCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICA+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgPiBTaWRyb3BzQGlldGYu b3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHMN CiAgICANCiAgICANCg0K From nobody Mon Dec 11 18:05:33 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E30126D05; Mon, 11 Dec 2017 18:05:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151304433244.20409.17231979932715977756@ietfa.amsl.com> Date: Mon, 11 Dec 2017 18:05:32 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-rollover-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 02:05:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Router Certificate Rollover Authors : Brian Weis Roque Gagliano Keyur Patel Filename : draft-ietf-sidrops-bgpsec-rollover-04.txt Pages : 11 Date : 2017-12-11 Abstract: Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec Update messages verified with those router public keys. This document describes a safe rollover process, as well as discussing when and why the rollover of BGPsec router certificates are necessary. When this rollover process is followed the rollover will be performed without routing information being lost. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bgpsec-rollover-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-bgpsec-rollover-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 Dec 11 18:09:30 2017 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 659AA1276AF; Mon, 11 Dec 2017 15:15:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Cc: morrowc@ops-netman.net, The IESG , sidrops@ietf.org, draft-ietf-sidrops-bgpsec-rollover@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151303413341.20442.16574333493788476869.idtracker@ietfa.amsl.com> Date: Mon, 11 Dec 2017 15:15:33 -0800 Archived-At: X-Mailman-Approved-At: Mon, 11 Dec 2017 18:09:29 -0800 Subject: [Sidrops] Protocol Action: 'BGPsec Router Certificate Rollover' to Best Current Practice (draft-ietf-sidrops-bgpsec-rollover-03.txt) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:15:33 -0000 The IESG has approved the following document: - 'BGPsec Router Certificate Rollover' (draft-ietf-sidrops-bgpsec-rollover-03.txt) as Best Current Practice This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/ Technical Summary Certificate Authorities (CAs) managing CA certificates and End-Entity (EE) certificates within the Resource Public Key Infrastructure (RPKI) will also manage BGPsec router certificates. But the rollover of CA and EE certificates BGPsec router certificates have additional considerations for Normal and emergency rollover processes. The rollover must be carefully managed in order to synchronize distribution of router public keys and BGPsec routers creating BGPsec Update messages verified with those router public keys. This document provides general recommendations for the rollover process, as well as describing reasons why the rollover of BGPsec router certificates might be necessary. When this rollover process is followed the rollover should be accomplished without routing information being lost. Working Group Summary As the Document Shepherd says: "This document didn't raise the ire of the WG, which was nice for a change." The document was well reviewed. Document Quality There are existing implementations - the 3 main versions of RPKI supporting software implement this. Personnel Document Shepherd: Chris Morrow. Responsible Area Director: Warren Kumari