From nobody Mon Mar 6 08:13:04 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 C8A3412999E; Fri, 3 Mar 2017 15:55:23 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532381.15846.806486909932238155.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:23 -0800 Archived-At: X-Mailman-Approved-At: Mon, 06 Mar 2017 08:13:03 -0800 Cc: joelja@bogus.com, sidrops@ietf.org Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 98 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:24 -0000 Dear Chris Morrow, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (1:30:00) Tuesday, Afternoon Session II 1450-1620 Room Name: Zurich C size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sidr opsarea opsec idr Second Priority: grow People who must be present: Chris Morrow Keyur Patel Joel Jaeggli Resources Requested: Projector in room Special Requests: we're newbies! :) and ideally not friday, but... --------------------------------------------------------- From nobody Wed Mar 8 10:53:27 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 65D8C1294BC; Wed, 8 Mar 2017 10:53:26 -0800 (PST) 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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148899920637.20215.823697088683647126@ietfa.amsl.com> Date: Wed, 08 Mar 2017 10:53:26 -0800 Archived-At: Cc: sidrops@ietf.org Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-rollover-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:53:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations of the IETF. Title : BGPsec Router Certificate Rollover Authors : Brian Weis Roque Gagliano Keyur Patel Filename : draft-ietf-sidrops-bgpsec-rollover-00.txt Pages : 10 Date : 2017-03-08 Abstract: BGPsec will need to address the impact from regular and emergency rollover processes for the BGPsec end-entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec EE certificates must be carefully managed in order to synchronize distribution of router public keys and the usage of those public keys by BGPsec routers. This memo provides general recommendations for that process, as well as describing reasons why the rollover of BGPsec EE certificates might be necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-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 Wed Mar 8 11:59: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 13A671294BC; Wed, 8 Mar 2017 11:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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, RCVD_IN_MSPIKE_H2=-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=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yeXWCO3j-Uz; Wed, 8 Mar 2017 11:26:31 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 B6CB71293FF; Wed, 8 Mar 2017 11:26:31 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id C02A160056; Wed, 8 Mar 2017 19:26:30 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2CA028004F; Wed, 8 Mar 2017 19:26:31 +0000 (UTC) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0024.outbound.protection.outlook.com [207.46.163.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 5CA8E6005D; Wed, 8 Mar 2017 19:26:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7AaTFcXNrmao/75ZYC7UctifdhacNQs5wHaOLniT+3g=; b=brPjcmeb2t6G3AKNHiXHvbXY17H9nAKvdTp7eu5JGy4fe7McZov3dMUjSWvctYr7gHa+MlkqLg7YLQLCTK2C2RCnqt4KgfmEnuoFfjre0pMmu80WQLwAr8GfPaSyhK+wDSNSo8M7uZA1tjBXbR4LW7CfUlgdVYOBh6WfkBXaWg0= Received: from SN1PR18MB0270.namprd18.prod.outlook.com (10.163.58.157) by SN1PR18MB0269.namprd18.prod.outlook.com (10.163.58.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 19:26:28 +0000 Received: from SN1PR18MB0270.namprd18.prod.outlook.com ([10.163.58.157]) by SN1PR18MB0270.namprd18.prod.outlook.com ([10.163.58.157]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 19:26:28 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Call for SIDROPS WG Agenda Items Thread-Index: AQHSmEHhKm9TLxV8kUOYDXI6aM7uZA== Date: Wed, 8 Mar 2017 19:26:27 +0000 Message-ID: <7FA93B0D-8418-4A83-9F40-7AADC112BB52@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.68.143.133] x-ms-office365-filtering-correlation-id: 74745bd0-b675-4b4a-974d-08d466590489 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR18MB0269; x-microsoft-exchange-diagnostics: 1; SN1PR18MB0269; 7:hx4vwXuaKjVsSxJO7jnNdwaWs7wyrBIkngFLRb2RSUTXUEXvQ/GitZoBGoOMZVj1C9mOfUXQSwfZAOA0jBJ4nmssEdLaOgRROTO4M90Qiocj4+RBmfydUFIQQ3ZcW0XwtRH5FsfmexVP3ohbZclYMMNkfDMwlFrhNIUmCBulI6szd7NCTBseotR/VQXecFg/9A47bdWXqoI2uP2xE6cKHRDZdQ4RdnguG9a2B7c//jDtwbMB81OaV6wVWfAU81kkmYvUGrPEc3s2pwEaAuoh6A13wLzpOMsJyfQHdRoSmnRIWnhkgMWQVjlPcC6IgbgNXWSv9UmZwEHNImBz5rI3hQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(2016111802025)(20161123558025)(20161123555025)(20161123562025)(6043046)(6072148); SRVR:SN1PR18MB0269; BCL:0; PCL:0; RULEID:; SRVR:SN1PR18MB0269; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39830400002)(377454003)(6306002)(83716003)(6436002)(6512007)(6916009)(6506006)(54896002)(1730700003)(122556002)(8676002)(77096006)(81166006)(25786008)(6486002)(82746002)(2501003)(189998001)(36756003)(99286003)(8936002)(33656002)(5640700003)(4326008)(66066001)(106116001)(86362001)(3846002)(6116002)(54356999)(53936002)(50986999)(5660300001)(102836003)(450100002)(2906002)(38730400002)(3280700002)(3660700001)(2900100001)(110136004)(7736002)(2351001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR18MB0269; H:SN1PR18MB0270.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 19:26:27.9393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR18MB0269 X-MDID: 1489001191-05iVP-NCRZKC Archived-At: X-Mailman-Approved-At: Wed, 08 Mar 2017 11:59:05 -0800 Cc: "sidr@ietf.org" Subject: [Sidrops] Call for SIDROPS WG Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:26:33 -0000 --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZm9sa3MsDQoNClNJRFJPUFMgd2lsbCBtZWV0IGF0IElFVEYtOTggb24gVHVlc2RheSwgTWFy Y2ggMjh0aCBmcm9tIDI6NTAgcG0gLSA0OjIwIHBtLiBQbGVhc2UgZm9yd2FyZCBhbnkgU0lEUk9Q UyBhZ2VuZGEgaXRlbXMgeW91IG1heSBoYXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28g bWFrZSBzdXJlIHRoYXQgeW91ciBzbGlkZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2hhaXJzIGJ5 IE1vbmRheSBtb3JuaW5nICgzLzI3LzIwMTcpLiBTbGlkZXMgcmVjZWl2ZWQgYWZ0ZXIgd2lsbCBi ZSBsZXNzIGxpa2VseSB0byBiZSBhdmFpbGFibGUgZm9yIHVzZSBkdXJpbmcgdGhlIG1lZXRpbmcu DQoNCldlIGhhdmUgY2NlZCBTSURSIG1haWxpbmcgbGlzdCBhcyB3ZWxsIGNvbnNpZGVyaW5nIHdl IGFyZSBnb2luZyB0byBoYXZlIG91ciBmaXJzdCBTSURST1BTIG1lZXRpbmcuDQoNClJlZ2FyZHMs DQpDaHJpcyBhbmQgS2V5dXINCg0KDQoNCg0K --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <88940B6D50B1EB4A82D1993920FC6E7F@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBmb2xr cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNJRFJPUFMgd2ls bCBtZWV0IGF0IElFVEYtOTggb24gVHVlc2RheSwgTWFyY2ggMjh0aCBmcm9tIDI6NTAgcG0gLSA0 OjIwIHBtLiBQbGVhc2UgZm9yd2FyZCBhbnkgU0lEUk9QUyBhZ2VuZGEgaXRlbXMgeW91IG1heSBo YXZlIHRvIENocmlzIGFuZCBtZS4gUGxlYXNlIGFsc28gbWFrZSBzdXJlIHRoYXQgeW91ciBzbGlk ZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUNCiBjaGFpcnMgYnkgTW9uZGF5IG1vcm5pbmcgKDMvMjcv MjAxNykuIFNsaWRlcyByZWNlaXZlZCBhZnRlciB3aWxsIGJlIGxlc3MgbGlrZWx5IHRvIGJlIGF2 YWlsYWJsZSBmb3IgdXNlIGR1cmluZyB0aGUgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGhhdmUgY2NlZCBTSURSIG1haWxpbmcgbGlzdCBhcyB3 ZWxsIGNvbnNpZGVyaW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIG91ciBmaXJzdCBTSURST1BTIG1l ZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5DaHJpcyBhbmQgS2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7FA93B0D84184A839F407AADC112BB52arrcuscom_-- From nobody Tue Mar 14 17:32:25 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 730E6129496; Tue, 14 Mar 2017 15:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 ezoEbERQjQvO; Tue, 14 Mar 2017 15:26:50 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1A9129BB3; Tue, 14 Mar 2017 15:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DZs2Yh0mnvwhNvj0Q1EXuJIp6dWJM/DhUnrlLydUyyc=; b=R7xwG9YGqnzbSZF7I74Jea6XNYbl7IGhBLHU3EEaRb+cJudgZJU+Ty4EUpZqSQ/BpGTrxHPpgUsBVHIq48zcChdLh0NPWwjLcNbvkxQW0g6MvWeKXUloUD08QeHU40Koof0Vq3DwzIeL/hImoTvTJ4HND0pLxAVDBOmWntlYD4w= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 22:26:46 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 22:26:46 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush , Steve KENT CC: sidr wg list , Alvaro Retana , "Matthias Waehlisch" , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LI= Date: Tue, 14 Mar 2017 22:26:46 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.93] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:zovzPaFbPwAdivYBUBWnTywijaqAHJ7S91UwAzduKhEM3pOxFnjQz+nRg8+VJVLSOhOFsu/DmXwcvzm/Q48nBhQM5nAZDYzG46C37rUG5hVO2xoYYnVB4V6sq54CkSndgU4PVS12h5cXxsOqvF8Ai4HtSCNo7CtNL6NahT2IxZmLcXB+7aIA9SeekJlj1zmGpME2Ntw8MF7sS7EZoPcrjReDmTDkYljHQ+Tk9k/btVLoObhiU0lpO0zFCUDstk0MIYBVbsZ1Nj7JK/A4D/rpzO8q1xVx6EZh6vhwjI3DCnoGqzm65TpPF6hpjipqhTAh0m91Wm1UE+VNiDsvGGdXAw== x-ms-office365-filtering-correlation-id: 85cadefb-1c6a-4fe1-4a3e-08d46b293375 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51414003)(25786008)(966004)(6306002)(7696004)(6246003)(6606003)(99286003)(54906002)(33656002)(55016002)(9686003)(5660300001)(4326008)(54896002)(561944003)(53936002)(74316002)(7736002)(122556002)(2900100001)(10710500007)(38730400002)(77096006)(8936002)(8676002)(2906002)(2950100002)(81166006)(53546007)(3846002)(54356999)(6116002)(76176999)(3280700002)(6506006)(19627405001)(50986999)(15650500001)(7110500001)(2420400007)(229853002)(3660700001)(189998001)(66066001)(102836003)(6436002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 22:26:46.5207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: X-Mailman-Approved-At: Tue, 14 Mar 2017 17:32:22 -0700 Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:26:52 -0000 --_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just so that everyone on the list is aware of the background info.... I sent this suggestion (email copied below) to Alvaro. Alvaro replied to me in detail. I would request him to post that response on this list as well so everyone has the full context. Alvaro asked me to invite comments on the WG list. Please read the proposal below, and share your thoughts. Thanks. Sriram ________________________________________ From: Sriram, Kotikalapudi (Fed) Sent: Monday, March 13, 2017 4:57 PM To: Alvaro Retana (aretana) Subject: BGPsec draft and extended messages Hi Alvaro, Just trying to think aloud about a possible way to have wording in the BGPs= ec draft that does not require normative dependence on the extended message= draft. I think it can be done in a rational way as follows. Please feel fr= ee to shoot this down if the rationale seems weak. Currently the draft reads in Section 2.2: Note that BGPsec update messages can be quite large, therefore any BGPsec speaker announcing the capability to receive BGPsec messages SHOULD also announce support for the capability to receive BGP extended messages [I-D.ietf-idr-bgp-extended-messages]. Please see related operational guidance in Section 7. Suggestion: Remove the above paragraph from Section 2.2 and add the followi= ng in Section 4.2 (Constructing the BGPsec_Path Attribute): BGPsec update size is subject to a maximum BGP update size. The maximum siz= e at present is 4096 bytes [RFC4271], and it may be extended to a larger si= ze in the future. If the sending router determines that adding its Secure_P= ath Segment and Signature Segment causes the BGPsec update to exceed the ma= ximum size, then it will convert the BGPsec update to an unsigned tradition= al BGP update [using the procedure in Section 4.4] and send the unsigned up= date. (Note: Please see related discussion in Section 7.) Then the existing discussion paragraph in Section 7 (operations) related to= extended messages can be replaced with the following: BGPsec update size is subject to =93current=94 maximum BGP update size, not= ing that =93current=94 maximum size may increase in the future. The maximum= size at present is 4096 bytes [RFC4271], and it is expected be extended to= a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given th= e ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-= algs], each AS in an AS path adds approximately 100 bytes of BGPsec data (i= .e. Secure_Path Segment and Signature Segment). Hence, the maximum size of = 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS= path. (Note: AS prepends are compressed out with the use of pCount as desc= ribed in Section 3.1.) Currently, the average and maximum AS path lengths = in the Internet are 3.8 and 14, respectively, and have remained in this bal= l park for many years [Huston]. [Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 March 1= 3, 2017. http://bgp.potaroo.net/as6447/ (BTW, the above wording perhaps also makes it independent of the form exten= ded messages takes eventually =96 separate RFC that updates BGP-4 or as def= ault in BGP-5 OPEN(?) etc. ) I look forward to hearing your thoughts on this. Thank you. Sriram --_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Just so that everyone on the list is aware of the background info..= .. 

I sent this suggestion (email copied below) to Alvaro.

Alvaro replied to me in detail. 

I would request him to post that response on this list as well

so everyone has the full context.

Alvaro asked me to invite comments on the WG list. 


Please read the proposal below, and share your thoughts. Thanks.


Sriram 

________________________________________

From: Sriram, Kotikalapudi (Fed)

Sent: Monday, March 13, 2017 4:57 PM

To: Alvaro Retana (aretana)

Subject: BGPsec draft and extended messages

Hi Alvaro,

Just trying to think aloud about a possible way to have wording in the B= GPsec draft that does not require normative dependence on the extended mess= age draft. I think it can be done in a rational way as follows. Please feel= free to shoot this down if the rationale seems weak.

Currently the draft reads in Section 2.2:

   Note that BGPsec update messages can be quite large, theref= ore any

   BGPsec speaker announcing the capability to receive BGPsec = messages

   SHOULD also announce support for the capability to receive = BGP

   extended messages [I-D.ietf-idr-bgp-extended-messages].&nbs= p; Please see

   related operational guidance in Section 7.

Suggestion: Remove the above paragraph from Section 2.2 and add the foll= owing in Section 4.2 (Constructing the BGPsec_Path Attribute):


BGPsec update size is subject to a maximum BGP update size. The maximum = size at present is 4096 bytes [RFC4271], and it may be extended to a larger= size in the future. If the sending router determines that adding its Secur= e_Path Segment and Signature Segment causes the BGPsec update to exceed the maximum size, then it will convert = the BGPsec update to an unsigned traditional BGP update [using the procedur= e in Section 4.4] and send the unsigned update. (Note: Please see related d= iscussion in Section 7.)


Then the existing discussion paragraph in Section 7 (operations) related= to extended messages can be replaced with the following:


BGPsec update size is subject to =93current=94 maximum BGP update size, = noting that =93current=94 maximum size may increase in the future. The maxi= mum size at present is 4096 bytes [RFC4271], and it is expected be extended= to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sid= r-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPse= c data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximum= size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepe= nds are compressed out with the use of pCount as described in Section 3.1.)=   Currently, the average and maximum AS path lengths in the Internet a= re 3.8 and 14, respectively, and have remained in this ball park for many years [Huston].


[Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 Marc= h 13, 2017.  http://bgp.potaroo.net/as6447/


(BTW, the above wording perhaps also makes it independent of the form ex= tended messages takes eventually =96 separate RFC that updates BGP-4 or as = default in BGP-5 OPEN(?) etc. )

I look forward to hearing your thoughts on this. Thank you.


Sriram

--_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_-- From nobody Tue Mar 14 19:58:43 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 5FBD3131874; Tue, 14 Mar 2017 19:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 vrtlrPsIre60; Tue, 14 Mar 2017 19:58:34 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0127.outbound.protection.outlook.com [23.103.200.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22C4131873; Tue, 14 Mar 2017 19:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SbJlltqYYq1ICWwk5nWX0++2iEeqAtJmOEZSBm1el5k=; b=lwQl6hZL53zLrnoAVThw9F4TMUSRrPkjKz9B/BLahORDL0VC5gwY9nd1NWRapVMf1jOxTPLiRvqw9JcNqpG9DFrFRLrCrsgVuJyQwWn1VfPAxBTILOFXNKPvUg3N19ZJXUCGc85ficMGLrfgZw/EAbBsrwWmHJilM5gS9so/swk= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Wed, 15 Mar 2017 02:58:31 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0961.021; Wed, 15 Mar 2017 02:58:31 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush , Steve KENT CC: sidr wg list , "sidrops@ietf.org" , Alvaro Retana , "keyur@arrcus.com" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAAqiPU8= Date: Wed, 15 Mar 2017 02:58:31 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.93] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:wpBwLRdISn9GvxzOmyO43Dgul/Dn4PEbW7l+2W64azqv5h6OfZh7UI8HACNgTb4THLYMEdlnAV5m+EglJ9ndo+TklePQLGLUk1wFhhWz2UgJ2KHkezD36ra/euokwvwYJSpWhmGEE/e4oP7OFSfLGGL/rsjevTgukMK6lPZQZjNHuKQ07+hmGHCZs5s+R3m44NnYGeQzVgyUMVg5NDwVSoA56qcO4rpRWaf6XuGv5OKo6oPslNtPTmQwR8Tod+JvwBdVKvOLMBfG/q/nCLZMjXgzf+8MrSvZlk+eWdajtitZEjXCC+PTjpvA9B8Htxr5kae/BLMDjXsmX2LuF50Ckg== x-ms-office365-filtering-correlation-id: 02c1cdce-fd75-4208-5110-08d46b4f2a0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(54896002)(3846002)(122556002)(76176999)(2420400007)(6606003)(15650500001)(2950100002)(7696004)(2900100001)(236005)(55016002)(5660300001)(6306002)(54906002)(53936002)(77096006)(99286003)(9686003)(8676002)(7736002)(81166006)(25786008)(229853002)(7906003)(86362001)(189998001)(2906002)(38730400002)(10710500007)(6506006)(102836003)(74316002)(6246003)(6116002)(606005)(3280700002)(7110500001)(8936002)(966004)(54356999)(6436002)(3660700001)(33656002)(53336002)(66066001)(4326008)(50986999)(19627405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 02:58:31.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 02:58:36 -0000 --_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >> I think it makes sense to omit the extended message feature, given the >> use of ECDSA P-256. >unfortunately, existing bgp data and simple arithmetic would seem to say o= therwise. We are focusing here on the size of the BGPsec_Path attribute. As I wrote in the rationale part in my other post (in this thread): BGPsec update size is subject to =93current=94 maximum BGP update size, not= ing that =93current=94 maximum size may increase in the future. The maximum= size at present is 4096 bytes [RFC4271], and it is expected be extended to= a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given th= e use of ECDSA P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-algs= ], each AS in an AS path adds approximately 100 bytes of BGPsec data (i.e. = Secure_Path Segment and Signature Segment). Hence, the maximum size of 4096= bytes is exceeded only if there are 40 or more distinct ASes in the AS pat= h. (Note: AS prepends are compressed out with the use of pCount as describe= d in Section 3.1.) Currently, the average and maximum AS path lengths in t= he Internet are 3.8 and 14, respectively, and have remained in this ball pa= rk for many years [Huston]. [Huston] G. Huston, =93AS6447 BGP Routing Table Analysis Report,=94 March 1= 3, 2017. http://bgp.potaroo.net/as6447/ Extended messages work must/will continue. We are only trying to see if BGP= sec draft can have the extended messages draft as an "Informational" reference rather= than "Normative". Sriram --_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

>> I think it makes sense to omit the extended message feature, gi= ven the

>> use of ECDSA P-256.


>unfortunately, existing bgp data and simple arithmetic would seem to= say otherwise.



We are focusing here on the size of the BGPsec_Path attribute.

As I wrote in the rationale part in my other post (in this thread):



BGPsec update size is subject to =93current=94 maximum BGP update = size, noting that =93current=94 maximum size may increase in the future. Th= e maximum size at present is 4096 bytes [RFC4271], and it is expected be ex= tended to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the use of ECDSA P-256 for the signature algorithm [I-D.ietf-si= dr-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPs= ec data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximu= m size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepends a= re compressed out with the use of pCount as described in Section 3.1.) = ; Currently, the average and maximum AS path lengths in the Internet are 3.= 8 and 14, respectively, and have remained in this ball park for many years [Huston]. 



[Huston] G. Huston, =93AS6447 BGP Routing Table A= nalysis Report,=94 March 13, 2017.  http://bgp.potaroo.net/as6447/ 



Extended messages work must/will continue. We are only tryin= g to see if BGPsec draft

can have the extended messages draft as an = "Informational" reference rather than "Normative".



Sriram


--_000_DM2PR09MB04468AF74061924F8576067784270DM2PR09MB0446namp_-- From nobody Wed Mar 15 06:45:04 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 D97231314F4; Wed, 15 Mar 2017 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 HwFFaMHOejOh; Wed, 15 Mar 2017 06:44:58 -0700 (PDT) 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 A7F7C1314F0; Wed, 15 Mar 2017 06:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11826; q=dns/txt; s=iport; t=1489585497; x=1490795097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bI1Kc+ZrDAYFCV6z521apxDkMo9uMG+XI+Ouug7HV7g=; b=OzbGypGgCk5h3SPii1uB7apsOtIxpuHWCXDuGlAUmf2u9q/ClzInchmt 6widcyZEgWewLWbDuYzyIhH0Q2UinC6Q8A+5pirLaPh85uR5X6H5Gd2rk aobU4laNumJwtmbWNl0LKCvY5SbMkIoH7PyKBsIpPEbpQAtuThKZwkYGz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AwD9RMlY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB4NZig2RNx+QD4Utgg6GIgIagk8/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBBAEjVgULAgEIPwMCAgIwFBEBAQQBDQWJeAiuCIImK4o1AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZOggUIgmKHWi6CMQWWAIZDAZI6gXuFJYoFiEaLAAEfOIE?= =?us-ascii?q?EWBVBEQGEQiCBY3WIJYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,168,1486425600"; d="scan'208,217";a="398438011" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 13:44:56 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2FDiu5R000384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 13:44:56 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 08:44:55 -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.1210.000; Wed, 15 Mar 2017 08:44:55 -0500 From: "Alvaro Retana (aretana)" To: "Sriram, Kotikalapudi (Fed)" , Randy Bush , Steve KENT CC: sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAA0o+kaAAxpUAAAF68igA== Date: Wed, 15 Mar 2017 13:44:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:45:03 -0000 --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCltTcGVha2luZyBhcyBBRF0NCg0KVGhlIHJlcXVpcmVtZW50IGZvciBFeHRlbmRlZCBN ZXNzYWdlcyBoYXMgYmVlbiBpbiB0aGUgQkdQU2VjIGRyYWZ0IHNpbmNlIHRoZSBiZWdpbm5pbmcg KGF0IGxlYXN0IHRoZSBXRyAtMDAgdmVyc2lvbikuICBDaGFuZ2luZyBpdCBub3cgd291bGQgbWVh biBhIHNpZ25pZmljYW50IGRldmlhdGlvbiBpbiB0aGUgcHJvY2VzcyDigJMgYnV0IG5vdCBpbXBv c3NpYmxlLg0KDQpCZWZvcmUgY29tbWl0dGluZyB0byBzdXBwb3J0aW5nIGFueSBjaGFuZ2UgdG8g dGhlIGRvY3VtZW50LCBJIHdvdWxkIGxpa2UgdG8gc2VlIGNoYW5nZXMgZGlzY3Vzc2VkIGluIHRo ZSBzaWRyIFdHIGxpc3QuICBZb3UgbWF5IGV2ZW4gYmUgYWJsZSB0byBjb252aW5jZSB0aGUgc2lk cm9wcyBDaGFpcnMgdG8gZ2l2ZSB5b3Ugc29tZSB0aW1lIGluIENoaWNhZ28gdG8gZGlzY3VzcyBp biBwZXJzb24uICBXZSB3b3VsZCBuZWVkIHRoZSBXRyB0byByZWFjaCBjb25zZW5zdXMgZm9yIHN1 Y2ggYSBjaGFuZ2UuDQoNCg0KW1NwZWFraW5nIGFzIFdHIFBhcnRpY2lwYW50XQ0KDQpJIHRoaW5r IHRoYXQgYSBwb3NzaWJsZSBwYXRoIGZvcndhcmQgaXMgdG8gdGFrZSBhbnkgcmVmZXJlbmNlIHRv IHRoZSBFeHRlbmRlZCBNZXNzYWdlcyBkb2N1bWVudCBvdXQsIGFuZCBzaW1wbHkgcHV0IHRleHQg c2ltaWxhciB0byB0aGlzIGluIChmcm9tIFNyaXJhbeKAmXMgbWVzc2FnZSk6DQoNCuKAnEJHUHNl YyB1cGRhdGUgc2l6ZSBpcyBzdWJqZWN0IHRvIGEgbWF4aW11bSBCR1AgdXBkYXRlIHNpemUuIFRo ZSBtYXhpbXVtIHNpemUgYXQgcHJlc2VudCBpcyA0MDk2IGJ5dGVzIFtSRkM0MjcxXSwgYW5kIGl0 IG1heSBiZSBleHRlbmRlZCB0byBhIGxhcmdlciBzaXplIGluIHRoZSBmdXR1cmUuIElmIHRoZSBz ZW5kaW5nIHJvdXRlciBkZXRlcm1pbmVzIHRoYXQgYWRkaW5nIGl0cyBTZWN1cmVfUGF0aCBTZWdt ZW50IGFuZCBTaWduYXR1cmUgU2VnbWVudCBjYXVzZXMgdGhlIEJHUHNlYyB1cGRhdGUgdG8gZXhj ZWVkIHRoZSBtYXhpbXVtIHNpemUsIHRoZW4gaXQgd2lsbCBjb252ZXJ0IHRoZSBCR1BzZWMgdXBk YXRlIHRvIGFuIHVuc2lnbmVkIHRyYWRpdGlvbmFsIEJHUCB1cGRhdGUgW3VzaW5nIHRoZSBwcm9j ZWR1cmUgaW4gU2VjdGlvbiA0LjRdIGFuZCBzZW5kIHRoZSB1bnNpZ25lZCB1cGRhdGUuIChOb3Rl OiBQbGVhc2Ugc2VlIHJlbGF0ZWQgZGlzY3Vzc2lvbiBpbiBTZWN0aW9uIDcuKeKAnQ0KDQpJIHdv dWxkIGV2ZW4ganVzdCBtZW50aW9uIHRoZSDigJxtYXhpbXVtIG1lc3NhZ2Ugc2l6ZeKAnSAod2l0 aCBubyBzcGVjaWZpYyBudW1iZXJzKSBhbmQgbGVhdmUgb3V0IG1lbnRpb24gb2YgYW55IGZ1dHVy ZSBjaGFuZ2VzLiAgVGhpcyB3YXkgdGhlIEJHUFNlYyBkb2N1bWVudHMgKDEpIGRvbuKAmXQgZGVw ZW5kIG9uIHRoZSBFeHRlbmRlZCBNZXNzYWdlcyBkb2N1bWVudCwgYW5kICgyKSB0aGV5IGRlcGVu ZCBvbiB3aGF0ZXZlciBCR1AgY2FuIGRvLiAgSWYvd2hlbiBFeHRlbmRlZCBNZXNzYWdlcyBhcmUg c2V0dGxlZCBhbmQgaW1wbGVtZW50ZWQgdGhlbiBCR1BTZWMgY2FuIG1ha2UgdXNlIG9mIHRoZW0g KGFzIGNhbiBhbnkgb3RoZXIgYXBwbGljYXRpb24gdXNpbmcgQkdQKS4NCg0KDQpUaGFua3MhDQoN CkFsdmFyby4NCg0KDQoNCg0KDQoNCg0KDQpPbiAzLzE0LzE3LCA2OjI2IFBNLCAiU3JpcmFtLCBL b3Rpa2FsYXB1ZGkgKEZlZCkiIDxrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PG1haWx0bzpr b3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292Pj4gd3JvdGU6DQoNCj4gQWx2YXJvIHJlcGxpZWQg dG8gbWUgaW4gZGV0YWlsLg0K --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5bU3BlYWtpbmcgYXMgQURdJm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5UaGUgcmVxdWlyZW1lbnQgZm9yIEV4dGVuZGVkIE1lc3NhZ2Vz IGhhcyBiZWVuIGluIHRoZSBCR1BTZWMgZHJhZnQgc2luY2UgdGhlIGJlZ2lubmluZyAoYXQgbGVh c3QgdGhlIFdHIC0wMCB2ZXJzaW9uKS4mbmJzcDsgQ2hhbmdpbmcgaXQgbm93IHdvdWxkIG1lYW4g YSBzaWduaWZpY2FudCBkZXZpYXRpb24gaW4gdGhlIHByb2Nlc3MNCiDigJMgYnV0IG5vdCBpbXBv c3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkJlZm9yZSBjb21taXR0aW5nIHRvIHN1 cHBvcnRpbmcgYW55IGNoYW5nZSB0byB0aGUgZG9jdW1lbnQsIEkgd291bGQgbGlrZSB0byBzZWUg Y2hhbmdlcyBkaXNjdXNzZWQgaW4gdGhlIHNpZHIgV0cgbGlzdC4mbmJzcDsgWW91IG1heSBldmVu IGJlIGFibGUgdG8gY29udmluY2UgdGhlIHNpZHJvcHMgQ2hhaXJzIHRvIGdpdmUgeW91IHNvbWUN CiB0aW1lIGluIENoaWNhZ28gdG8gZGlzY3VzcyBpbiBwZXJzb24uJm5ic3A7IFdlIHdvdWxkIG5l ZWQgdGhlIFdHIHRvIHJlYWNoIGNvbnNlbnN1cyBmb3Igc3VjaCBhIGNoYW5nZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5bU3BlYWtpbmcgYXMgV0cgUGFydGljaXBhbnRdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+SSB0aGluayB0aGF0IGEgcG9zc2libGUgcGF0aCBmb3J3YXJkIGlzIHRvIHRha2UgYW55IHJl ZmVyZW5jZSB0byB0aGUgRXh0ZW5kZWQgTWVzc2FnZXMgZG9jdW1lbnQgb3V0LCBhbmQgc2ltcGx5 IHB1dCB0ZXh0IHNpbWlsYXIgdG8gdGhpcyBpbiAoZnJvbSBTcmlyYW3igJlzIG1lc3NhZ2UpOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPuKAnEJHUHNlYyB1cGRhdGUgc2l6ZSBpcyBzdWJqZWN0 IHRvIGEgbWF4aW11bSBCR1AgdXBkYXRlIHNpemUuIFRoZSBtYXhpbXVtIHNpemUgYXQgcHJlc2Vu dCBpcyA0MDk2IGJ5dGVzIFtSRkM0MjcxXSwgYW5kIGl0IG1heSBiZSBleHRlbmRlZCB0byBhIGxh cmdlciBzaXplIGluIHRoZSBmdXR1cmUuIElmIHRoZSBzZW5kaW5nIHJvdXRlcg0KIGRldGVybWlu ZXMgdGhhdCBhZGRpbmcgaXRzIFNlY3VyZV9QYXRoIFNlZ21lbnQgYW5kIFNpZ25hdHVyZSBTZWdt ZW50IGNhdXNlcyB0aGUgQkdQc2VjIHVwZGF0ZSB0byBleGNlZWQgdGhlIG1heGltdW0gc2l6ZSwg dGhlbiBpdCB3aWxsIGNvbnZlcnQgdGhlIEJHUHNlYyB1cGRhdGUgdG8gYW4gdW5zaWduZWQgdHJh ZGl0aW9uYWwgQkdQIHVwZGF0ZSBbdXNpbmcgdGhlIHByb2NlZHVyZSBpbiBTZWN0aW9uIDQuNF0g YW5kIHNlbmQgdGhlIHVuc2lnbmVkDQogdXBkYXRlLiAoTm90ZTogUGxlYXNlIHNlZSByZWxhdGVk IGRpc2N1c3Npb24gaW4gU2VjdGlvbiA3LinigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5J IHdvdWxkIGV2ZW4ganVzdCBtZW50aW9uIHRoZSDigJxtYXhpbXVtIG1lc3NhZ2Ugc2l6ZeKAnSAo d2l0aCBubyBzcGVjaWZpYyBudW1iZXJzKSBhbmQgbGVhdmUgb3V0IG1lbnRpb24gb2YgYW55IGZ1 dHVyZSBjaGFuZ2VzLiZuYnNwOyBUaGlzIHdheSB0aGUgQkdQU2VjIGRvY3VtZW50cyAoMSkgZG9u 4oCZdCBkZXBlbmQgb24gdGhlIEV4dGVuZGVkDQogTWVzc2FnZXMgZG9jdW1lbnQsIGFuZCAoMikg dGhleSBkZXBlbmQgb24gd2hhdGV2ZXIgQkdQIGNhbiBkby4mbmJzcDsgSWYvd2hlbiBFeHRlbmRl ZCBNZXNzYWdlcyBhcmUgc2V0dGxlZCBhbmQgaW1wbGVtZW50ZWQgdGhlbiBCR1BTZWMgY2FuIG1h a2UgdXNlIG9mIHRoZW0gKGFzIGNhbiBhbnkgb3RoZXIgYXBwbGljYXRpb24gdXNpbmcgQkdQKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWx2YXJvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMy8xNC8xNywgNjoyNiBQTSwgJnF1b3Q7U3JpcmFtLCBLb3Rp a2FsYXB1ZGkgKEZlZCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprb3Rpa2FsYXB1ZGkuc3Jp cmFtQG5pc3QuZ292Ij5rb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jmd0OyBBbHZhcm8g cmVwbGllZCB0byBtZSBpbiBkZXRhaWwuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_-- From nobody Wed Mar 15 11:11:44 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 4F2B11316A1; Wed, 15 Mar 2017 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT7X0RUfBLDp; Wed, 15 Mar 2017 09:43:19 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EF95E13171A; Wed, 15 Mar 2017 09:43:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.137; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'Sriram, Kotikalapudi \(Fed\)'" , "'Randy Bush'" , "'Steve KENT'" Cc: , , "'Matthias Waehlisch'" , "'sidr wg list'" References: In-Reply-To: Date: Wed, 15 Mar 2017 12:38:32 -0400 Message-ID: <031501d29daa$95f44320$c1dcc960$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0316_01D29D89.0EE4C600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJvgUkdknlbchV64BNKsEAFS0ypwGwu225AcVHGkYCCCF0zqD750fA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Wed, 15 Mar 2017 11:11:42 -0700 Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:43:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0316_01D29D89.0EE4C600 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alvaro:=20 =20 Thank you for working through these issues at this late time.=20 =20 =20 IDR is talking input on this topic. So it would be good to post a = summary of your discussion to the IDR list. If it is useful, we can = still set aside time for the authors (or SIDR WG chairs) to present = their needs at IDR. If you wish this, please let the IDR chairs know so = we can set-up time.=20 =20 =20 Sue Hares=20 =20 =20 From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana) Sent: Wednesday, March 15, 2017 9:45 AM To: Sriram, Kotikalapudi (Fed); Randy Bush; Steve KENT Cc: sidrops@ietf.org; sidr-chairs@ietf.org; Matthias Waehlisch; sidr wg = list Subject: Re: [sidr] BGPsec draft and extended messages =20 Hi! =20 [Speaking as AD] =20 =20 The requirement for Extended Messages has been in the BGPSec draft since = the beginning (at least the WG -00 version). Changing it now would mean = a significant deviation in the process =E2=80=93 but not impossible. =20 Before committing to supporting any change to the document, I would like = to see changes discussed in the sidr WG list. You may even be able to = convince the sidrops Chairs to give you some time in Chicago to discuss = in person. We would need the WG to reach consensus for such a change. =20 =20 [Speaking as WG Participant] =20 I think that a possible path forward is to take any reference to the = Extended Messages document out, and simply put text similar to this in = (from Sriram=E2=80=99s message): =20 =E2=80=9CBGPsec update size is subject to a maximum BGP update size. The = maximum size at present is 4096 bytes [RFC4271], and it may be extended = to a larger size in the future. If the sending router determines that = adding its Secure_Path Segment and Signature Segment causes the BGPsec = update to exceed the maximum size, then it will convert the BGPsec = update to an unsigned traditional BGP update [using the procedure in = Section 4.4] and send the unsigned update. (Note: Please see related = discussion in Section 7.)=E2=80=9D =20 I would even just mention the =E2=80=9Cmaximum message size=E2=80=9D = (with no specific numbers) and leave out mention of any future changes. = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do. If/when = Extended Messages are settled and implemented then BGPSec can make use = of them (as can any other application using BGP). =20 =20 Thanks! =20 Alvaro. =20 =20 =20 =20 =20 =20 =20 =20 On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" = wrote: =20 > Alvaro replied to me in detail.=20 ------=_NextPart_000_0316_01D29D89.0EE4C600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Alvaro:

 

Thank you for working through these issues at this late time. =

<IDR WG chair hat on>

 

IDR is talking input on this topic.=C2=A0 So it would be good to post = a summary of your discussion to the IDR list. =C2=A0=C2=A0If it is = useful, we can still set aside time for the authors (or SIDR WG chairs) = to present their needs at IDR.=C2=A0 If you wish this, please let the = IDR chairs know so we can set-up time.

<IDR WG chair hat off>

 

Sue Hares

=C2=A0

 

From:= = sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana)
Sent: Wednesday, March 15, 2017 9:45 = AM
To: Sriram, Kotikalapudi (Fed); Randy Bush; Steve = KENT
Cc: sidrops@ietf.org; sidr-chairs@ietf.org; Matthias = Waehlisch; sidr wg list
Subject: Re: [sidr] BGPsec draft and = extended messages

 

Hi!

 =

[Speaking = as AD] 

 =

The = requirement for Extended Messages has been in the BGPSec draft since the = beginning (at least the WG -00 version).  Changing it now would = mean a significant deviation in the process =E2=80=93 but not = impossible.

 =

Before = committing to supporting any change to the document, I would like to see = changes discussed in the sidr WG list.  You may even be able to = convince the sidrops Chairs to give you some time in Chicago to discuss = in person.  We would need the WG to reach consensus for such a = change.

 =

 =

[Speaking = as WG Participant]

 =

I think = that a possible path forward is to take any reference to the Extended = Messages document out, and simply put text similar to this in (from = Sriram=E2=80=99s message):

 =

=E2=80=9CBG= Psec update size is subject to a maximum BGP update size. The maximum = size at present is 4096 bytes [RFC4271], and it may be extended to a = larger size in the future. If the sending router determines that adding = its Secure_Path Segment and Signature Segment causes the BGPsec update = to exceed the maximum size, then it will convert the BGPsec update to an = unsigned traditional BGP update [using the procedure in Section 4.4] and = send the unsigned update. (Note: Please see related discussion in = Section 7.)=E2=80=9D

 =

I would = even just mention the =E2=80=9Cmaximum message size=E2=80=9D (with no = specific numbers) and leave out mention of any future changes.  = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do.  = If/when Extended Messages are settled and implemented then BGPSec can = make use of them (as can any other application using = BGP).

 =

 =

Thanks!

 =

Alvaro.

 =

 =

 =

 =

 =

 =

 =

 =

 

> Alvaro = replied to me in detail. 

------=_NextPart_000_0316_01D29D89.0EE4C600-- From nobody Wed Mar 15 11:38:42 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 5B13D131774; Wed, 15 Mar 2017 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rpfCWt65m4V; Wed, 15 Mar 2017 11:15:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A9B51131765; Wed, 15 Mar 2017 11:15:49 -0700 (PDT) Received: from [10.33.204.119] (unknown [156.154.81.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E7E0A540A62; Wed, 15 Mar 2017 14:15:36 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Wes George In-Reply-To: Date: Wed, 15 Mar 2017 14:15:29 -0400 Cc: "Sriram, Kotikalapudi (Fed)" , Randy Bush , Steve KENT , sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Message-Id: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> References: To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Wed, 15 Mar 2017 11:38:41 -0700 Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:15:52 -0000 --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29 Content-Type: multipart/alternative; boundary="Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239" --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m behind on mail but Sriram suggested I pay attention to this, = so here=E2=80=99s a drive-by comment, and if this comes up in SIDROps in = Chicago I=E2=80=99ll do my best to attend and participate in the = discussion there. Being pragmatic, I understand that the risk is low for exceeding the max = size without extended message support based on the average AS-path = length, but I have concerns about the suggested solution that treats = unsigned updates as a fallback path for updates that would otherwise be = too large. First, I don=E2=80=99t believe that there is any construct = within the current BGPSec setup that allows for this sort of mixed mode = where most updates are signed but some subset are not. Normally it=E2=80=99= s something negotiated on session establish - either BGPSec is supported = by both neighbors, or it is not - and the BGP machinery handles updates = accordingly. So likely the document would need some additional guidance = on how that mixed mode is supposed to work. I think it=E2=80=99s pretty = straightforward since there is already a defined process for stripping = signatures and sending unsigned updates, but there=E2=80=99s sufficient = grey area that I am not comfortable leaving this =E2=80=9Cas an exercise = for the implementer=E2=80=9D since it needs to properly interoperate. = And if what is being suggested is that one update being too large drops = the entire session back to unsecured mode, that seems even worse. More generally, I have expressed concern in the past (including quite = publicly at NANOG) about =E2=80=9Cfailing open=E2=80=9D and the impacts = of this model. While it=E2=80=99s definitely the lower-risk method when = we=E2=80=99re dealing with something as critical as routing updates, it = has the net effect of creating situations where the very benefit gained = by deploying the technology is negated because any number of problems = can cause fallback to the unsecured model that is effectively the same = as having not deployed in the first place. The deployment threshold for = things like this is usually that the net improvement in protection has = to be worth the increased overhead of deployment and maintenance. I have = been having trouble making the argument that OV and PV fall on the right = side of that line due to the amount of places where things fail open by = design. Some of those concerns are addressed by work in progress to move = away from rsync and address other potential failure cases, but the = potential for what amounts to a silent failure where some subset of = routes on a session that I expect to be secured suddenly are not seems = high in this case, and thus I don=E2=80=99t see this as an acceptable = tradeoff. Given the headwinds for deployment of path validation - it requires a = certain level of hardware support (CPU/Memory) to deploy at real scale, = software features that haven=E2=80=99t been implemented yet, etc., I = don=E2=80=99t see a delay while we get extended message support sorted = as any really serious deal-breaker. Realistically, vendors and operators = will be better served if this set of features can be implemented as a = group to minimize the amount of touching and re-touching the same area = of code and certifying and deploying multiple code versions to get = everything. In other words, if I were deciding on a deployment timeline, = I=E2=80=99d plan to wait until a critical mass of features is available = either way, so whether that waiting happens now or later, the result is = the same, and the better focus would be to get Extended Messages moved = through the process with all possible haste instead of trying to pull = BGPSec back for late-stage changes to reduce its dependency on the = former. Wes George > On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) = wrote: >=20 > Hi! >=20 > [Speaking as AD] >=20 > The requirement for Extended Messages has been in the BGPSec draft = since the beginning (at least the WG -00 version). Changing it now = would mean a significant deviation in the process =E2=80=93 but not = impossible. >=20 > Before committing to supporting any change to the document, I would = like to see changes discussed in the sidr WG list. You may even be able = to convince the sidrops Chairs to give you some time in Chicago to = discuss in person. We would need the WG to reach consensus for such a = change. >=20 >=20 > [Speaking as WG Participant] >=20 > I think that a possible path forward is to take any reference to the = Extended Messages document out, and simply put text similar to this in = (from Sriram=E2=80=99s message): >=20 > =E2=80=9CBGPsec update size is subject to a maximum BGP update size. = The maximum size at present is 4096 bytes [RFC4271], and it may be = extended to a larger size in the future. If the sending router = determines that adding its Secure_Path Segment and Signature Segment = causes the BGPsec update to exceed the maximum size, then it will = convert the BGPsec update to an unsigned traditional BGP update [using = the procedure in Section 4.4] and send the unsigned update. (Note: = Please see related discussion in Section 7.)=E2=80=9D >=20 > I would even just mention the =E2=80=9Cmaximum message size=E2=80=9D = (with no specific numbers) and leave out mention of any future changes. = This way the BGPSec documents (1) don=E2=80=99t depend on the Extended = Messages document, and (2) they depend on whatever BGP can do. If/when = Extended Messages are settled and implemented then BGPSec can make use = of them (as can any other application using BGP). >=20 >=20 > Thanks! >=20 > Alvaro. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" = > = wrote: >=20 > > Alvaro replied to me in detail. --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m behind on mail but Sriram = suggested I pay attention to this, so here=E2=80=99s a drive-by comment, = and if this comes up in SIDROps in Chicago I=E2=80=99ll do my best to = attend and participate in the discussion there. 

Being pragmatic, I = understand that the risk is low for exceeding the max size without = extended message support based on the average AS-path length, but I have = concerns about the suggested solution that treats unsigned updates as a = fallback path for updates that would otherwise be too large. First, I = don=E2=80=99t believe that there is any construct within the current = BGPSec setup that allows for this sort of mixed mode where most updates = are signed but some subset are not. Normally it=E2=80=99s something = negotiated on session establish - either BGPSec is supported by both = neighbors, or it is not - and the BGP machinery handles updates = accordingly. So likely the document would need some additional guidance = on how that mixed mode is supposed to work. I think it=E2=80=99s pretty = straightforward since there is already a defined process for stripping = signatures and sending unsigned updates, but there=E2=80=99s sufficient = grey area that I am not comfortable leaving this =E2=80=9Cas an exercise = for the implementer=E2=80=9D since it needs to properly interoperate. = And if what is being suggested is that one update being too large drops = the entire session back to unsecured mode, that seems even = worse.

More = generally, I have expressed concern in the past (including quite = publicly at NANOG) about =E2=80=9Cfailing open=E2=80=9D and the impacts = of this model. While it=E2=80=99s definitely the lower-risk method when = we=E2=80=99re dealing with something as critical as routing updates, it = has the net effect of creating situations where the very benefit gained = by deploying the technology is negated because any number of problems = can cause fallback to the unsecured model that is effectively the same = as having not deployed in the first place. The deployment threshold for = things like this is usually that the net improvement in protection has = to be worth the increased overhead of deployment and maintenance. I have = been having trouble making the argument that OV and PV fall on the right = side of that line due to the amount of places where things fail open by = design. Some of those concerns are addressed by work in progress to move = away from rsync and address other potential failure cases, but the = potential for what amounts to a silent failure where some subset of = routes on a session that I expect to be secured suddenly are not seems = high in this case, and thus I don=E2=80=99t see this as an acceptable = tradeoff. 

Given the headwinds for deployment of path validation - it = requires a certain level of hardware support (CPU/Memory) to deploy at = real scale, software features that haven=E2=80=99t been implemented yet, = etc., I don=E2=80=99t see a delay while we get extended message support = sorted as any really serious deal-breaker. Realistically, vendors and = operators will be better served if this set of features can be = implemented as a group to minimize the amount of touching and = re-touching the same area of code and certifying and deploying multiple = code versions to get everything. In other words, if I were deciding on a = deployment timeline, I=E2=80=99d plan to wait until a critical mass of = features is available either way, so whether that waiting happens now or = later, the result is the same, and the better focus would be to get = Extended Messages moved through the process with all possible haste = instead of trying to pull BGPSec back for late-stage changes to reduce = its dependency on the former. 


Wes = George

On Mar 15, 2017, at 9:44 AM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:

Hi!
 
[Speaking as AD] 
 
The requirement for Extended Messages has been in = the BGPSec draft since the beginning (at least the WG -00 = version).  Changing it now would mean a significant deviation in = the process =E2=80=93 but not impossible.
 
Before committing to supporting any change to the document, I = would like to see changes discussed in the sidr WG list.  You may = even be able to convince the sidrops Chairs to give you some time in = Chicago to discuss in person.  We would need the WG to reach = consensus for such a change.
 
 
[Speaking as WG Participant]
 
I think that a possible path forward is to take any reference = to the Extended Messages document out, and simply put text similar to = this in (from Sriram=E2=80=99s message):
 
=E2=80=9CBGPsec update size is subject to a maximum BGP = update size. The maximum size at present is 4096 bytes [RFC4271], and it = may be extended to a larger size in the future. If the sending router = determines that adding its Secure_Path Segment and Signature Segment = causes the BGPsec update to exceed the maximum size, then it will = convert the BGPsec update to an unsigned traditional BGP update [using = the procedure in Section 4.4] and send the unsigned update. (Note: = Please see related discussion in Section 7.)=E2=80=9D
 
I would even just mention the =E2=80=9Cmaximum message = size=E2=80=9D (with no specific numbers) and leave out mention of any = future changes.  This way the BGPSec documents (1) don=E2=80=99t = depend on the Extended Messages document, and (2) they depend on = whatever BGP can do.  If/when Extended Messages are settled and = implemented then BGPSec can make use of them (as can any other = application using BGP).
 
 
Thanks!
 
Alvaro.
 
 
 
 
 
 
 
 
On 3/14/17, = 6:26 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> wrote:
 
> Alvaro = replied to me in detail. 

= --Apple-Mail=_38823FDC-80EB-4BD4-AB49-B746C663C239-- --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29 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----- iQIcBAEBCgAGBQJYyYTBAAoJEBdIPc22E6UhvfIP/jLa5c1jChsYZ8PJIPF3XzPx q05KjBSLdwqE96PpKeiUAh/i7pIylHC+U8SRrSfZGv5TnJgOsusFJPZUZOkAB2E0 fSlOVbnkIuuzL7hCvt7My7PHpa0ufSAPqk0sdf2wPmVnoEh6FtNSc6cVVxv7Lm8h rrQMVtMUTFushXgzvYqpqbxvk6rmQ9/ca3YRSV8SFKcY692hXAuxP5b021TSKI88 WkxuwS1gM/MiZcqSsXpzRq3XGi8zPt53QbCADU7l1MIEijUfneMwxFk1Fj/0J2r/ H5jFrZsDZnecxRCXIuihIbwlLP7G9n6S9Iwpp9OtK/fVc8w4QX/dt1jc+yqYEdX9 GPE1+VSeYrRWwWujIymzSfZaJ2EH7OCCFNLloq9G/VIdaZzyjWl1pTXVSLmKTOen WA+D90ie7wuK8+sSOqDsEkI53MB7exUE71O3tcjHu552HdSKheTEfmVJBdz5rhOe /LTbmW2kLCR+Qa8KjKlvVjjSJezldGS2yWJpHVoKQ4zElzyDsMde464Tx8pL2xu2 bVXDQbKucz3Ohkxaf+WoWxbyLyjQnS/38xPjYTXOs/Cehxqzzk3vwO/i8SlyexeK noRC4JXrAQBhHHsC0GglUUmGWOKBa7mZ5q4LQHJsj4qsdLOC9seaeYyxEsA8AqpR jvuoWKyjWnmrlgz289mC =xPn6 -----END PGP SIGNATURE----- --Apple-Mail=_63016B99-F777-4929-A6DF-D3A4C87C9E29-- From nobody Wed Mar 15 15:19:04 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 37609129C4A; Wed, 15 Mar 2017 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3x-SPsjVUUIj; Wed, 15 Mar 2017 15:18:55 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0114.outbound.protection.outlook.com [23.103.201.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB60129C2F; Wed, 15 Mar 2017 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lqEwXRnAeH8a4q+S7KQJO2b7wvf2wGMCH01R6zQP4gY=; b=OIH1n3GldmXaktJxXbpNV9/tNABmB1La6RakW/wO/UUkhLDRc+ErxmYE+Wdlv2/2Ct2iVfiS2slpVUyWLhUU4mJXH02QUyf0gHPgKQ/YV3iU9S95oTpWpMcc020TNSpkswmDWU0tTnzgs64XqRtpiclH4PHB+Vghc0YSLWc+1ic= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Wed, 15 Mar 2017 22:18:52 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0961.021; Wed, 15 Mar 2017 22:18:52 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Wes George , "Alvaro Retana (aretana)" CC: Randy Bush , Steve KENT , "sidr wg list" , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LIAIXQFgAAJcw6AAAhP9PA= Date: Wed, 15 Mar 2017 22:18:52 +0000 Message-ID: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> In-Reply-To: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:L6Gb0v9iXJyvsW4pARL0H6iaqQR+vHpV5vROYRk10JpllogvFj6ppxAjrs+RN+oGbShZzfm9TzKSZgSuZIWMg1d4LTnqzuS5h1FcS1gTWWiD3590wC/qsw1Gjy7yfXQWvombfLQH83SIAelDQyIxTFxbc9GPVDZyQJalFyvIMBrVChoB/syAeDxWhLTAhv5qRuAPqNiDm5+UXdKAtMbrvazyE+cTwHkXlmJJ/PgYrjPh0PwxuVQpc8EapmBFyWCrLRATHb3L2DsOLdJNN33EIwGrDgB61FoROZ9iSN8zYPpc7aSzUUCqlstWroG6LnRwkc7E4RdZ0HicL45AOcj9Ng== x-ms-office365-filtering-correlation-id: 71930e5e-a723-4acc-63bd-08d46bf14309 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39850400002)(39410400002)(4326008)(6246003)(102836003)(6116002)(38730400002)(189998001)(2906002)(6506006)(10710500007)(74316002)(93886004)(33656002)(790700001)(50986999)(606005)(8936002)(7110500001)(54356999)(3280700002)(66066001)(3660700001)(6436002)(19609705001)(15650500001)(5660300001)(99286003)(55016002)(6306002)(77096006)(53936002)(9686003)(236005)(54906002)(122556002)(76176999)(3846002)(2900100001)(2950100002)(2420400007)(7696004)(54896002)(7906003)(8676002)(7736002)(81166006)(229853002)(86362001)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 22:18:52.0655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:18:57 -0000 --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VzLA0KDQoNCkNvbW1lbnRzIGlubGluZSBiZWxvdyBtYXJrZWQgd2l0aCBba3NdLg0KDQoNCj4N Cj5CZWluZyBwcmFnbWF0aWMsIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSByaXNrIGlzIGxvdyBmb3Ig ZXhjZWVkaW5nIHRoZSBtYXggc2l6ZSB3aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBi YXNlZCBvbiB0aGUgYXZlcmFnZSBBUy1wYXRoIGxlbmd0aCwgYnV0IEkgaGF2ZSBjb25jZXJucyBh Ym91dCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIHRoYXQgdHJlYXRzIHVuc2lnbmVkIHVwZGF0ZXMg YXMgYSBmYWxsYmFjayBwYXRoIGZvciB1cGRhdGVzIHRoYXQgd291bGQgb3RoZXJ3aXNlIGJlIHRv byBsYXJnZS4NCj4NCg0KDQpba3NdIFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWlzdW5kZXJzdGFu ZGluZyBoZXJlLiBMZXQgbWUgdHJ5IHRvIGNsYXJpZnkuDQoNCg0KW2tzXSBUaGUgcHJvcG9zZWQg Y2hhbmdlIGlzIHNpbXBseSB0aGF0IEJHUHNlYyBzcGVjaWZpY2F0aW9uIGFja25vd2xlZGdlcyB0 aGF0IHRoZXJlIGlzIGEgbWF4aW11bSBtZXNzYWdlIHNpemUsIHdoaWNoIGlzIHByb3ZpZGVkIGJ5 IEJHUC4gKFRoYXQgaXMgNDA5NiBieXRlcyBtYXhpbXVtIHNpemUgY3VycmVudGx5IGFuZCBpbiB0 aGUgZnV0dXJlIGl0IG1heSBiZSBtb3JlLikgQkdQc2VjIHNpbXBseSBhYmlkZXMgYnkgdGhlIG1h eGltdW0gc2l6ZS4gVGhlbiB0aGUgZGVzaWduIHF1ZXN0aW9uIGlzOiBXaGF0IGRvZXMgdGhlIHNl bmRpbmcgQkdQc2VjIHJvdXRlciBkbyB3aGVuIGl0IGZpbmRzIHRoYXQgYnkgYWRkaW5nIGl0cyBT ZWN1cmVfUGF0aCBhbmQgU2lnbmF0dXJlIFNlZ21lbnQsIHRoZSBzaXplIGV4Y2VlZHMgdGhlIG1h eGltdW0gbWVzc2FnZSBzaXplPyAoVGhpcyBxdWVzdGlvbiBuZWVkcyB0byBiZSBhZGRyZXNzZWQg aW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCB2YWx1ZSBvZiB0aGUgbWF4aW11bSBzaXplIHByb3Zp ZGVkIGJ5IEJHUC4pDQoNCg0KW2tzXSBUaGUgc2Vjb25kYXJ5IHF1ZXN0aW9uIGlzIGhvdyBvZnRl biBkb2VzIGl0IGhhcHBlbiAoaS5lLiBleGNlZWRpbmcgdGhlIG1heGltdW0gc2l6ZSk/ICBZb3Ug c2VlbWVkIHRvIHNheSDigJxyaXNrIGlzIGxvdyBmb3IgZXhjZWVkaW5nIHRoZSBtYXggc2l6ZSB3 aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBiYXNlZCBvbiB0aGUgKiphdmVyYWdlKiog QVMtcGF0aCBsZW5ndGgu4oCdICBBY3R1YWxseSwgdGhlIHdvcnN0LWNhc2UgQVMtcGF0aCBsZW5n dGggd2FzIHVzZWQuIFBsZWFzZSBzZWUgdGhlIGFuYWx5c2lzIGluIG15IHByZXZpb3VzIHBvc3Qu DQoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQv bXNnMDg1MDIuaHRtbA0KDQoNCj5GaXJzdCwgSSBkb27igJl0IGJlbGlldmUgdGhhdCB0aGVyZSBp cyBhbnkgY29uc3RydWN0IHdpdGhpbiB0aGUgY3VycmVudCBCR1BTZWMgc2V0dXAgdGhhdCBhbGxv d3MgZm9yIHRoaXMgc29ydCBvZiBtaXhlZCBtb2RlIHdoZXJlIG1vc3QgdXBkYXRlcyBhcmUgc2ln bmVkIGJ1dCBzb21lIHN1YnNldCBhcmUgbm90LiBOb3JtYWxseSBpdOKAmXMgc29tZXRoaW5nIG5l Z290aWF0ZWQgb24gc2Vzc2lvbiBlc3RhYmxpc2ggLSBlaXRoZXIgQkdQU2VjIGlzIHN1cHBvcnRl ZCBieSBib3RoIG5laWdoYm9ycywgb3IgaXQgaXMgbm90IC0gYW5kIHRoZSBCR1AgbWFjaGluZXJ5 IGhhbmRsZXMgdXBkYXRlcyBhY2NvcmRpbmdseS4NCg0KDQpba3NdIFdoZW4gQkdQc2VjIGlzIG5l Z290aWF0ZWQsIGl0IHNpbXBseSBtZWFucyB0aGF0IHRoZSByb3V0ZXIgY2FuIHNlbmQvcmVjZWl2 ZSBCR1BzZWMgdXBkYXRlcy4gVHJhZGl0aW9uYWwgdW5zaWduZWQgdXBkYXRlcyBjYW4gc3RpbGwg YmUgZXhjaGFuZ2VkIG9uIHRoYXQgc2Vzc2lvbiBhcyBuZWNlc3NhcnkuIFRoaXMgd2FzIHBhcnQg b2YgdGhlIGRlc2lnbiBmcm9tIHRoZSBzdGFydC4gVGhhdOKAmXMgYmVjYXVzZSBhbiBBUyBtYXkg bmVnb3RpYXRlIEJHUHNlYyB3aXRoIGEgcGVlciBidXQgY2FuIGhhdmUgYSBjdXN0b21lciB0aGF0 IGlzIG5vdCB1cGdyYWRlZCB0byBCR1BzZWMuIE9uY2UgYSBCR1BzZWMgc2Vzc2lvbiBpcyBlc3Rh Ymxpc2hlZCwgYW4gdXBkYXRlIG1heSBoYXZlIEJHUHNlY19QYXRoIG9yICh1bnNpZ25lZCkgQVNf UEFUSCBhdHRyaWJ1dGUsIGJ1dCBub3QgYm90aC4gU2VlIHNlY3Rpb24gMi4yLCBwLjU6DQoNCg0K 4oCcQkdQIHVwZGF0ZSBtZXNzYWdlcyB3aXRob3V0IHRoZSBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUg KGkuZS4gdW5zaWduZWQgdXBkYXRlcykgTUFZIGJlDQogICBzZW50IHdpdGhpbiBhIHNlc3Npb24g cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgdXNlIG9mIEJHUHNlYw0KICAgaXMgc3Vj Y2Vzc2Z1bGx5IG5lZ290aWF0ZWQu4oCdDQoNCg0KPlNvIGxpa2VseSB0aGUgZG9jdW1lbnQgd291 bGQgbmVlZCBzb21lIGFkZGl0aW9uYWwgZ3VpZGFuY2Ugb24gaG93IHRoYXQgbWl4ZWQgbW9kZSBp cyBzdXBwb3NlZCB0byB3b3JrLiBJIHRoaW5rIGl04oCZcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk IHNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYSBkZWZpbmVkIHByb2Nlc3MgZm9yIHN0cmlwcGluZyBz aWduYXR1cmVzIGFuZCBzZW5kaW5nIHVuc2lnbmVkIHVwZGF0ZXMsIGJ1dCB0aGVyZeKAmXMgc3Vm ZmljaWVudCBncmV5IGFyZWEgdGhhdCBJIGFtIG5vdCBjb21mb3J0YWJsZSBsZWF2aW5nIHRoaXMg 4oCcYXMgYW4gZXhlcmNpc2UgZm9yIHRoZSBpbXBsZW1lbnRlcuKAnSBzaW5jZSBpdCBuZWVkcyB0 byBwcm9wZXJseSBpbnRlcm9wZXJhdGUuDQoNCg0KW2tzXSBQbGVhc2Ugc2VlIG15IHJlc3BvbnNl IGFib3ZlLiBIb3dldmVyLCBpdCBpcyB3b3J0aCBkb3VibGUgY2hlY2tpbmcgdG8gbWFrZSBzdXJl IHRoYXQgd2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcgaXMgc3RhdGVkIGNsZWFybHkgaW4gdGhlIGRv Y3VtZW50LiBJ4oCZbGwgZG8gdGhhdC4NCg0KDQo+QW5kIGlmIHdoYXQgaXMgYmVpbmcgc3VnZ2Vz dGVkIGlzIHRoYXQgb25lIHVwZGF0ZSBiZWluZyB0b28gbGFyZ2UgZHJvcHMgdGhlIGVudGlyZSBz ZXNzaW9uIGJhY2sgdG8gdW5zZWN1cmVkIG1vZGUsIHRoYXQgc2VlbXMgZXZlbiB3b3JzZS4NCg0K DQpba3NdIE5vLiBUaGF0IGlzIG5vdCBiZWluZyBzdWdnZXN0ZWQuDQoNCg0KVGhhbmtzLg0KDQoN ClNyaXJhbQ0KDQoNCg0K --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5XZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q29tbWVudHMgaW5saW5lIGJlbG93IG1hcmtl ZCB3aXRoIFtrc10uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDtCZWluZyBwcmFnbWF0aWMsIEkg dW5kZXJzdGFuZCB0aGF0IHRoZSByaXNrIGlzIGxvdyBmb3IgZXhjZWVkaW5nIHRoZSBtYXggc2l6 ZSB3aXRob3V0IGV4dGVuZGVkIG1lc3NhZ2Ugc3VwcG9ydCBiYXNlZCBvbiB0aGUgYXZlcmFnZSBB Uy1wYXRoIGxlbmd0aCwgYnV0IEkgaGF2ZSBjb25jZXJucyBhYm91dCB0aGUNCiBzdWdnZXN0ZWQg c29sdXRpb24gdGhhdCB0cmVhdHMgdW5zaWduZWQgdXBkYXRlcyBhcyBhIGZhbGxiYWNrIHBhdGgg Zm9yIHVwZGF0ZXMgdGhhdCB3b3VsZCBvdGhlcndpc2UgYmUgdG9vIGxhcmdlLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPltrc10gVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBtaXN1bmRlcnN0YW5kaW5n IGhlcmUuIExldCBtZSB0cnkgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ba3NdIFRoZSBwcm9wb3Nl ZCBjaGFuZ2UgaXMgc2ltcGx5IHRoYXQgQkdQc2VjIHNwZWNpZmljYXRpb24gYWNrbm93bGVkZ2Vz IHRoYXQgdGhlcmUgaXMgYSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSwgd2hpY2ggaXMgcHJvdmlkZWQg YnkgQkdQLiAoVGhhdCBpcyA0MDk2IGJ5dGVzIG1heGltdW0gc2l6ZSBjdXJyZW50bHkNCiBhbmQg aW4gdGhlIGZ1dHVyZSBpdCBtYXkgYmUgbW9yZS4pIEJHUHNlYyBzaW1wbHkgYWJpZGVzIGJ5IHRo ZSBtYXhpbXVtIHNpemUuIFRoZW4gdGhlIGRlc2lnbiBxdWVzdGlvbiBpczogV2hhdCBkb2VzIHRo ZSBzZW5kaW5nIEJHUHNlYyByb3V0ZXIgZG8gd2hlbiBpdCBmaW5kcyB0aGF0IGJ5IGFkZGluZyBp dHMgU2VjdXJlX1BhdGggYW5kIFNpZ25hdHVyZSBTZWdtZW50LCB0aGUgc2l6ZSBleGNlZWRzIHRo ZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZT8NCiAoVGhpcyBxdWVzdGlvbiBuZWVkcyB0byBiZSBhZGRy ZXNzZWQgaW5kZXBlbmRlbnQgb2YgdGhlIGFjdHVhbCB2YWx1ZSBvZiB0aGUgbWF4aW11bSBzaXpl IHByb3ZpZGVkIGJ5IEJHUC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+W2tzXSBUaGUgc2Vjb25kYXJ5IHF1ZXN0aW9u IGlzIGhvdyBvZnRlbiBkb2VzIGl0IGhhcHBlbiAoaS5lLiBleGNlZWRpbmcgdGhlIG1heGltdW0g c2l6ZSk/Jm5ic3A7IFlvdSBzZWVtZWQgdG8gc2F5IOKAnHJpc2sgaXMgbG93IGZvciBleGNlZWRp bmcgdGhlIG1heCBzaXplIHdpdGhvdXQgZXh0ZW5kZWQgbWVzc2FnZSBzdXBwb3J0DQogYmFzZWQg b24gdGhlICoqYXZlcmFnZSoqIEFTLXBhdGggbGVuZ3RoLuKAnSZuYnNwOyBBY3R1YWxseSwgdGhl IHdvcnN0LWNhc2UgQVMtcGF0aCBsZW5ndGggd2FzIHVzZWQuIFBsZWFzZSBzZWUgdGhlIGFuYWx5 c2lzIGluIG15IHByZXZpb3VzIHBvc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDg1MDIuaHRtbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaWRyL2N1cnJlbnQvbXNnMDg1MDIuaHRtbDwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Rmlyc3QsIEkgZG9u4oCZdCBiZWxpZXZl IHRoYXQgdGhlcmUgaXMgYW55IGNvbnN0cnVjdCB3aXRoaW4gdGhlIGN1cnJlbnQgQkdQU2VjIHNl dHVwIHRoYXQgYWxsb3dzIGZvciB0aGlzIHNvcnQgb2YgbWl4ZWQgbW9kZSB3aGVyZSBtb3N0IHVw ZGF0ZXMgYXJlIHNpZ25lZCBidXQgc29tZSBzdWJzZXQgYXJlIG5vdC4NCiBOb3JtYWxseSBpdOKA mXMgc29tZXRoaW5nIG5lZ290aWF0ZWQgb24gc2Vzc2lvbiBlc3RhYmxpc2ggLSBlaXRoZXIgQkdQ U2VjIGlzIHN1cHBvcnRlZCBieSBib3RoIG5laWdoYm9ycywgb3IgaXQgaXMgbm90IC0gYW5kIHRo ZSBCR1AgbWFjaGluZXJ5IGhhbmRsZXMgdXBkYXRlcyBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5b a3NdIFdoZW4gQkdQc2VjIGlzIG5lZ290aWF0ZWQsIGl0IHNpbXBseSBtZWFucyB0aGF0IHRoZSBy b3V0ZXIgY2FuIHNlbmQvcmVjZWl2ZSBCR1BzZWMgdXBkYXRlcy4gVHJhZGl0aW9uYWwgdW5zaWdu ZWQgdXBkYXRlcyBjYW4gc3RpbGwgYmUgZXhjaGFuZ2VkIG9uIHRoYXQgc2Vzc2lvbiBhcyBuZWNl c3NhcnkuDQogVGhpcyB3YXMgcGFydCBvZiB0aGUgZGVzaWduIGZyb20gdGhlIHN0YXJ0LiBUaGF0 4oCZcyBiZWNhdXNlIGFuIEFTIG1heSBuZWdvdGlhdGUgQkdQc2VjIHdpdGggYSBwZWVyIGJ1dCBj YW4gaGF2ZSBhIGN1c3RvbWVyIHRoYXQgaXMgbm90IHVwZ3JhZGVkIHRvIEJHUHNlYy4gT25jZSBh IEJHUHNlYyBzZXNzaW9uIGlzIGVzdGFibGlzaGVkLCBhbiB1cGRhdGUgbWF5IGhhdmUgQkdQc2Vj X1BhdGggb3IgKHVuc2lnbmVkKSBBU19QQVRIIGF0dHJpYnV0ZSwNCiBidXQgbm90IGJvdGguIFNl ZSBzZWN0aW9uIDIuMiwgcC41OiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJxCR1AgdXBkYXRlIG1lc3Nh Z2VzIHdpdGhvdXQgdGhlIEJHUHNlY19QYXRoIGF0dHJpYnV0ZSAoaS5lLiB1bnNpZ25lZCB1cGRh dGVzKSBNQVkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VudCB3aXRoaW4gYSBzZXNzaW9uIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciBvciBub3QgdGhlIHVzZSBvZiBCR1BzZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaXMgc3VjY2Vz c2Z1bGx5IG5lZ290aWF0ZWQu4oCdJm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0O1NvIGxpa2VseSB0aGUgZG9jdW1lbnQgd291 bGQgbmVlZCBzb21lIGFkZGl0aW9uYWwgZ3VpZGFuY2Ugb24gaG93IHRoYXQgbWl4ZWQgbW9kZSBp cyBzdXBwb3NlZCB0byB3b3JrLiBJIHRoaW5rIGl04oCZcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk IHNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYSBkZWZpbmVkIHByb2Nlc3MNCiBmb3Igc3RyaXBwaW5n IHNpZ25hdHVyZXMgYW5kIHNlbmRpbmcgdW5zaWduZWQgdXBkYXRlcywgYnV0IHRoZXJl4oCZcyBz dWZmaWNpZW50IGdyZXkgYXJlYSB0aGF0IEkgYW0gbm90IGNvbWZvcnRhYmxlIGxlYXZpbmcgdGhp cyDigJxhcyBhbiBleGVyY2lzZSBmb3IgdGhlIGltcGxlbWVudGVy4oCdIHNpbmNlIGl0IG5lZWRz IHRvIHByb3Blcmx5IGludGVyb3BlcmF0ZS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ba3NdIFBsZWFz ZSBzZWUgbXkgcmVzcG9uc2UgYWJvdmUuIEhvd2V2ZXIsIGl0IGlzIHdvcnRoIGRvdWJsZSBjaGVj a2luZyB0byBtYWtlIHN1cmUgdGhhdCB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZyBpcyBzdGF0ZWQg Y2xlYXJseSBpbiB0aGUgZG9jdW1lbnQuIEnigJlsbCBkbyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDtB bmQgaWYgd2hhdCBpcyBiZWluZyBzdWdnZXN0ZWQgaXMgdGhhdCBvbmUgdXBkYXRlIGJlaW5nIHRv byBsYXJnZSBkcm9wcyB0aGUgZW50aXJlIHNlc3Npb24gYmFjayB0byB1bnNlY3VyZWQgbW9kZSwg dGhhdCBzZWVtcyBldmVuIHdvcnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltrc10gTm8uIFRoYXQgaXMgbm90IGJl aW5nIHN1Z2dlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3JpcmFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DM2PR09MB0446CCB7DE24681F23429D7784270DM2PR09MB0446namp_-- From nobody Sat Mar 18 07:00:27 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 7952112708C; Sat, 18 Mar 2017 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 5iz8yms2nrJc; Sat, 18 Mar 2017 07:00:17 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7FC12751F; Sat, 18 Mar 2017 07:00:17 -0700 (PDT) Received: from [IPv6:2610:178:8::40f6:8f10:4485:ece9] (unknown [IPv6:2610:178:8:0:40f6:8f10:4485:ece9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E94FA540DC8; Sat, 18 Mar 2017 10:00:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Wes George In-Reply-To: Date: Sat, 18 Mar 2017 09:59:48 -0400 Cc: "Alvaro Retana (aretana)" , Randy Bush , Steve KENT , sidr wg list , Matthias Waehlisch , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Message-Id: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> To: "Sriram, Kotikalapudi (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:00:20 -0000 --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD Content-Type: multipart/alternative; boundary="Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE" --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) = wrote: >=20 > >First, I don=E2=80=99t believe that there is any construct within the = current BGPSec setup that allows for this sort of mixed mode where most = updates are signed but some subset are not. Normally it=E2=80=99s = something negotiated on session establish - either BGPSec is supported = by both neighbors, or it is not - and the BGP machinery handles updates = accordingly. >=20 >=20 > [ks] When BGPsec is negotiated, it simply means that the router can = send/receive BGPsec updates. Traditional unsigned updates can still be = exchanged on that session as necessary. This was part of the design from = the start. That=E2=80=99s because an AS may negotiate BGPsec with a peer = but can have a customer that is not upgraded to BGPsec. Once a BGPsec = session is established, an update may have BGPsec_Path or (unsigned) = AS_PATH attribute, but not both. See section 2.2, p.5: >=20 >=20 > =E2=80=9CBGP update messages without the BGPsec_Path attribute (i.e. = unsigned updates) MAY be > sent within a session regardless of whether or not the use of = BGPsec > is successfully negotiated.=E2=80=9D WG] My original email was insufficiently precise when expressing my = concern on this, as it was written in relative haste. I=E2=80=99ll try = again. I always interpreted this as allowing for updates that were never = secured (because the downstream neighbor doesn=E2=80=99t support it) to = be sent between BGPSec capable neighbors, as you explain above. This = makes perfect sense given BGPSec=E2=80=99s decision to not allow = partially-signed updates. My concern is that using this text as justification for updates that = otherwise would be secured (because they came through a path of = neighbors that all support BGPSec end to end) dropping back to insecure = on account of the size of the update violates the principle of least = astonishment and again allows for degraded security by failing open. Wes --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 15, 2017, at 6:18 PM, Sriram, Kotikalapudi (Fed) = <kotikalapudi.sriram@nist.gov> wrote:
 
>First, I = don=E2=80=99t believe that there is any construct within the current = BGPSec setup that allows for this sort of mixed mode where most updates = are signed but some subset are not. Normally it=E2=80=99s something = negotiated on session establish - either BGPSec is supported by both = neighbors, or it is not - and the BGP machinery handles updates = accordingly.
 
 
[ks] When BGPsec is negotiated, it simply means that the = router can send/receive BGPsec updates. Traditional unsigned updates can = still be exchanged on that session as necessary. This was part of the = design from the start. That=E2=80=99s because an AS may negotiate BGPsec = with a peer but can have a customer that is not upgraded to BGPsec. Once = a BGPsec session is established, an update may have BGPsec_Path or = (unsigned) AS_PATH attribute, but not both. See section 2.2, = p.5:  
 
 
=E2=80=9CBGP update messages without the BGPsec_Path = attribute (i.e. unsigned updates) MAY be
   sent = within a session regardless of whether or not the use of BGPsec
   is = successfully negotiated.=E2=80=9D   


WG] My original email = was insufficiently precise when expressing my concern on this, as it was = written in relative haste. I=E2=80=99ll try again. I always interpreted = this as allowing for updates that were never secured (because the = downstream neighbor doesn=E2=80=99t support it) to be sent between = BGPSec capable neighbors, as you explain above. This makes perfect sense = given BGPSec=E2=80=99s decision to not allow partially-signed = updates. 
My concern is that using this text as = justification for updates that otherwise would be secured (because they = came through a path of neighbors that all support BGPSec end to end) = dropping back to insecure on account of the size of the update violates = the principle of least astonishment and again allows for degraded = security by failing open.

Wes
= --Apple-Mail=_5A39DCE0-59F0-4925-8677-58BA9BF971AE-- --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD 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----- iQIcBAEBCgAGBQJYzT1VAAoJEBdIPc22E6UhD28P/iRgJHCkSRe+wun3cMO0XgXZ Q7CRxkerks0fJ0tE+fM3P+uOz8tavvsPevwC0u6i/LopTblpZQv4wnKPCFlekc1B Lu9ogoxA18XwpA6rKVxW2Jc/4ZSyUA4SmKBcUnelbSReyN3uQTl3GoiLSMgQt5sA pQCpFD71Xqcfy2QLUk8giZac5nJT+rmuUlzAmFfiBf6mxBhaOXd1uZVPYng6GISJ IDdxWzM7yxTnoJWe2flbuY9/4wGBGXGVdOPF+YBL6pS1CQK/m7U+Ycy/lF1PEPFS 4GSvfPS6YiZMKBVgR8VmPJydMnBcS9EP5nSjFqZHI6X+IUjij1qzVCw5CYJIVaQ7 +WcGM2PpBOa8zCi+pY/pWwqmKQ9n55GdAf50wslQDt1yEprMkmVkXvTSBwKM4RMK p9oewhW7ykKmv6AnIu32QGDPzDyL8UwW4n4eKB4cKEAq4MAAIH4X/I6Gf5L86DI3 GeOfNbMx3AuTXvFmTO4Us6Methv95oaP4V48p2qNfDIJ2AUYr7QQZ29Xi54jxi/2 FN+YXj18ME0YLmxxUzQfFyrSv+OzviOOr9eMvQwX3unqxQpMALpPRGG7PByw6oLP 9JOXxjhAXBYri2KnEw1HKjeNDDB4nidYbIJBD+Ut7uSqcI8hvE2NIWg2726kO4Yv BSF4He48Z5JkRWlNIVop =QpJk -----END PGP SIGNATURE----- --Apple-Mail=_F70881C1-A36E-481D-9FCF-4C1BB9D239BD-- From nobody Tue Mar 21 06:54:36 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 19F2F129871 for ; Tue, 21 Mar 2017 06:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 UtFnooCd9-0V for ; Tue, 21 Mar 2017 06:54:32 -0700 (PDT) Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) (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 20F8D129494 for ; Tue, 21 Mar 2017 06:54:28 -0700 (PDT) Received: by mail-pf0-f170.google.com with SMTP id o126so80399043pfb.3 for ; Tue, 21 Mar 2017 06:54:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=Hfh9BnTG0GFpWoX+u6rdJ4sSviasj3d3f4kExb3rA5I=; b=PBAbj+ppbs3sK4GbsVzfPZG8xGfDax1KzdUMTYcozwetJWVRmUkGwDSV/dkF5e20oY k6q0KpLiSxA8BEx8/JdyjB6KQ8RgXcVMy7gU9HxdhzY6cRbH1aKTdzSwSvLMqb6qpS9Y +ExbPFxW+x8wYiCRsWJLao+VGbm+yklorwE53zVNN6aXY8cb130JixGYU7Ee8xPpeAc3 2r4LqQihrvu93G46amyiV6CxhVtzP+sNjWn4UUUxQyH1taE89CBftYex5Ky2aBaiEqkE Oy4z6WCnhrt9Qm0RmaJhoml7r8OYHOx/+C42Bq4SYeU5PShmK270dFPRisC/ndxU3iYJ aXAw== X-Gm-Message-State: AFeK/H0210Y2S4ys6cTK05Dq/zXciv9u/EmXrMa3BKXs1/N0OM+TAJHtnZ02juv0slnPpw== X-Received: by 10.98.31.20 with SMTP id f20mr39800821pff.193.1490104468127; Tue, 21 Mar 2017 06:54:28 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id x21sm40216074pgf.15.2017.03.21.06.54.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 06:54:27 -0700 (PDT) Date: Tue, 21 Mar 2017 14:54:23 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: <20170321135423.tye6fyixctuyzzay@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:54:34 -0000 Hi all, While implementing some ordering-dependent routing policy I came across an IPv4 resource for which two ROAs exist: one authorises AS 0, another one authorises a regular RIR assigned ASN. This made me question my assumptions around AS 0: does a ROA with AS 0 preclude other valid ROAs? Should they co-exist? Reading https://tools.ietf.org/html/rfc7607, I (unfortunatly) see no mention or codification on how to proceed when multiple ROAs exist for a resource, in context of AS 0. When I asked the owner of the ROAs whether this was intentional, the answer was "yes". It is now my understanding that the existence of one valid RPKI ROA does not preclude the existence of another valid RPKI ROA, even when one of the ROAs authorises AS 0 as the origin. Is this understanding shared within this group? If so, should we file an errata on RFC 7607 to request clarification on this issue when the document is updated? Kind regards, Job From nobody Tue Mar 21 08:27:23 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 86A44129A5A for ; Tue, 21 Mar 2017 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVyQb6ZcRcUg for ; Tue, 21 Mar 2017 08:27:18 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22CC129A65 for ; Tue, 21 Mar 2017 08:27:13 -0700 (PDT) X-TM-DID: fef139ab98d4162706aebb46b66bdb9d Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Declan Ma In-Reply-To: <20170321135423.tye6fyixctuyzzay@Vurt.local> Date: Tue, 21 Mar 2017 23:22:36 +0800 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170321135423.tye6fyixctuyzzay@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:27:21 -0000 Job, [RFC6483] states =A1=B0A ROA with a subject of AS 0 (AS 0 ROA) is an = attestation by the holder of a prefix that the prefix described in the = ROA, and any more specific prefix, should not be used in a routing = context.=A1=B1 I believe this issue bears relevance with how RP software responds to = multiple ROAs existence with ROA 0 included.=20 As for the example you provide, if both ROAs have been validated = successfully, it is up to RPs to generate output to BGP speakers. =20 Even a ROA with AS 0 doesn=A1=AFt preclude other valid ROAs, we should = not encourage this operation.=20 Declan(Di)=20 > =D4=DA 2017=C4=EA3=D4=C221=C8=D5=A3=AC21:54=A3=ACJob Snijders = =D0=B4=B5=C0=A3=BA >=20 > Hi all, >=20 > While implementing some ordering-dependent routing policy I came = across > an IPv4 resource for which two ROAs exist: one authorises AS 0, = another > one authorises a regular RIR assigned ASN. >=20 > This made me question my assumptions around AS 0: does a ROA with AS 0 > preclude other valid ROAs? Should they co-exist? >=20 > Reading https://tools.ietf.org/html/rfc7607, I (unfortunatly) see no > mention or codification on how to proceed when multiple ROAs exist for = a > resource, in context of AS 0. >=20 > When I asked the owner of the ROAs whether this was intentional, the > answer was "yes". It is now my understanding that the existence of one > valid RPKI ROA does not preclude the existence of another valid RPKI > ROA, even when one of the ROAs authorises AS 0 as the origin. Is this > understanding shared within this group? >=20 > If so, should we file an errata on RFC 7607 to request clarification = on > this issue when the document is updated? >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 21 08:41:55 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 816F6129ADF; Tue, 21 Mar 2017 08:41:50 -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, HTML_MESSAGE=0.001, 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 hUmon1nqgoed; Tue, 21 Mar 2017 08:41:47 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0091.outbound.protection.outlook.com [23.103.201.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CA5129B37; Tue, 21 Mar 2017 08:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AiUJHsScDjub6YXUXAEyIF7d21E3WJKoldp7+8LxWD8=; b=mIn9pk2JhUCem4ZAuncr3Z64Hcs4XtisVduMrTzBpLQLU7v2lQE7AQSMKus5ynymjjvHXTxoKmEsvMvmXxAnl2TeaX7q2vXIUK0yGjoec7e8yNnAuUJU0daV4350JXpiU2XD//AU9SW1Evi4ZY7ynLVb3huQk41cg6i6LESLWBo= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 15:39:06 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 15:39:06 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Wes George CC: "Alvaro Retana (aretana)" , Randy Bush , Steve KENT , sidr wg list , "Matthias Waehlisch" , "sidr-chairs@ietf.org" , Sean Turner , "sidrops@ietf.org" Thread-Topic: [sidr] BGPsec draft and extended messages Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAAEOhsAACVRtkMAChNseAABALyAAACP7LIAIXQFgAAJcw6AAAhP9PAAhaHeAACZP1lg Date: Tue, 21 Mar 2017 15:39:06 +0000 Message-ID: References: <4CF183FB-F22F-4133-BE91-86CA44DBEDBE@puck.nether.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:PjMlIdMJ0MoEi+vgGeLWUpbRtlLvXoZVQwVe7JGoxArDTGC6hnLYaGAf274ATBABkXrgJwqpW7739fYSh3+o4jOTFVGc5ZPTVvpj6UFaLrOXOlz/vBk7Jwj1LgWqI18LZau2Z0EtnSANSMRTzx/qU4AJs00AgQj4hjGJRrH04LaNgbmOv+4BPC5qur7Gjs9c1800m/Hyhel0KX0db0JBoDGqieZ5SF49Mk80YtEzylSMx4jW8Zy9yeIqDJLUe4EMtyn563go5PyLrEt9dARPuTenhh6Ug4LIHExi6JXJXv48tn8XaiSWNPG9XuyCJrW2RkxzVq1DmKDy4bngC1Yf2Q== x-ms-office365-filtering-correlation-id: a7139243-deae-48ef-e84b-08d470706929 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(50986999)(76176999)(7736002)(54356999)(110136004)(2900100001)(2420400007)(93886004)(7520500002)(38730400002)(229853002)(3846002)(122556002)(102836003)(6116002)(4326008)(6246003)(19609705001)(790700001)(7110500001)(77096006)(6506006)(3280700002)(53936002)(3660700001)(86362001)(25786008)(189998001)(8676002)(10710500007)(6436002)(54896002)(6306002)(54906002)(2906002)(15650500001)(9686003)(6916009)(2950100002)(99286003)(7696004)(66066001)(33656002)(55016002)(81166006)(8936002)(74316002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 15:39:06.7443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Sidrops] [sidr] BGPsec draft and extended messages X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:41:50 -0000 --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VzLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBNeSBjb21tZW50cyBiZWxvdy4N Cg0KDQrigKYuLiBzbmlwIOKApi4NCj5XR10gTXkgb3JpZ2luYWwgZW1haWwgd2FzIGluc3VmZmlj aWVudGx5IHByZWNpc2Ugd2hlbiBleHByZXNzaW5nIG15IGNvbmNlcm4gb24gdGhpcywgYXMgaXQg d2FzIHdyaXR0ZW4gaW4gcmVsYXRpdmUgaGFzdGUuIEnigJlsbCB0cnkgYWdhaW4uIEkgYWx3YXlz IGludGVycHJldGVkIHRoaXMgYXMgYWxsb3dpbmcgZm9yIHVwZGF0ZXMgdGhhdCB3ZXJlIG5ldmVy IHNlY3VyZWQgKGJlY2F1c2UgdGhlIGRvd25zdHJlYW0gbmVpZ2hib3IgZG9lc27igJl0IHN1cHBv cnQgaXQpIHRvIGJlIHNlbnQgYmV0d2VlbiBCR1BTZWMgY2FwYWJsZSBuZWlnaGJvcnMsIGFzIHlv dSBleHBsYWluIGFib3ZlLiBUaGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2UgZ2l2ZW4gQkdQU2Vj4oCZ cyBkZWNpc2lvbiB0byBub3QgYWxsb3cgcGFydGlhbGx5LXNpZ25lZCB1cGRhdGVzLg0KDQoNCj5X R10gTXkgY29uY2VybiBpcyB0aGF0IHVzaW5nIHRoaXMgdGV4dCBhcyBqdXN0aWZpY2F0aW9uIGZv ciB1cGRhdGVzIHRoYXQgb3RoZXJ3aXNlIHdvdWxkIGJlIHNlY3VyZWQgKGJlY2F1c2UgdGhleSBj YW1lIHRocm91Z2ggYSBwYXRoIG9mIG5laWdoYm9ycyB0aGF0IGFsbCBzdXBwb3J0IEJHUFNlYyBl bmQgdG8gZW5kKSBkcm9wcGluZyBiYWNrIHRvIGluc2VjdXJlIG9uIGFjY291bnQgb2YgdGhlIHNp emUgb2YgdGhlIHVwZGF0ZSB2aW9sYXRlcyB0aGUgcHJpbmNpcGxlIG9mIGxlYXN0IGFzdG9uaXNo bWVudCBhbmQgYWdhaW4gYWxsb3dzIGZvciBkZWdyYWRlZCBzZWN1cml0eSBieSBmYWlsaW5nIG9w ZW4uDQoNCg0KQkdQc2VjX1BhdGggYXR0cmlidXRlIHNpemUgZG9lcyBub3QgZXhjZWVkIDRLLg0K RUNEU0EgUC0yNTYgc2lnbmF0dXJlIHNpemUgaXMgNjQgYnl0ZXMuDQpTbywgI2J5dGVzIGFkZGVk IHRvIEJHUHNlY19QYXRoIGFyZSBhYm91dCAxMDAgYnl0ZXMgcGVyIEFTLg0KRXh0ZW5kZWQgbWVz c2FnZSB3YXMgdGhvdWdodCB0byBiZSBuZWVkZWQgd2hlbiBSU0EtMjA0OCAoMjU2IGJ5dGVzIHNp Zykgd2FzIGluaXRpYWxseSBwcm9wb3NlZC4NCldpdGggUC0yNTYsIEJHUHNlY19QYXRoIGF0dHJp YnV0ZSBkb2VzIG5vdCBleGNlZWQgNEsgdXAgdG8gNDAgQVNlcyBpbiB0aGUgcGF0aC4NCihOb3Rl OiBBUyBwcmVwZW5kcyBhcmUgY29tcHJlc3NlZCBvdXQgZHVlIHRvIHVzZSBvZiBwQ291bnQuKQ0K SW4gdGhlIEludGVybmV0LCB0aGUgb2JzZXJ2ZWQgbWF4aW11bSBBUyBwYXRoIGxlbmd0aCBpcyAx NCBbSHVzdG9uXS4NClRoZSBtYXhpbXVtIEFTIHBhdGggbGVuZ3RoIGhhcyByZW1haW5lZCBpbiB0 aGlzIGJhbGwgcGFyayBmb3IgbWFueSB5ZWFycyBub3cuDQpUaGVyZWZvcmUsIGl0IGRvZXNu4oCZ dCBhcHBlYXIgdGhhdCDigJxkcm9wcGluZyBiYWNrIHRvIOKAnGluc2VjdXJlIG9uIGFjY291bnQg b2YNCnRoZSBzaXplIG9mIHRoZSB1cGRhdGXigJ0gIHdvdWxkIGhhcHBlbiBpbiBwcmFjdGljZS4N Cg0KDQpTbywgdGhlIHF1ZXN0aW9uIGlzOiBEb2VzIHRoZSBXRyBhZ3JlZSB0aGF0IHRoZSBleHRl bmRlZCBtZXNzYWdlcyBkcmFmdA0KY2FuIGJlIGFuIEluZm9ybWF0aXZlIHJhdGhlciB0aGFuIGEg Tm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KDQpBbHZhcm8gKHNwZWFraW5nIGFzIFdHIFBhcnRpY2lw YW50KSBzdWdnZXN0ZWQ6DQoNCg0K4oCcSSB3b3VsZCBldmVuIGp1c3QgbWVudGlvbiB0aGUg4oCc bWF4aW11bSBtZXNzYWdlIHNpemXigJ0gKHdpdGggbm8gc3BlY2lmaWMgbnVtYmVycykgYW5kIGxl YXZlIG91dCBtZW50aW9uIG9mIGFueSBmdXR1cmUgY2hhbmdlcy4gIFRoaXMgd2F5IHRoZSBCR1BT ZWMgZG9jdW1lbnRzICgxKSBkb27igJl0IGRlcGVuZCBvbiB0aGUgRXh0ZW5kZWQgTWVzc2FnZXMg ZG9jdW1lbnQsIGFuZCAoMikgdGhleSBkZXBlbmQgb24gd2hhdGV2ZXIgQkdQIGNhbiBkby4gIElm L3doZW4gRXh0ZW5kZWQgTWVzc2FnZXMgYXJlIHNldHRsZWQgYW5kIGltcGxlbWVudGVkIHRoZW4g QkdQU2VjIGNhbiBtYWtlIHVzZSBvZiB0aGVtIChhcyBjYW4gYW55IG90aGVyIGFwcGxpY2F0aW9u IHVzaW5nIEJHUCku4oCdDQoNCg0KU3RldmUgS2VudCBzYWlkIGVhcmxpZXIgaW4gdGhlIHRocmVh ZDoNCg0KDQrigJxJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIG9taXQgdGhlIGV4dGVuZGVkIG1l c3NhZ2UgZmVhdHVyZSwgZ2l2ZW4gdGhlIHVzZSBvZiBFQ0RTQSBQLTI1Ni7igJ0NCg0KDQpTcmly YW0NCg0KDQoNCg== --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZXMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRp b24uIE15IGNvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKApi4uIHNuaXAg4oCmLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtXR10gTXkgb3JpZ2luYWwg ZW1haWwgd2FzIGluc3VmZmljaWVudGx5IHByZWNpc2Ugd2hlbiBleHByZXNzaW5nIG15IGNvbmNl cm4gb24gdGhpcywgYXMgaXQgd2FzIHdyaXR0ZW4gaW4gcmVsYXRpdmUgaGFzdGUuIEnigJlsbCB0 cnkgYWdhaW4uIEkgYWx3YXlzIGludGVycHJldGVkIHRoaXMgYXMgYWxsb3dpbmcgZm9yIHVwZGF0 ZXMgdGhhdCB3ZXJlIG5ldmVyIHNlY3VyZWQgKGJlY2F1c2UgdGhlIGRvd25zdHJlYW0NCiBuZWln aGJvciBkb2VzbuKAmXQgc3VwcG9ydCBpdCkgdG8gYmUgc2VudCBiZXR3ZWVuIEJHUFNlYyBjYXBh YmxlIG5laWdoYm9ycywgYXMgeW91IGV4cGxhaW4gYWJvdmUuIFRoaXMgbWFrZXMgcGVyZmVjdCBz ZW5zZSBnaXZlbiBCR1BTZWPigJlzIGRlY2lzaW9uIHRvIG5vdCBhbGxvdyBwYXJ0aWFsbHktc2ln bmVkIHVwZGF0ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1dHXSBNeSBjb25jZXJuIGlz IHRoYXQgdXNpbmcgdGhpcyB0ZXh0IGFzIGp1c3RpZmljYXRpb24gZm9yIHVwZGF0ZXMgdGhhdCBv dGhlcndpc2Ugd291bGQgYmUgc2VjdXJlZCAoYmVjYXVzZSB0aGV5IGNhbWUgdGhyb3VnaCBhIHBh dGggb2YgbmVpZ2hib3JzIHRoYXQgYWxsIHN1cHBvcnQgQkdQU2VjIGVuZCB0byBlbmQpIGRyb3Bw aW5nIGJhY2sgdG8gaW5zZWN1cmUgb24gYWNjb3VudCBvZiB0aGUgc2l6ZSBvZg0KIHRoZSB1cGRh dGUgdmlvbGF0ZXMgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBhc3RvbmlzaG1lbnQgYW5kIGFnYWlu IGFsbG93cyBmb3IgZGVncmFkZWQgc2VjdXJpdHkgYnkgZmFpbGluZyBvcGVuLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJHUHNlY19Q YXRoIGF0dHJpYnV0ZSBzaXplIGRvZXMgbm90IGV4Y2VlZCA0Sy48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RUNEU0EgUC0yNTYgc2lnbmF0dXJlIHNpemUgaXMgNjQgYnl0ZXMuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sICNieXRlcyBhZGRlZCB0byBCR1BzZWNfUGF0aCBhcmUg YWJvdXQgMTAwIGJ5dGVzIHBlciBBUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkV4dGVuZGVkIG1lc3NhZ2Ugd2FzIHRob3VnaHQgdG8gYmUgbmVlZGVkIHdoZW4gUlNBLTIw NDggKDI1NiBieXRlcyBzaWcpIHdhcyBpbml0aWFsbHkgcHJvcG9zZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIFAtMjU2LCBCR1BzZWNfUGF0aCBhdHRyaWJ1dGUg ZG9lcyBub3QgZXhjZWVkIDRLIHVwIHRvIDQwIEFTZXMgaW4gdGhlIHBhdGguPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTm90ZTogQVMgcHJlcGVuZHMgYXJlIGNvbXByZXNz ZWQgb3V0IGR1ZSB0byB1c2Ugb2YgcENvdW50Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIHRoZSBJbnRlcm5ldCwgdGhlIG9ic2VydmVkIG1heGltdW0gQVMgcGF0aCBs ZW5ndGggaXMgMTQgW0h1c3Rvbl0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgbWF4aW11bSBBUyBwYXRoIGxlbmd0aCBoYXMgcmVtYWluZWQgaW4gdGhpcyBiYWxsIHBh cmsgZm9yIG1hbnkgeWVhcnMgbm93Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVyZWZvcmUsIGl0IGRvZXNu4oCZdCBhcHBlYXIgdGhhdCDigJxkcm9wcGluZyBiYWNr IHRvIOKAnGluc2VjdXJlIG9uIGFjY291bnQgb2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhlIHNpemUgb2YgdGhlIHVwZGF0ZeKAnSZuYnNwOyB3b3VsZCBoYXBwZW4g aW4gcHJhY3RpY2UuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGUgcXVlc3Rpb24gaXM6IERvZXMgdGhlIFdH IGFncmVlIHRoYXQgdGhlIGV4dGVuZGVkIG1lc3NhZ2VzIGRyYWZ0DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbiBiZSBhbiBJbmZvcm1hdGl2ZSByYXRoZXIgdGhhbiBh IE5vcm1hdGl2ZSByZWZlcmVuY2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx2YXJvIChzcGVha2luZyBhcyBXRyBQ YXJ0aWNpcGFudCkgc3VnZ2VzdGVkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEkgd291bGQgZXZlbiBqdXN0IG1l bnRpb24gdGhlIOKAnG1heGltdW0gbWVzc2FnZSBzaXpl4oCdICh3aXRoIG5vIHNwZWNpZmljIG51 bWJlcnMpIGFuZCBsZWF2ZSBvdXQgbWVudGlvbiBvZiBhbnkgZnV0dXJlIGNoYW5nZXMuJm5ic3A7 IFRoaXMgd2F5IHRoZSBCR1BTZWMgZG9jdW1lbnRzICgxKSBkb27igJl0IGRlcGVuZCBvbiB0aGUg RXh0ZW5kZWQgTWVzc2FnZXMgZG9jdW1lbnQsIGFuZCAoMikgdGhleSBkZXBlbmQgb24gd2hhdGV2 ZXINCiBCR1AgY2FuIGRvLiZuYnNwOyBJZi93aGVuIEV4dGVuZGVkIE1lc3NhZ2VzIGFyZSBzZXR0 bGVkIGFuZCBpbXBsZW1lbnRlZCB0aGVuIEJHUFNlYyBjYW4gbWFrZSB1c2Ugb2YgdGhlbSAoYXMg Y2FuIGFueSBvdGhlciBhcHBsaWNhdGlvbiB1c2luZyBCR1ApLuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0ZXZl IEtlbnQgc2FpZCBlYXJsaWVyIGluIHRoZSB0aHJlYWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcSSB0aGluayBp dCBtYWtlcyBzZW5zZSB0byBvbWl0IHRoZSBleHRlbmRlZCBtZXNzYWdlIGZlYXR1cmUsIGdpdmVu IHRoZSB1c2Ugb2YgRUNEU0EgUC0yNTYu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3JpcmFtPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_-- From nobody Tue Mar 21 08:51:06 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 132E4129AC4 for ; Tue, 21 Mar 2017 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] 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 ouIixEfWrgEx for ; Tue, 21 Mar 2017 08:50:32 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) (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 0044B126D05 for ; Tue, 21 Mar 2017 08:50:22 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id o126so81617093pfb.3 for ; Tue, 21 Mar 2017 08:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=kA/8L3Ur2vVkuJ0Qt8C1wUGMvJoAv5cFw9iaf+Ws0mU=; b=TsV1d0e2XYdrRAVUfA5GoLI9dxp05EO/lXWcWEahFrUnwyF37VD+sta43kraYdAr4U DDYYutwl54vQ7ykGzCrr/WjrfrwXOTfL4lXYgzXmURHfu2Wdp3KOGo3m8qYw+NiA72Cc a7S0P3RCox/BlD+EFoXjD1NMr4vEzv7IijXcUvwd76nHtSmk0gfsP1dSk2bzUCIfTR9T exrSOGRH/Z6jMXGgAvPwwDeYFpvttNBcAkAftKB0aEF5fIgvVg39XNPJ3J3qK4cG6Dxa WKDfd9FYyxNujZPboHq+fx4EmIlUUu3JKdSCE/XyACb41/szRdv3rlDixaoOeX/IGiim 67aQ== X-Gm-Message-State: AFeK/H2FRH6/dmmKu5jrKqcO2HKrRaKdI+6/RRnB82eGXdQDIhqa9m+zBOSRLbQqTggp2w== X-Received: by 10.84.160.195 with SMTP id v3mr48624312plg.161.1490111422466; Tue, 21 Mar 2017 08:50:22 -0700 (PDT) Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id p9sm11671387pfe.22.2017.03.21.08.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 08:50:21 -0700 (PDT) Date: Tue, 21 Mar 2017 16:50:18 +0100 From: Job Snijders To: Declan Ma Cc: sidrops@ietf.org Message-ID: <20170321155018.ufekfatlgrelgih5@Vurt.local> References: <20170321135423.tye6fyixctuyzzay@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:50:34 -0000 Hi Declan, On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote: > [RFC6483] states “A ROA with a subject of AS 0 (AS 0 ROA) is an > attestation by the holder of a prefix that the prefix described in the > ROA, and any more specific prefix, should not be used in a routing > context.” > > I believe this issue bears relevance with how RP software responds to > multiple ROAs existence with ROA 0 included. > > As for the example you provide, if both ROAs have been validated > successfully, it is up to RPs to generate output to BGP speakers. > > Even a ROA with AS 0 doesn’t preclude other valid ROAs, we should not > encourage this operation. How and why would you discourage this, if it is a valid mode of operation? Clarity is king. There may be legitimate use cases for doing this. Kind regards, Job From nobody Tue Mar 21 09:05: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 271D6129AB2 for ; Tue, 21 Mar 2017 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMfowJwsETGD for ; Tue, 21 Mar 2017 09:05:03 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DAB1200F1 for ; Tue, 21 Mar 2017 09:05:03 -0700 (PDT) X-TM-DID: a5a23315f39ddc6a8f9e54d6ca0d97c6 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Declan Ma In-Reply-To: <20170321155018.ufekfatlgrelgih5@Vurt.local> Date: Wed, 22 Mar 2017 00:00:21 +0800 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44BEFF34-13C2-4660-8439-B46F86E935F2@zdns.cn> References: <20170321135423.tye6fyixctuyzzay@Vurt.local> <20170321155018.ufekfatlgrelgih5@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:05:06 -0000 Job, > =D4=DA 2017=C4=EA3=D4=C221=C8=D5=A3=AC23:50=A3=ACJob Snijders = =D0=B4=B5=C0=A3=BA >=20 > Hi Declan, >=20 > On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote: >> [RFC6483] states =A1=B0A ROA with a subject of AS 0 (AS 0 ROA) is an >> attestation by the holder of a prefix that the prefix described in = the >> ROA, and any more specific prefix, should not be used in a routing >> context.=A1=B1 >>=20 >> I believe this issue bears relevance with how RP software responds to >> multiple ROAs existence with ROA 0 included.=20 >>=20 >> As for the example you provide, if both ROAs have been validated >> successfully, it is up to RPs to generate output to BGP speakers. =20 >>=20 >> Even a ROA with AS 0 doesn=A1=AFt preclude other valid ROAs, we = should not >> encourage this operation.=20 >=20 > How and why would you discourage this, if it is a valid mode of > operation? Clarity is king. There may be legitimate use cases for = doing > this. >=20 There MAY be legitimate use cases for doing this. These cases should be justified before the WG discuss how to update RFC = 7607. I am open to this operation, hoping to see more detailed context in = which you said the owner of the ROAs was intentional to do that.=20 Declan (Di)=20 From nobody Tue Mar 21 10:56:41 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 120A1129C53 for ; Tue, 21 Mar 2017 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 3YXkpO56TkKH for ; Tue, 21 Mar 2017 10:56:38 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2A6129C48 for ; Tue, 21 Mar 2017 10:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2535; q=dns/txt; s=iport; t=1490118998; x=1491328598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jnG8GuJWiV+Zdm8Te7S6EMw9IsIlaMemzHhR1l207R8=; b=clE5FX/y6F2Am2Sk7hI/BcmT9ebqhsv7oWwLjvPWP3WNkBmJQYHv2zXH ycAhzI4eeLgM/SmgQxlZwmYVLPlArdqnnyJFcXmRkd2f2cI/mjJueA68T Ex77TP+5KJdoxf0SXkYtsv3RQ4+d8/ZtvOVqv3plQjcBM92DUG9uWK8H7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAQBaaNFY/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1uKEJFelUSCDh8LgkKCbEoCgxQ/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBHwFMCwwEAgEIEQQBAQEBAwsYAgMCJwsUCQgCBAENBQiJfA6MW?= =?us-ascii?q?Z1WAYIqikoBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEIhUaEb4RbgnyCYgWcUAG?= =?us-ascii?q?GeYtDggSPMohViwkBHziBBFgVQYRXHYFjdYcGK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,200,1486425600"; d="scan'208";a="400452497" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 17:56:37 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2LHubch020448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 17:56:37 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 12:56:36 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 12:56:36 -0500 From: "Jakob Heitz (jheitz)" To: Declan Ma , Job Snijders CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] rfc7607 & multiple ROAs covering same resource Thread-Index: AQHSokquSLcghRhkE0CIUEYJW7z96KGfvSwAgAAHvQCAAALPgP//x9Ew Date: Tue, 21 Mar 2017 17:56:36 +0000 Message-ID: <15c6acae82454db0861f4dddf998669a@XCH-ALN-014.cisco.com> References: <20170321135423.tye6fyixctuyzzay@Vurt.local> <20170321155018.ufekfatlgrelgih5@Vurt.local> <44BEFF34-13C2-4660-8439-B46F86E935F2@zdns.cn> In-Reply-To: <44BEFF34-13C2-4660-8439-B46F86E935F2@zdns.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.211] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:56:40 -0000 RFC 7607 does use the word "only": This allows a resource holder to signal that a prefix (and the more specifics) should not be routed by publishing a ROA listing AS 0 as the only origin. https://tools.ietf.org/html/rfc6483 In an environment of a collection of valid ROAs, a route's validity state is considered to be "valid" if any ROA provides a "valid" outcome. It's validity state is considered to be "invalid" if one (or more) ROAs provide an "invalid" outcome and no ROAs provide a "valid" outcome. The ROA for AS 0 provides an "invalid" outcome. However, the other ROA provides a "valid" outcome. Therefore, the final outcome is "valid". Thanks, Jakob. > -----Original Message----- > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Declan Ma > Sent: Tuesday, March 21, 2017 9:00 AM > To: Job Snijders > Cc: sidrops@ietf.org > Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource >=20 > Job, >=20 > > =1B$B:_=1B(B 2017=1B$BG/=1B(B3=1B$B7n=1B(B21=1B$BF|!$=1B(B23:50=1B$B!$= =1B(BJob Snijders =1B$B > > > Hi Declan, > > > > On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote: > >> [RFC6483] states =1B$B!H=1B(BA ROA with a subject of AS 0 (AS 0 ROA) i= s an > >> attestation by the holder of a prefix that the prefix described in the > >> ROA, and any more specific prefix, should not be used in a routing > >> context.=1B$B!I=1B(B > >> > >> I believe this issue bears relevance with how RP software responds to > >> multiple ROAs existence with ROA 0 included. > >> > >> As for the example you provide, if both ROAs have been validated > >> successfully, it is up to RPs to generate output to BGP speakers. > >> > >> Even a ROA with AS 0 doesn=1B$B!G=1B(Bt preclude other valid ROAs, we = should not > >> encourage this operation. > > > > How and why would you discourage this, if it is a valid mode of > > operation? Clarity is king. There may be legitimate use cases for doing > > this. > > >=20 > There MAY be legitimate use cases for doing this. >=20 > These cases should be justified before the WG discuss how to update RFC 7= 607. >=20 > I am open to this operation, hoping to see more detailed context in which= you said the owner of the ROAs was > intentional to do that. >=20 > Declan (Di) >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 21 11:00:53 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09027129C58; Tue, 21 Mar 2017 11:00:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Xq7E8riBEcZw; Tue, 21 Mar 2017 11:00:38 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403C6129C43; Tue, 21 Mar 2017 11:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MtlZXKhMN2w6ttqnjcOR4pO7BvG72Tnzd7z/mUAwiB0=; b=d/VjByct7fNy3HPQRLOhbeaRpRHJIE9t7pfX97ajE6cOhG4pOjSavqOHUu9ijepaHi9xn+1XnEKkiPcGREicjJOT60OnuIfFZwcKq8ZGBcitzm2IYiWYiS8X+saU0NmQjOxphOGlX4pw+TYEoRimptGpdYDyNl88qdyNFKYZKtM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 18:00:36 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 18:00:36 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "grow@ietf.org" , "idr@ietf.org" CC: "sidr wg list (sidr@ietf.org)" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" Thread-Topic: operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4w== Date: Tue, 21 Mar 2017 18:00:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.110.145] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 7:xBQU71LM1+X3o0+Ty1/UwWlrOxncq+oJt+62mY5tIjRUmVCwGVQXIHZSBKkAqv27yEORlnSHP/t2qyis88m6fPo0AEOR51q3CpIH/HhBi6Qne7E21djlT8YEKgYZUlIt+mlN2YhFsLqzhyilxM88LemjTUvwMFpoLJiYbT8Oacg+9Ugs8PJzFksOesYoQsyO10C0G4A8oPkyRJr5bRgGsq0g9JDs2HvulqryB6sxTFuuE6YA9y7Zg8ORXhybY9Q6FeM9tCcNwO1WAjT0olpg28Zi48HvrsgLRnQMZRM1rrj09CCqaMzF7oW5yZomtbOs1GdDcccXwn28l5rrCbN3ZA== x-ms-office365-filtering-correlation-id: 7ba95e3f-b4b6-4025-082b-08d470842d66 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(305945005)(86362001)(3280700002)(7736002)(74316002)(3660700001)(6506006)(38730400002)(2906002)(2900100001)(54356999)(50986999)(66066001)(7696004)(33656002)(5660300001)(6436002)(55016002)(966004)(53936002)(9686003)(99286003)(54906002)(6306002)(77096006)(122556002)(8936002)(189998001)(8676002)(81166006)(3846002)(6116002)(2501003)(102836003)(4326008)(25786009)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 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: 21 Mar 2017 18:00:36.3476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Subject: [Sidrops] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:00:41 -0000 Inviting comments especially from GROW WG folk (network operators).=20 Please look at this and address the question posed at the end. Thank you. The most common form of route leak occurs when multi-homed=20 customer AS-C receives a route from its transit provider AS-A and leaks it to another transit provider AS-B. =20 [RFC 7908 https://tools.ietf.org/html/rfc7908 ] Customer AS-C is often the single point of failure. AS-A and AS-B may be doing intra-AS community tagging etc.=20 perfectly well to prevent route leaks, but AS-C does not and ends up leakin= g. The leaked route propagates via AS-B to the rest of Internet=20 due to prefer customer route policy. (Example: Google/Hathway/Airtel leak - https://bgpmon.net/what-caused-the-google-service-interruption/ =20 see many more examples in RFC 7908 ) A solution component for this has long been discussed in=20 SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ).=20 The solution involves AS-A setting a field (in an optional transitive attri= bute) in BGP update to indicate that=20 (1) it is sending the route to a customer AS (or lateral peer), and=20 (2) the route SHOULD be considered a leak if subsequently received from a customer or a lateral peer. This is one component of the overall solution. It has been presented and discussed and I believe accepted in SIDR/IDR/GROW over the last few years (at least since 2014). Question:=20 >From an operator point of view, are you willing to place a piece of relationship info (as stated above) in the BGP update for the significant gain of a route leak solution that works well to detect/stop route leaks that do happen, and prevents single point of failures in incremental/partial deployment scenarios? Sriram=20 P.S. There is already immense BGP-derived public data out there on AS peeri= ng relations: http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data-s= elected-id=3D39=20 http://bgp.he.net/AS7018#_graph4=20 =20 =20 =20 From nobody Tue Mar 21 11:26:41 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 C974212950C for ; Tue, 21 Mar 2017 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pLbHwZ3uV528 for ; Tue, 21 Mar 2017 11:26:37 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0097.outbound.protection.outlook.com [104.47.36.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEF9129C64 for ; Tue, 21 Mar 2017 11:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iGo5kCGeE1KQ2GnCIfQtS+kcjHQWP1AYEozTWqtYc/o=; b=fs0T8FGq78S34W2211DuhS3TOPmBSV7xYfhN4MYnVKb0GlTGTWWQnA2nsmg7x1UwOmYjqV30SI/mLtbJmZLk3xemS6sXbLMPPI6zRIMPSl4AqnyvM6yBPRn4sHGHCYnrvIm5o0QYdXYQt4m5+Yac0uFnDyvbBZjZwijZBbPplcA= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.164] (66.129.241.12) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 18:26:34 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <15c6acae82454db0861f4dddf998669a@XCH-ALN-014.cisco.com> Date: Tue, 21 Mar 2017 14:26:29 -0400 CC: Declan Ma , Job Snijders , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: References: <20170321135423.tye6fyixctuyzzay@Vurt.local> <20170321155018.ufekfatlgrelgih5@Vurt.local> <44BEFF34-13C2-4660-8439-B46F86E935F2@zdns.cn> <15c6acae82454db0861f4dddf998669a@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR12CA0002.namprd12.prod.outlook.com (10.168.222.12) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: 650a1760-f357-4ebe-5213-08d47087ce51 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 3:RQl27JZjcZOWla1ms7rJMnXPOhh2bpL0i5njy8/wXc42up3l3fme2PLBbOns/NPBS8/d/7prGbdfA+Mp4K0PyoW4Z561WqncluIV+rFkc9117fkWw9NL1rXk80ZeTw9mTgt7Bv5RTLwVrfuPugMJ2lpIAyJZnZtKdVGPSepcNA6msM51jh+Tbs9nI07N1ROBaWOel2oQwMi8Qxa32zX2T0xu5lcJqIT5XAKhZOxVp616nxOE4XKjVKpi2Ybv6uMe4FJ8i4Fc+fpJn0hRtLLy0oBo4cH8SMN8kcKAW3ZAcKQ=; 25:zqTbKjFkIamNrpwt/77DMypQAwZr8jDo4NeszeAx4lNdtDThVbWUEAqkzlE5m4fIGz/SLGzfIYrcdk+yZypx4+xk3OecbQyxtfui5TSVZ+0v4bvdhuZMi70wJL2SHjFMPdRzHepFIjdjmdlwArJvtJ89aJeFLQnUqJ5qD7VgiMDp4cfOqwYGgdRCm7/M2GwJ/XlypZ0aIuL1J2pDwf6e2xKOZ6RXpGTFPNP8lZnqTrImpKzCHIG69Xto8p9X7t+dFt4qh1n6kqlhP7KY2GuuBxpxxY2dI2ZwNDIiYW0tRJcCjTY98tfDX19rXTDvFGOxS4XF+xld0C0PNgTvpbXTXHjsf3kk8hodlzouPH6P7sXOByAj+1eEuK9k1NzuRvOkD4L0FvWRXg5ev70iZJS93DWH45ltwmehgkY8va97QY8Rb4pOxKFJ/F6KaMhpRK+wBIRJnsH5zgH3E6Txev/WlA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 31:a2faIOjfr76MJ1gsbCex+L5h1A3RCiYZsIm6ZQKybFndj6deFwTOMwdnJAw5cwGc7plPdqUYqMBoCzn55KFvcmQI3pCCF81ElkfhAPzLKPlPo9N9ZnkQ3mpVTt05YYDsmRjiLmpi5jPYzpUqXDi+YhrsEwXdFxOxpmR5dH6z0ewZEuTIYZI/SS8htVathob7v5LyZ0BpfX75GJ8wyKuZ8yFoIpyMEO4kD1llEjKT2OpwNESCLkUYSo95Hllq/ifTdI0nJx+HS8EAqoTsTxHP1lN+hI4+96emskPYg7sTzIg=; 20:dYlb1LmIu47renVH39SryowvEjbObjEWx9r5JhaeHR8tZDChY7VZWe6PAf5wNIj+ERaUw+NKx1+ND8PBujp2hdefJXK2DtwWsuPhKZm/BM1ZZ5aMnnci+orHjIMELzrR/lGDeuDTjDoOXmaZsaVZsHTewtQgHvSOP74Fe8T5KzWK9RBKuWuTW013rM9JgGie1g9NwlZpZVFJ77ZcxPOeg4xy+FthH1+ErdqVBxiFu++Evf/01A8S5jyWd/A2GagFuleLsG3DKDLMYGjqNmTzLKCpnBZD6JKQ6o7ymKYPfxtwMRcFn7xws1USQsWst9ZDG71XwGNNmE7Pz93zcdTAXoqhWjXGIy6MIpbcMcvm2XIjUKaIhDhtaVteRzJacIZ5oX1KVDyzZHAZueJUMwEjHsV6WDGOcXq9x4uXVX1xK5q+VqzroFff1+IXv15biCKrl4meMOJ+lXkPj0nB2sG+4CnDIaLWzQe/e8H3wS0HEsIri4HvfhQXpT2ec9kF+T7vA8339ByYhPvD1PVhhxkQKClSQ4nLWR45J9f4/S+9Rg2qt0tz9zS7ZAFZI7r5vZB4CjhwJJd6jlYWSxvJSPJTyr0i1dIemGD182xhRCg0gV4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 4:n5cnbfDN6HDl3+BG5D9dmUjrjZuPWttHNaiFqYLkeS5AmTsek5HYwuEg3Nr0RC0bTHcXA3+SYUjSYG7v1ozjbwS8ZJ6pMmiXyX7VOgYoDRZreMnB2bxww5BXUwJuhnaGP40bkIHnPvhurAHpC1WpgbWWwkce4Shjde8F7ajQDSP6bJ+VpLS1cZn2UeotkdOWRinJMm3FspSzVhR7k8Zzcw5gNfSQrwNz0SPGXNW09ukaUme/7yR02BVXLGADDcy9h0OzvQNK64YEkYB5Z/RfFyaCNp96CuZcf8+rhjlSVui/4NWJYYRZD3Sbsv96ErwiNSe0Tmxt79keIcj1lPnhKZXfpOsvppRt00vRuCM9f9WskzvEm1kK288LaWdjqahfXn31EUhFpM0uuUwvzIWjqN4psI1oiglhqLj8L2ZvDqulA5FBQdemenVY58YwxjSIsYLCFL3peBQt7lz6CPZPTLODLmqq3+mETV4DBxGjajiaUOemxUseoGog4WoMzUfxWP40g4eyptyKYgV5ZncnLU7c/be2YbIEMDC8znxOqNTwfZWKcv9RJ9Cf4lhznADowDJqaQO+x1HfO7ORNd8OHnxCHNX9MeuD2eXUA1UqOr+kpJSiOcUaIp0XLLc7iU9wjg+79BTHHOwAd26JE+8LmB154Cm9BsNbCs/hvJTVmYY= X-Forefront-PRVS: 02530BD3AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(377454003)(13464003)(24454002)(82746002)(6486002)(90366009)(77096006)(8746002)(81166006)(189998001)(93886004)(229853002)(6306002)(54906002)(6246003)(42186005)(53546009)(110136004)(4326008)(25786009)(7736002)(47776003)(50226002)(305945005)(38730400002)(57306001)(83716003)(8676002)(86362001)(53936002)(23676002)(76176999)(5660300001)(3846002)(6916009)(6666003)(33656002)(36756003)(2950100002)(50986999)(6116002)(66066001)(50466002)(2906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:[172.29.37.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1TUIyNTAwOzIzOkw1T0RDTDllc0k0cDZta1M4cXJ3UE1NTC83?= =?utf-8?B?VUNRS2xTMGRxZjBjY2lSOThhenUycXA4N05VNERObFZnZmZyZ1ZjL0xZcE9L?= =?utf-8?B?SlpMd212S1N6VFBQZFhkdE1UNzQyUHFUV3F6anRCSE5NYUwrZEkwY21RVktQ?= =?utf-8?B?TG1FeHM4ZU5HeFBmMW1QbXFFblEwN0JORjJ6WEE5YWN1WnR5bTJiZTZldjZB?= =?utf-8?B?QmNESk1CRWVTR0dGaGpoUWFzQjhzTGg0ZGc2ZDVNNGxnTkdtNWJWRTlvM3Y1?= =?utf-8?B?K3diY0x6Vy9PeUdCeW11OEQ5aGFBdTBCeklweUZDKzhCa1lreDdBelhpQmJC?= =?utf-8?B?eUtYSDFFcnlMOFdQMDFMejljaFVZd3ByaXhLUHpSeDlkTkkzUDE4ZUpvT2VT?= =?utf-8?B?TWpWcGVtZXRYVFo0eElxaERWbWFraDJmSmJPTHZhK28zUHpQOWFvS3dnVEhR?= =?utf-8?B?UlFkL3pPYSt3TytGYVREUjhDNVRpSTE4d1V0ZnN3aWJXU1RiRSt3T3E4UnM4?= =?utf-8?B?VUpkTEYxZDlIcDhPZlpxNy9yYlRqaFRuQWs3d0s0MUI4eWw2TTU5RTNtL3dl?= =?utf-8?B?Wm1zVHFMME5OZTYvL29DOEVuVks2M1MzUHAzbXFMU3dDemNWNTh2bElMckVx?= =?utf-8?B?RTdOVGdldlFTY2dqeHU1a0dnNlhpNWZYSUd1VDJzemRsS2hCRTRuWDZCY21E?= =?utf-8?B?Z1FuYjdzc0puamJBMVNRMlljTlBDRHIxZHJEMGRtN3pCaDQvVnh2WWRnUUFU?= =?utf-8?B?NVp5U0hFSXVlUlBpQzVMdzdPdFJ2T2d1RWdiWTRudDk3WUxuUG5OVUJYNUd4?= =?utf-8?B?ck9Vb1VpV1piaEwybmp6bElGaHlnakluWXExLzFVV2NLRjZaL3BjVkI5Zno4?= =?utf-8?B?aVdCR3ppUjFuNzV2Ym5HcUFsdkZhRVdadVFmYkJKOWFmbDRUTFZKQWZOcFY2?= =?utf-8?B?UzBiK3pkL3Y4S0VEblhxMFNFZlpSQU0xcGozYUdPVmR6MEVXL0VIc0RKc29D?= =?utf-8?B?Ykxnb09qWitxdmx4eExMSHk0Z1RPcWlPd2Yrb2J5UHIvZlhtUDFsc3ZwdzVH?= =?utf-8?B?bjcyRVcwOUxkQ2NzdjUzOFdwMVhhZVBhWmxCYzRGdk0xZHUxNlh6RzNhTmJX?= =?utf-8?B?N3ptUHRoVkNZK29qOFdpYnFVNkFvMnMrZHB5cWZMVFVrREozaUY1dnY2Y01D?= =?utf-8?B?WlVzVWZDbnZ2MWw5NUN1YXFpVnczZ0Q2aGNNNm03WmFYNzlBQ3krbXRMQldX?= =?utf-8?B?clplSFFYZElZelk4b2RkYVY4QXM4cW5mZmNmVzJadmZtUUIyZ3B5OUxKcUI0?= =?utf-8?B?enV6R0hHS1Y0OFNVSVYwWDFzWkxFOURSNmVSVHJKQ2g2c3V4QzV4T1dFSWVS?= =?utf-8?B?R3RvaUhsMWpHWmMyUkYyT0t2UGtyTVY0TDJHdHBRa2VtYWMwR2tHUzl3TXFa?= =?utf-8?B?M3FKd1ZDNzhDVUZEeXR3SGJ2dFFBWjZOeGFkS2tNVXBTVGFKQjI4VHZyTnBt?= =?utf-8?B?THdHc1NFY3Q1TDJwWmtMeXlrUzBGWm9YZnY0cGhoZWZkd3U5ZVpaR2JLOUtO?= =?utf-8?B?aUxnYXF5QWlZMVc1aTFHblBmNFpwTi84K2FMSnF3QUp4UEhKeXBsRkJnYjBB?= =?utf-8?B?SmpUTkFMRmJYUnNtSFozLzNtVlpaTjdqU05IVm52Z21VRnYxQUdwc2hFdVV5?= =?utf-8?B?aENMZUVuU0lFaDhEM0UzSmxqOGM1UFVLamNwYUNySS9WUnpTeURtRTlidWFi?= =?utf-8?B?dUU5MC85NGUzVG95KzhnZz09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:jUTwWWMBxF+P3qv52eu4c4+1vz4PT97zcdg75y2WbD/QqVOk90Q4v7KG3TukOMRbkUEJmopx5qZwUvn/Jjs/XtnPygqkvtSqlCGoHfDL9Q4F03DpgMKaYJfKbClHsTR4tdvmpvd3XA22l1JNjK8uCMA84INKwswKnwKuQMr5vxkxc9xzF63yuEMBURI24NJDig1uPfFusxXrs+EAZCZc0n30v56/1Tsy47rqQJi36DsFhnSlREyRi2WNVBmIty+f5GeoyreSxIMn5ZBB8+xjz7TCVbQ7cpvkvHTuk22Yh8XeErV2jfk6kmReDxW0sXz4PuVFsOW2Pmtvgvdu5WruYgeWReYs375IjB6N5Ce34oMUiTi38bGh86MbLN+qfILitSZTFfPE06xoshMoy2t91iPd2tOnwXV1phaIoGpMfqc=; 5:YzllpuikpOtmV5bf34oVMouABCHq171mdZhsnGltIox/B3/90Dq3Q+GpfcqaN3sQ5s6b6ogvumZ37mWZWqCfLpY7i1rGxLzr8LMIelPC93KDninNBvtvaoBx8qBkA/jztDB4cZ8MTgVOIAkpKopgnw==; 24:le3GfL0wM1/nJMLM9TyWjFL5wIKokQvGU2/2eDSG2QMeqsw/8l54q3PHVN9y7ZR5emPztXqp2BYwt6bR3325Gx9C6gtDwuXijN40Pg09DYQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 7:xGRBwaYfzQesg5OBmWlf7uaSkhlxQbPfiyo94lHPZT0gcFstay6fA/U1gPHLAjcDDu5l8cgzrqDFMtuvbKWepf2hzN+x6mBobzccyZFoEgBqwiVG404jGdBp/qV7BCiFpvWUyEnsZ5yh29FtY5FPF4E//EIAp5eufQpP+4S8tPiJlMbAc+4Vgjs0p9+TtAwehc6qrxHxeGteo6clyWlIao9GcM+C7dqbxXZq/I0Ju66Q38t24ZXJD23yezsY2JRyVdC28zlgc2FJU97IeyzBEFuSY4bUqJOz4wyyS+jTfAMq77HLEIlQtKdGcS0HU4QFC5FL06Cp5W63pI8m9AbzOQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 18:26:34.6611 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:26:40 -0000 To add to this, there's a fairly obvious use case for having two extant = ROAs, one for AS 0 and one for another ASN -- make-before-break. I'm not = sure why you'd persistently have both of them, but it seems harmless. Or = at least "mostly harmless" to quote D. Adams. As for 7606 itself, I think nothing needs to be changed. The text = related to ROAs is only there to provide motivation -- the only = normative language in the RFC is in section 2, and it doesn't talk about = ROAs or route validation. I just reread the section and it seems clear = to me. In short: don't put AS 0 on the wire in a BGP message. The = conversation we're now having is evidence no good deed goes unpunished = -- if the motivating text had been omitted and only section 2 published, = we'd be good I guess. The 6483 section 4 language trips over itself a bit -- if it were still = in draft I'd suggest removing the "by convention" language since it's = nonsense. But it's harmless nonsense (or at least "mostly harmless") = since in the very next clause it says "this is not a strict = requirement". Doesn't seem like there's a problem in need of fixing. --John > On Mar 21, 2017, at 1:56 PM, Jakob Heitz (jheitz) = wrote: >=20 > RFC 7607 does use the word "only": >=20 > This allows a resource holder to signal > that a prefix (and the more specifics) should not be routed by > publishing a ROA listing AS 0 as the only origin. >=20 >=20 > https://tools.ietf.org/html/rfc6483 >=20 > In an environment of a collection of valid ROAs, a route's validity > state is considered to be "valid" if any ROA provides a "valid" > outcome. It's validity state is considered to be "invalid" if one > (or more) ROAs provide an "invalid" outcome and no ROAs provide a > "valid" outcome. >=20 > The ROA for AS 0 provides an "invalid" outcome. > However, the other ROA provides a "valid" outcome. > Therefore, the final outcome is "valid". >=20 > Thanks, > Jakob. >=20 >=20 >> -----Original Message----- >> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Declan = Ma >> Sent: Tuesday, March 21, 2017 9:00 AM >> To: Job Snijders >> Cc: sidrops@ietf.org >> Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource >>=20 >> Job, >>=20 >>> =E5=9C=A8 2017=E5=B9=B43=E6=9C=8821=E6=97=A5=EF=BC=8C23:50=EF=BC=8CJob= Snijders =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> Hi Declan, >>>=20 >>> On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote: >>>> [RFC6483] states =E2=80=9CA ROA with a subject of AS 0 (AS 0 ROA) = is an >>>> attestation by the holder of a prefix that the prefix described in = the >>>> ROA, and any more specific prefix, should not be used in a routing >>>> context.=E2=80=9D >>>>=20 >>>> I believe this issue bears relevance with how RP software responds = to >>>> multiple ROAs existence with ROA 0 included. >>>>=20 >>>> As for the example you provide, if both ROAs have been validated >>>> successfully, it is up to RPs to generate output to BGP speakers. >>>>=20 >>>> Even a ROA with AS 0 doesn=E2=80=99t preclude other valid ROAs, we = should not >>>> encourage this operation. >>>=20 >>> How and why would you discourage this, if it is a valid mode of >>> operation? Clarity is king. There may be legitimate use cases for = doing >>> this. >>>=20 >>=20 >> There MAY be legitimate use cases for doing this. >>=20 >> These cases should be justified before the WG discuss how to update = RFC 7607. >>=20 >> I am open to this operation, hoping to see more detailed context in = which you said the owner of the ROAs was >> intentional to do that. >>=20 >> Declan (Di) >>=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 Tue Mar 21 14:06:54 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 9787B1293D8 for ; Tue, 21 Mar 2017 14:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOx5bYlbczoK for ; Tue, 21 Mar 2017 14:04:05 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 5884712EE46 for ; Tue, 21 Mar 2017 14:04:05 -0700 (PDT) X-Original-To: sidrops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 25A8F619A9 for ; Tue, 21 Mar 2017 21:55:14 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D0D3D606E8; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id C21C96B17D; Tue, 21 Mar 2017 21:55:13 +0100 (CET) Date: Tue, 21 Mar 2017 21:55:13 +0100 From: Gert Doering To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170321205513.GA2367@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: X-Mailman-Approved-At: Tue, 21 Mar 2017 14:06:53 -0700 Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 21:04:07 -0000 Hi, On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > >>From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? I'm not sure it will do any good. Those ISPs that care about the garbage their customers try to inject already do prefix/as-path filtering. Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer router sending out unfiltered garbage won't have "send-community" enabled either). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Mar 21 15:33:05 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 4F0121293E4; Tue, 21 Mar 2017 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yop8UWtzmMYZ; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 A0E561299D6; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b140so57059674iof.1; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=WSsVexnRwM6tmHe16Ea4zuR6nKfRzYrtIWdztwRtFSYinnCQkiiHgZ0ZWkVNcKdVY/ s+/zCHz1kjfmCQr0e9fZ8ItumA2s+FGeF6myOKzTis/uZiTmIOcqj5qKFwOL+6jG48IB AchG8r9wT0SIOkLCVCG/sg4jEJAnPkVQyBgqwAeFH1sHQ13I9whZpNTiX24f7WW43mNB wNuBrQ4eT9yOa+jPC5gR3m4T7WyhPRb8oipfLACKl7i5rWD9bG/twvcqFvtOWXr4AF8q 4FGBCSzq89v6ii7mHikRKYzo86RXRuaY9s0LrpZKRxBaHX2h5ncbzStJmIYhAKQOmKU4 Kg6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qsY+bWNf4uVp4x+J0c2SJTRhOlzE4eRrYm0v2JAQb9g=; b=RQtP8FZ0VUYanPXF0akXdX7cvNcCa1riN86eDNsU0ud2SShc+/9AEnOSmVpHInGGK2 Bn+rHGyeVJiPTL/PvRIi2J14RIRJ5YLJ4cZSdUbpznuqo3GqcZWqyICo1CmgeLRdBL6r B7rqSU1lWCP/nZu2+5FbcehJ0CPPza83SxwIm3pcDVPPR2glKW3Dkh14oGAocVYXybti xs6lo+gOUEVKz1KCF1y7i/tFaV5ayGz8hFKYYUhoFO3GE2nd89pN+P0g2DhSeEkjHfNp Y4vW0zer+ETx//jj+AupHwEA5fiBvTwWi/QcEAqVXQAnJiBUotgAq5llN8ynqVHnremX 1vkg== X-Gm-Message-State: AFeK/H2y8fy8wQgmMhfoLSTc20qd6oqwQhRbqAslaPRUHO2K1hOlt9lPBrephBjB/shOT0ER3O8VLmXu/nfn1Q== X-Received: by 10.107.157.146 with SMTP id g140mr32456766ioe.63.1490134783056; Tue, 21 Mar 2017 15:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Tue, 21 Mar 2017 15:19:42 -0700 (PDT) In-Reply-To: <20170321205513.GA2367@Space.Net> References: <20170321205513.GA2367@Space.Net> From: Brian Dickson Date: Tue, 21 Mar 2017 15:19:42 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a11409824696c41054b450a11 Archived-At: X-Mailman-Approved-At: Tue, 21 Mar 2017 15:33:04 -0700 Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:19:45 -0000 --001a11409824696c41054b450a11 Content-Type: text/plain; charset=UTF-8 Pre-emptive top-post in case anyone mistakes the technique proposed: This will NOT be implemented via communities. The proposal is for a NEW optional transitive attribute. If any operators can answer the original question, this will be very helpful. Thank you in advance to any and all operators. Reminder on optional+transitive logic - If the attribute is not understood/implemented/enabled, the attribute is passed unmodified. - If it is understood & implemented & enabled, behavior is subject to the applicable standards. - Thus, optional transitives are "opt-in", by definition. The proposal itself is an IDR WG I-D, and as such not finalized; input here is definitely helpful in reaching consensus, understanding requirements, etc. Brian On Tue, Mar 21, 2017 at 1:55 PM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote: > > >>From an operator point of view, > > are you willing to place a piece of relationship info (as stated above) > > in the BGP update for the significant gain of a route leak solution > > that works well to detect/stop route leaks that do happen, > > and prevents single point of failures in incremental/partial > > deployment scenarios? > > I'm not sure it will do any good. > > Those ISPs that care about the garbage their customers try to inject > already do prefix/as-path filtering. > > Those ISPs that do not care today will not add bother to add a filter on > this well-known community value (... and most likely, the customer > router sending out unfiltered garbage won't have "send-community" > enabled either). > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a11409824696c41054b450a11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pre-emptive top-post in case anyone mistakes the technique= proposed: This will NOT be implemented via communities.

The proposal is for a NEW optional transitive attribute.
If any operators can answer the original question, this will b= e very helpful. Thank you in advance to any and all operators.=C2=A0
<= div>
Reminder on optional+transitive logic=C2=A0
- = If the attribute is not understood/implemented/enabled, the attribute is pa= ssed unmodified.=C2=A0
- If it is understood & implemented &a= mp; enabled, behavior is subject to the applicable standards.
- T= hus, optional transitives are "opt-in", by definition.
=
The proposal itself is an IDR WG I-D, and as such not finali= zed; input here is definitely helpful in reaching consensus, understanding = requirements, etc.

Brian

On Tue, Mar 21, 2017 at 1:55 PM,= Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 06:00:36PM +0000, Sriram, Kotikalapudi (Fed) wrote:=
> >>From an operator point of view,
> are you willing to place a piece of relationship info (as stated above= )
> in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen,
> and prevents single point of failures in incremental/partial
> deployment scenarios?

I'm not sure it will do any good.

Those ISPs that care about the garbage their customers try to inject
already do prefix/as-path filtering.

Those ISPs that do not care today will not add bother to add a filter on this well-known community value (... and most likely, the customer
router sending out unfiltered garbage won't have "send-community&q= uot;
enabled either).

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--001a11409824696c41054b450a11-- From nobody Tue Mar 21 16:54:04 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 610D7129409; Tue, 21 Mar 2017 16:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domino.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 RSBjPzlRqKkM; Tue, 21 Mar 2017 16:36:46 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0130.outbound.protection.outlook.com [104.47.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF2129496; Tue, 21 Mar 2017 16:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domino.onmicrosoft.com; s=selector1-domino-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZf1ujktFS/b52i+UMplQhDgJTkeScooLEH3ctIlZlI=; b=T8l0RW3yRd0VEhqlxuBcjo8NAKUC9pqwmPqcDVO0cOPSlEVdsC/LMWsAHeyXs2P8KBDT73KUslDt/19y3wL1lFIeQKSUlCE9jh4DcIGRGEuKX/nP8dhchwXH05Cz57iGd7wknJTyzy5eYippOJ9Au1gE67qUG3UDIAQWNeYGiS0= Received: from AM4PR03MB1425.eurprd03.prod.outlook.com (10.164.77.155) by AM4PR03MB1427.eurprd03.prod.outlook.com (10.164.77.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 23:36:40 +0000 Received: from AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) by AM4PR03MB1425.eurprd03.prod.outlook.com ([10.164.77.155]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 23:36:40 +0000 From: "Neil J. McRae" To: "Sriram, Kotikalapudi (Fed)" CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Thread-Topic: [Idr] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wAMKpth Date: Tue, 21 Mar 2017 23:36:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=domino.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [107.77.224.155] x-microsoft-exchange-diagnostics: 1; AM4PR03MB1427; 7:tyTnIuVIwh5JEFjo2h+aFF46ANIfZr8wkDh54mlgbmQzX83VfBID0oPU6MXT50MY5CDxN03uB1HWVd9dIr/BvLQwRCPi6zJvm/Ph9L2qR5gxZTqlOXG7JpsCiZBvG/CDEwTwK9aI0kNCFLyvL3o/moi3rA4E4F4jHwQ0G/66y4LPL+q7BFS+J5eLvct3yn67cE8QaJzosn8HFnku86oTzHYO1dRfcJarXv4vFlstwRsd/58ectVZnePEHqX7/p+Rcxaf6mh/PgrlDLQkcMwmnkwOcbu7lh4wTAsUJpFfS1w79mBVf01sEiQUt8unpU+IdoIk0dcsJ2r64gjng7LQCA== x-ms-office365-filtering-correlation-id: 07f08d1c-a623-471e-07f0-08d470b3201b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR03MB1427; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(256337837700080); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(2016111802025)(6072148)(6043046); SRVR:AM4PR03MB1427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1427; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(24454002)(966004)(2906002)(99286003)(5660300001)(8676002)(82746002)(83716003)(50986999)(53936002)(102836003)(122556002)(25786009)(2900100001)(54906002)(6116002)(229853002)(6512007)(86362001)(38730400002)(6246003)(6306002)(66066001)(3846002)(81166006)(110136004)(4326008)(77096006)(6436002)(6916009)(6506006)(3660700001)(189998001)(7736002)(33656002)(54356999)(3280700002)(2950100002)(76176999)(36756003)(305945005)(53546009)(6486002)(8936002)(8656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1427; H:AM4PR03MB1425.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 23:36:40.3569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1427 Archived-At: X-Mailman-Approved-At: Tue, 21 Mar 2017 16:54:03 -0700 Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 23:36:49 -0000 It seems a reasonable approach as long as it's kept as simple as described = here. Regards, Neil. > On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) wrote: >=20 > Inviting comments especially from GROW WG folk (network operators).=20 > Please look at this and address the question posed at the end. Thank you. >=20 > The most common form of route leak occurs when multi-homed=20 > customer AS-C receives a route from its transit provider AS-A > and leaks it to another transit provider AS-B. =20 > [RFC 7908 https://tools.ietf.org/html/rfc7908 ] >=20 > Customer AS-C is often the single point of failure. > AS-A and AS-B may be doing intra-AS community tagging etc.=20 > perfectly well to prevent route leaks, but AS-C does not and ends up leak= ing. > The leaked route propagates via AS-B to the rest of Internet=20 > due to prefer customer route policy. > (Example: Google/Hathway/Airtel leak - > https://bgpmon.net/what-caused-the-google-service-interruption/ =20 > see many more examples in RFC 7908 ) >=20 > A solution component for this has long been discussed in=20 > SIDR/GROW/IDR and well documented in IDR (see Section 4)=20 > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigat= ion-06 ).=20 > The solution involves AS-A setting a field (in an optional transitive att= ribute) > in BGP update to indicate that=20 > (1) it is sending the route to a customer AS (or lateral peer), and=20 > (2) the route SHOULD be considered a leak if subsequently received > from a customer or a lateral peer. > This is one component of the overall solution. > It has been presented and discussed and I believe accepted > in SIDR/IDR/GROW over the last few years (at least since 2014). >=20 > Question:=20 >> From an operator point of view, > are you willing to place a piece of relationship info (as stated above) > in the BGP update for the significant gain of a route leak solution > that works well to detect/stop route leaks that do happen, > and prevents single point of failures in incremental/partial > deployment scenarios? >=20 > Sriram=20 >=20 > P.S. There is already immense BGP-derived public data out there on AS pee= ring relations: >=20 > http://as-rank.caida.org/?mode0=3Das-info&mode1=3Das-table&as=3D3356&data= -selected-id=3D39=20 >=20 > http://bgp.he.net/AS7018#_graph4 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Mar 21 19:06:32 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276B1129422 for ; Tue, 21 Mar 2017 19:06:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 JqDP5kM3gE0B for ; Tue, 21 Mar 2017 19:06:28 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9A0126BF7 for ; Tue, 21 Mar 2017 19:06:27 -0700 (PDT) X-TM-DID: 9b50029a547c1665d896c12ada7d969c Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Declan Ma In-Reply-To: Date: Wed, 22 Mar 2017 10:01:56 +0800 Cc: "Jakob Heitz (jheitz)" , "sidrops@ietf.org" , Job Snijders Content-Transfer-Encoding: quoted-printable Message-Id: <22F74981-4FF1-43E6-A2A6-BE54226EAB46@zdns.cn> References: <20170321135423.tye6fyixctuyzzay@Vurt.local> <20170321155018.ufekfatlgrelgih5@Vurt.local> <44BEFF34-13C2-4660-8439-B46F86E935F2@zdns.cn> <15c6acae82454db0861f4dddf998669a@XCH-ALN-014.cisco.com> To: "John G. Scudder" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 02:06:31 -0000 John, > =D4=DA 2017=C4=EA3=D4=C222=C8=D5=A3=AC02:26=A3=ACJohn G. Scudder = =D0=B4=B5=C0=A3=BA >=20 > To add to this, there's a fairly obvious use case for having two = extant ROAs, one for AS 0 and one for another ASN -- make-before-break. = I'm not sure why you'd persistently have both of them, but it seems = harmless. Or at least "mostly harmless" to quote D. Adams. >=20 Agreed. =A1=B0Make-before-break=A1=B1 is making sense here :-) > As for 7606 itself, I think nothing needs to be changed. The text = related to ROAs is only there to provide motivation -- the only = normative language in the RFC is in section 2, and it doesn't talk about = ROAs or route validation. I just reread the section and it seems clear = to me. In short: don't put AS 0 on the wire in a BGP message. The = conversation we=A1=AFre now having is evidence no good deed goes = unpunished -- if the motivating text had been omitted and only section 2 = published, we'd be good I guess. >=20 > The 6483 section 4 language trips over itself a bit -- if it were = still in draft I'd suggest removing the "by convention" language since = it's nonsense. But it=A1=AFs harmless nonsense (or at least "mostly = harmless") since in the very next clause it says "this is not a strict = requirement". >=20 > Doesn=A1=AFt seem like there's a problem in need of fixing. Right. It also seems to me there is no need of fixing.=20 I comprehended =A1=B0by convention=A1=B1 as a sort of suggestion, while = =A1=B0not a strict requirement=A1=B1 do leaves it to operator to do at = its discretion.=20 Huh, one is free to have multiple ROAs existence with ROA 0 included. = Yet I believe the very implication is quite conspicuous.=20 Declan (Di) >=20 > --John >=20 >> On Mar 21, 2017, at 1:56 PM, Jakob Heitz (jheitz) = wrote: >>=20 >> RFC 7607 does use the word "only": >>=20 >> This allows a resource holder to signal >> that a prefix (and the more specifics) should not be routed by >> publishing a ROA listing AS 0 as the only origin. >>=20 >>=20 >> https://tools.ietf.org/html/rfc6483 >>=20 >> In an environment of a collection of valid ROAs, a route's validity >> state is considered to be "valid" if any ROA provides a "valid" >> outcome. It's validity state is considered to be "invalid" if one >> (or more) ROAs provide an "invalid" outcome and no ROAs provide a >> "valid" outcome. >>=20 >> The ROA for AS 0 provides an "invalid" outcome. >> However, the other ROA provides a "valid" outcome. >> Therefore, the final outcome is "valid". >>=20 >> Thanks, >> Jakob. >>=20 >>=20 >>> -----Original Message----- >>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Declan = Ma >>> Sent: Tuesday, March 21, 2017 9:00 AM >>> To: Job Snijders >>> Cc: sidrops@ietf.org >>> Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same = resource >>>=20 >>> Job, >>>=20 >>>> =D4=DA 2017=C4=EA3=D4=C221=C8=D5=A3=AC23:50=A3=ACJob Snijders = =D0=B4=B5=C0=A3=BA >>>>=20 >>>> Hi Declan, >>>>=20 >>>> On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote: >>>>> [RFC6483] states =A1=B0A ROA with a subject of AS 0 (AS 0 ROA) is = an >>>>> attestation by the holder of a prefix that the prefix described in = the >>>>> ROA, and any more specific prefix, should not be used in a routing >>>>> context.=A1=B1 >>>>>=20 >>>>> I believe this issue bears relevance with how RP software responds = to >>>>> multiple ROAs existence with ROA 0 included. >>>>>=20 >>>>> As for the example you provide, if both ROAs have been validated >>>>> successfully, it is up to RPs to generate output to BGP speakers. >>>>>=20 >>>>> Even a ROA with AS 0 doesn=A1=AFt preclude other valid ROAs, we = should not >>>>> encourage this operation. >>>>=20 >>>> How and why would you discourage this, if it is a valid mode of >>>> operation? Clarity is king. There may be legitimate use cases for = doing >>>> this. >>>>=20 >>>=20 >>> There MAY be legitimate use cases for doing this. >>>=20 >>> These cases should be justified before the WG discuss how to update = RFC 7607. >>>=20 >>> I am open to this operation, hoping to see more detailed context in = which you said the owner of the ROAs was >>> intentional to do that. >>>=20 >>> Declan (Di) >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Mar 22 08:07:11 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 592B1129A58 for ; Wed, 22 Mar 2017 07:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 Gy5ObqIJ3rHF for ; Wed, 22 Mar 2017 07:33:17 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 780871298AA for ; Wed, 22 Mar 2017 07:33:05 -0700 (PDT) X-Original-To: sidrops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9E795619FB for ; Wed, 22 Mar 2017 15:33:03 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 231F361637; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 14C5F3435E; Wed, 22 Mar 2017 15:33:03 +0100 (CET) Date: Wed, 22 Mar 2017 15:33:03 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JjQGvUpjKaxqoY/q" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:33:20 -0000 --JjQGvUpjKaxqoY/q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > Pre-emptive top-post in case anyone mistakes the technique proposed: This > will NOT be implemented via communities. >=20 > The proposal is for a NEW optional transitive attribute. >=20 > If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators. >=20 > Reminder on optional+transitive logic > - If the attribute is not understood/implemented/enabled, the attribute is > passed unmodified. > - If it is understood & implemented & enabled, behavior is subject to the > applicable standards. > - Thus, optional transitives are "opt-in", by definition. It does not really matter if this is a well-known community or a new transitive attribute. If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are the ones that are not caring today, I'm still not seeing why they would turn this on tomorrow. So you're adding implementation complexity which will not help anything. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --JjQGvUpjKaxqoY/q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljSix4ACgkQ31bAZeTO f8ULhxAAiPcBCmIotqsF0CoqP09alfDDaKam+WqBuTX/EFvah+KVFg5THx42yJoK 8HRHwMPghStcjXy8zbOd/jzOCpvq0x+OMCwqdD2WeExQcWum7nk5AyVtL9PqWn/F Ye8rbVuBuq1c2KH8YzmFv7MQu4OKmC/OEtjrYfFN/WhH2DPU/7QEj/HOYM7sxknW 4vAtiuI0aXfRW2rc2z/UrzOdOVaLfXQYVto2vkj0UhtP9KuKq7wvSTeWwXxSrEpX /MQLTpEfaZjXnkY8Z31sI8jTIakfXV/HUS9k0rG0m6Qp+snnk34jJYcWMvVZS+hn 5Fgj2xfQfUvzYEuqxntTBz87PrJwtZa9YA9DHSMvnp3sulHDQKtKBy90SsuwpKNg cdKZc1MBeQl2H1NOTJod2T5e4GHnbxmUnh6bJV3s9LN1raP8L3xdUN2gALsEglwE /zu6X3Xu2RzwPJF5s+MljPMhoZqlWMYzCxLmuHJytN/Lz8VcsIEiR+JtKrk3HPWZ M8yXcaQgR+YL682ySa4pkxAm3chtpatJanQZkoCIaMBQSPxhPMgdlyJXP3fZDEVl tuguuCI+AsmYH120mtXkAHTrYuMsz02RwbmErQA3PqHKoyy3UQPl6bV90c9tmd/N 40PBsbnxrmxSHWzZKvMNFjQ4cuo6SciRF0aq9e1pR0GvomGfr+I= =mefv -----END PGP SIGNATURE----- --JjQGvUpjKaxqoY/q-- From nobody Wed Mar 22 15:10:50 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 760731293DA; Wed, 22 Mar 2017 15:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymIOPcdC6GSO; Wed, 22 Mar 2017 15:10:47 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EFD1292D3; Wed, 22 Mar 2017 15:10:46 -0700 (PDT) X-Envelope-To: grow@ietf.org Received: from cupcake.local ([194.88.241.232]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2MMAhMt069578 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2017 22:10:44 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.232] claimed to be cupcake.local Message-ID: <58D2F662.5020504@foobar.org> Date: Thu, 23 Mar 2017 00:10:42 +0200 From: Nick Hilliard User-Agent: Postbox 5.0.11 (Macintosh/20170302) MIME-Version: 1.0 To: Gert Doering CC: "idr@ietf.org" , "sidrops@ietf.org" , "grow@ietf.org" References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> In-Reply-To: <20170322143302.GG2367@Space.Net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] [GROW] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:10:48 -0000 Gert Doering wrote: > It does not really matter if this is a well-known community or a new > transitive attribute. actually it does. send-community is disabled by default on most ebgp stacks. Transmission of other transitive attributes is enabled by default. Nick From nobody Wed Mar 22 15:13:16 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 4C603127342; Wed, 22 Mar 2017 15:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xCZ06se0aQXb; Wed, 22 Mar 2017 15:13:04 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 DBC7A127735; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 190so31004151itm.0; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=V9zI3/OXt0h8dzmKaggNrxMdCHAD5XiTNcrf0hx9YtqjiEKcHuJbhN3RMvPOAKd8tp y5R3DvFn6RoX3CD999aix5r8p3LuvwN+emRjcDxM5HuVJOmGCQitwQ4fibgoec+EIQni 6QzkeXENXtPK/AYBiREOM3NOooSkm33b5CyoGhRxIK0q9zviYKAB4JU5RKmPCbotPEKZ +GaIIZs4eDIk8SamDrvo9TQy/YCrKujkVl8Oi1RVQhmPfFE6J8nzJ/EBhQLjXNI4FcJ3 U3bJLhOWAaPq2pK95CVdDMEhH5qiIHePlfTronraFt6wg+eHvHkdXCGH3JlwYkc7hcNc DKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oUHKLFxuZRky4t5r6WW0J1XCW+fLpRqc3d2eE1QmR/Y=; b=XUCiWtjZdPrtlbJldMMPmbjxMxJES81XKKfFpAthYw/JyOhdtin/z5kQlPVurv8hKg 4F3Yu8kgAgvkroCSDP9aL4hiAEOvPas8nzqUUFMFutPJUjC9XDSTI1M3XE5zcAvOAhsi wJ//JmRuK9W/aGIYc1TtKFLINlQItjHlMsgXcjMN5M7Ioivovov9ieuLDW0KXuXsNLn5 9AwD8MFEByoQZpPCa14zTYsdtXrvApIsG4J/PFUDOXmr/4xWirk0YgIefh9qQmwlmQiF MFfxeX015Yvi34AdvYibAf7zhEgTYT8LGCXKyWXHzU+yZStoX+jTsR3O39ei7XEnFSy3 IEeg== X-Gm-Message-State: AFeK/H3HxY2xPVkDHS/tX2hB4ZTAPfdnnQrQBramODZ/+x+t26wT6X82SloauUqVpUWTD16Yd7OmVWMtK8M6BQ== X-Received: by 10.36.4.67 with SMTP id 64mr10149401itb.19.1490220783203; Wed, 22 Mar 2017 15:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 15:13:02 -0700 (PDT) In-Reply-To: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> From: Brian Dickson Date: Wed, 22 Mar 2017 15:13:02 -0700 Message-ID: To: Gert Doering Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1140ad4e6ba0a9054b59103c Archived-At: Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:13:06 -0000 --001a1140ad4e6ba0a9054b59103c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering wrote: > Hi, > > On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote: > > Pre-emptive top-post in case anyone mistakes the technique proposed: This > > will NOT be implemented via communities. > > > > The proposal is for a NEW optional transitive attribute. > > > > If any operators can answer the original question, this will be very > > helpful. Thank you in advance to any and all operators. > > > > Reminder on optional+transitive logic > > - If the attribute is not understood/implemented/enabled, the attribute > is > > passed unmodified. > > - If it is understood & implemented & enabled, behavior is subject to the > > applicable standards. > > - Thus, optional transitives are "opt-in", by definition. > > It does not really matter if this is a well-known community or a new > transitive attribute. > > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. > > There is direct benefit to partial (even very sparse) deployment. The deployment is self-serving; whoever turns this on protects themselves and their downstream customers. This becomes a differentiator with direct benefits, and creates market pressure to deploy. Here's the simplest example showing how few parties need to implement this, for benefit. (Key: O = originator, T = top-tier ISP, L = leaker; number N disambiguates; subscript y/n means "implements") On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2 - leaks in both directions pass without any tagging/blocking; - Path via L is preferred, because T1 and T2 prefer customer routes (which include L) - All traffic between Tn1 and Tn2 is affected (assuming L leaks the entire routing table) - In addition to latency caused by extra hops, there will likely be queueing-based latency, and significant loss On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) - Ty4 - (arbitrary path) - On2 - leaks in both directions are blocked, at Ty3 and Ty4 respectively - The leak is blocked despite neither On1 nor On2 activating the protocol - The actual path selected will be something else, possibly/probably: - On1 - ... - Ty3 - Ty4 - ... - On2 - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those routes are excluded - Assuming Ty3 and Ty4 peer, there will not be a better path respectively, modulo other peers with shorter AS paths to On1 or On2. If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths, the following will be the case: - In all likelihood, there will be massive latency and packet loss, on the first path via L - The other path will not have that latency/loss - On1 and On2 will both be better served by - preferentially routing to Ty3 and Ty4 (apply better local-pref inbound to Ty3 and Ty4) - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2) - On1 and On2 obtain benefit by being able route around L (the leaker) - Ty3 and Ty4 get benefit by having more traffic to/from their customers - Potential customers may choose Ty3 and Ty4 for those reasons - Networks who deploy on their own infrastructure gain similar benefits, even if they All of the above presumes intermediate ASNs that do not implement (all of the "arbitrary path" bits), yet there is benefit to all the named parties. The same would be true for ASNs at Tier-2 who peer at various exchange points, who implement; they would possibly position themselves better than Tier-1's until any Tier-1's implement. NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT see the benefit, unless they also implement, so there is further reason to implement for Tier-N, N>1. FYI - I worked as a senior network engineer, where inbound peering ACLs of other Tier-1 networks, allowed us to escape the AS7001 incident unscathed. This scales a lot better, since there is no need for ACL maintenance. Applying to customers/peers should be easy, assuming the ISP knows which BGP neighbors are customers... Brian > So you're adding implementation complexity which will not help anything. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > --001a1140ad4e6ba0a9054b59103c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 22, 2017 at 7:33 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Tue, Mar 21, 2017 at 03:19:42PM -0700, Brian Dickson wrote:
> Pre-emptive top-post in case anyone mistakes the technique proposed: T= his
> will NOT be implemented via communities.
>
> The proposal is for a NEW optional transitive attribute.
>
> If any operators can answer the original question, this will be very > helpful. Thank you in advance to any and all operators.
>
> Reminder on optional+transitive logic
> - If the attribute is not understood/implemented/enabled, the att= ribute is
> passed unmodified.
> - If it is understood & implemented & enabled, behavior is sub= ject to the
> applicable standards.
> - Thus, optional transitives are "opt-in", by definition.
It does not really matter if this is a well-known community or a new=
transitive attribute.

If ISPs do not turn this *on* on their customer connections, it will not do anything - and given that those ISPs that *need* to turn this on are
the ones that are not caring today, I'm still not seeing why they would=
turn this on tomorrow.


There is direct benefit to partial (ev= en very sparse) deployment.

The deployment is self= -serving; whoever turns this on protects themselves and their downstream cu= stomers.

This becomes a differentiator with direct= benefits, and creates market pressure to deploy.

= Here's the simplest example showing how few parties need to implement t= his, for benefit.
(Key: O =3D originator, T =3D top-tier ISP, L = =3D leaker; number N disambiguates; subscript y/n means "implements&qu= ot;)

On1 - (arbitrary path) - Tn1 - (arbitrary pat= h) - L - (arbitrary path) - Tn2 - (arbitrary path) - On2
  • = leaks in both directions pass without any tagging/blocking;=C2=A0
  • P= ath via L is preferred, because T1 and T2 prefer customer routes (which inc= lude L)
  • All traffic between Tn1 and Tn2 is affected (assuming L= leaks the entire routing table)
  • In addition to latency caused by e= xtra hops, there will likely be queueing-based latency, and significant los= s
On1 - (arbitrary path) - Ty3 - (arbitrary path) - L -= (arbitrary path) - Ty4 - (arbitrary path) - On2=C2=A0
  • le= aks in both directions are blocked, at Ty3 and Ty4 respectively
  • The leak is blocked despite neither On1 nor On2 activating the protoco= l
  • The actual path selected will be something else, possibly/pr= obably:
    • On1 - ... - Ty3 - Ty4 - ... - On2
    • Since Ty3 and= Ty4 both block the L routes (leaked) inbound, those routes are excluded
    • Assuming Ty3 and Ty4 peer, there will not be a better path respective= ly, modulo other peers with shorter AS paths to On1 or On2.
    <= div>If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid pat= hs, the following will be the case:
    • In all likelihood, th= ere will be massive latency and packet loss, on the first path via L
      • The other path will not have that latency/loss
    • On1 and On2 will b= oth be better served by=C2=A0
      • preferentially routing to Ty3 and= Ty4 (apply better =C2=A0local-pref inbound to Ty3 and Ty4)
      • prefere= ntially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
    • On1= and On2 obtain benefit by being able route around L (the leaker)
      • <= ul>
    • Ty3 and Ty4 get benefit by having more traffic to/from their custome= rs
    • Potential customers may choose Ty3 and Ty4 for those reasons
    • Networks who deploy on their own infrastructure gain similar benefits,= even if they=C2=A0
    All of the above presumes inte= rmediate ASNs that do not implement (all of the "arbitrary path" = bits), yet there is benefit to all the named parties.

    <= /div>
    The same would be true for ASNs at Tier-2 who peer at various exc= hange points, who implement; they would possibly position themselves better= than Tier-1's until any Tier-1's implement.

    NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT= see the benefit, unless they also implement, so there is further reason to= implement for Tier-N, N>1.

    FYI - I worked as a= senior network engineer, where inbound peering ACLs of other Tier-1 networ= ks, allowed us to escape the AS7001 incident unscathed.=C2=A0
    Thi= s scales a lot better, since there is no need for ACL maintenance.
    Applying to customers/peers should be easy, assuming the ISP knows which = BGP neighbors are customers...

    Brian
    =C2=A0
    So you're adding implementation complexity which will not help anything= .

    Gert Doering
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
    --
    have you enabled IPv6 on something today...?

    SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
    D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279

    --001a1140ad4e6ba0a9054b59103c-- From nobody Wed Mar 22 16:39:44 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 1B523127201 for ; Wed, 22 Mar 2017 16:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 7i6XcjF4jJn3 for ; Wed, 22 Mar 2017 16:39:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A6B64124B0A for ; Wed, 22 Mar 2017 16:39:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqpqu-0000Fu-Sl; Wed, 22 Mar 2017 23:39:40 +0000 Date: Wed, 22 Mar 2017 18:39:40 -0500 Message-ID: From: Randy Bush To: Job Snijders Cc: sidrops@ietf.org In-Reply-To: <20170321135423.tye6fyixctuyzzay@Vurt.local> References: <20170321135423.tye6fyixctuyzzay@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:39:44 -0000 > This made me question my assumptions around AS 0: does a ROA with AS 0 > preclude other valid ROAs? no. give 42 roas (incl some with as==0), if one validates the origin as, the announcement is valid. of course, at 43 roas, all bets are off :) randy From nobody Wed Mar 22 16:50:55 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 A78F1128D19; Wed, 22 Mar 2017 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Fi5vWmEX-vps; Wed, 22 Mar 2017 16:50:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EE5E7127201; Wed, 22 Mar 2017 16:50:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqq1Q-0000LC-T1; Wed, 22 Mar 2017 23:50:33 +0000 Date: Wed, 22 Mar 2017 18:50:32 -0500 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" Cc: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:50:36 -0000 > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. randy From nobody Wed Mar 22 18:09:53 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013341292F5; Wed, 22 Mar 2017 18:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCO3WtYsAR8q; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 1C385128954; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id w124so32095238itb.1; Wed, 22 Mar 2017 18:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=imeni+XKvXGsUU5vlf/8RXUaCta7nnXAzPjdTM+BkAdRHUvZFjFOLr5XyWz8/aCRAy gNYMmxthjEOCdagRbhrmHzCedInHQaxSCv6N18LQnuJmPo/G7aOty5TEkuW2QUbHYwLI 8vVVcnnOtH2yaLSTkh2WtzsM4R5dB91ZERfn5Mu3axSzFvsSQ77SfIqLzxlMVxx2g7xq /jwgkELna0y0lIisGKeV13loiLr8IJ/uSuVXMY0KSQHIHx14ekjxv6sGQ7PYxcHwrR8f GZhGkU/OZLfVeaNz9dAGXe2O7m3YzXibI4vB35oXszn35ca+wEWfAk9mNefTnWBkXmsR elMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qtGpYjit16EONu0EM0Wx5kW3QiIcY7QDfJOGkqQtaJI=; b=MvBj4vWAv7Aivhv/v9wXKoI2LNi7unIY4COjM+h+EeYoCPm9UtwIUXsGPpSZyg0W6z 7d4HV0k8t+CzHLjx5sRR00QFkKzSbpfOD113p2KFW6MaPFrAWDTKj4Hqgn5er4Mc+BQW WXbQOfz1zEy4qZXEwfXNQqiNqWsLgjprHy46I+OadjofjGpqOXqBn701Ew5E6aAjmjGN 94H51/ltSIRw0Kmk5Nb140YaJcVNQGC90NXzTsapRYn48vdU3gaCk/UHS97i0QLATd26 Tl82ysbmn2eoUmA2EQA1qp2oSpmtp+oCfL/lIsIjA+iN220WjXpBDsQIAYjBkvWrfWtA QxQg== X-Gm-Message-State: AFeK/H1YBDj2CfyijOurR5zm5LQSB2deOcXkvCvzEAYkxssc3v9A6vyp97+8NAUSTAhS4VFyUX7nC+0x0ySUog== X-Received: by 10.36.102.195 with SMTP id k186mr338487itc.75.1490231375484; Wed, 22 Mar 2017 18:09:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.121.77 with HTTP; Wed, 22 Mar 2017 18:09:34 -0700 (PDT) In-Reply-To: References: From: Brian Dickson Date: Wed, 22 Mar 2017 18:09:34 -0700 Message-ID: To: Randy Bush Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Content-Type: multipart/alternative; boundary=001a1147f558c4efba054b5b87e3 Archived-At: Subject: Re: [Sidrops] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 01:09:38 -0000 --001a1147f558c4efba054b5b87e3 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > > SIDR/GROW/IDR and well documented in IDR (see Section 4) > > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak- > detection-mitigation-06 ). > > The solution involves AS-A setting a field (in an optional transitive > > attribute) > > glad you liked the attribute approach well enough to plagarize it from > our draft. now you just need to change from misconfigurable statements > of relationships to plagarize the bgp open part of our draft and your > golden. > > Randy, With all due respect, your draft fails to acknowledge the earlier work by me (from 2012), outside of the recent drafts of which I am a co-author. Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns So, perhaps it would be best to avoid claims of plagiarizing, when (a) there is clear evidence that the source of the material predates your work, and (b) when your work does not credit the original work by me. Pot calling the kettle black, throwing stones in glass houses, and all that. You might want to also read those (expired) I-Ds, to get clarity on preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the disclosure of customer relationships -- something for which you have expressed a strong desire. FWIW, I will be working with my co-authors on the relationship-disclosure detail. Maybe we can schedule some white-board time in Chicago. Brian P.S. It is "you're golden". --001a1147f558c4efba054b5b87e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On W= ed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> wrote:
    = > SIDR/GROW/IDR and well documented in IDR (see Section 4)
    > ( https://tools.ie= tf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06= =C2=A0 ).
    > The solution involves AS-A setting a field (in an optional transitive<= br> > attribute)

    glad you liked the attribute approach well enough to plagarize it fr= om
    our draft.=C2=A0 now you just need to change from misconfigurable statement= s
    of relationships to plagarize the bgp open part of our draft and your
    golden.


    Randy,

    =
    With all due respect, your draft fails to acknowledge the earlier work= by me (from 2012), outside of the recent drafts of which I am a co-author.=

    Specifically:
    draft-dickson-sidr-route-= leak-def (which became the basis for RFC 7908)
    draft-dickson-= sidr-route-leak-reqts
    draft-dickson-sidr-route-leak-solns
    =

    So, perhaps it would be best to avoid claims of p= lagiarizing, when (a) there is clear evidence that the source of the materi= al predates your work, and (b) when your work does not credit the original = work by me.

    Pot calling the kettle black, throwing= stones in glass houses, and all that.

    You might w= ant to also read those (expired) I-Ds, to get clarity on preserving leak pr= evention across "special" peering sessions
    They also co= ver the ability to prevent leaks, without requiring the disclosure of custo= mer relationships -- something for which you have expressed a strong desire= .

    FWIW, I will be working with my co-authors on th= e relationship-disclosure detail.

    Maybe we can sch= edule some white-board time in Chicago.

    Brian

    P.S.=C2=A0 It is "you're golden".
    <= /div>
    --001a1147f558c4efba054b5b87e3-- From nobody Wed Mar 22 20:21:48 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 55242129B28; Wed, 22 Mar 2017 20:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 sp5gXmSgkcmj; Wed, 22 Mar 2017 20:21:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F2AAC1200A0; Wed, 22 Mar 2017 20:21:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cqtJW-00022B-T9; Thu, 23 Mar 2017 03:21:27 +0000 Date: Wed, 22 Mar 2017 22:21:26 -0500 Message-ID: From: Randy Bush To: Brian Dickson Cc: "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:21:32 -0000 > With all due respect, your draft fails to acknowledge the earlier work by > me (from 2012), outside of the recent drafts of which I am a > co-author. apologies. this should be corrected, > So, perhaps it would be best to avoid claims of plagiarizing, when (a) > there is clear evidence that the source of the material predates your work, > and (b) when your work does not credit the original work by me. word for word From nobody Wed Mar 22 20:34:30 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 434EA129438; Wed, 22 Mar 2017 20:34:11 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QLtG7LG5bahH; Wed, 22 Mar 2017 20:34:09 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F9B12942F; Wed, 22 Mar 2017 20:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HxYKCR7u8SHJhFeVh3X66vemla6rJNNjhuaPG4YnIXU=; b=v1/qajZTMRQTqSut/5/9HkDtBX3yl+5Y5wo2LgQ+nNEt/pS2hfDFcyqJKPsxNzpV4JINLRQDqB31vslvQMn/I+FB4mKwKYfeZxkLNX7fdAvjPIS+SFWEdBRGdPZjPnP/yIuLgCIH1glxps4B3NcrBo7iUy5YwP9DgD39cNbPcyw= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 03:34:07 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0977.019; Thu, 23 Mar 2017 03:34:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Randy Bush CC: "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" , "idr-chairs@ietf.org" Thread-Topic: [Sidrops] operator inputs -- route leak solution Thread-Index: AdKia1LxrjWKYnevQ5+4FG+AD/ZO4wA+8SkAAAcwRBI= Date: Thu, 23 Mar 2017 03:34:07 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.1] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:Xccu20Y8r07osmhTSUZ30bPMWEDEhjFtGoI4CsC4/zxqB2q6l4lphtSdim1gAjaW5knchfQZeJeS2JW+Y5giwFgC4dET0h/VFKJNmoUQlhD85yTshL9m0YymTVXH4KNjQ1e2qWMkjXHVOtHvz6nyrIoMnJDYhXVvShh4Z1shpBN/3JeHpBcBj7sGcSaC7/OCE0nslHQZ+nNVk2xSJAFWVjpQCI+Bzgqts720SWTFuiGyU0paWT4ExMNtF2xb+R5AZI9ULGj5AjRIjLKN3T+R9AK6xPxj2Vtg78LN6UsHoEcoBnkoJK6WMAYuCY0p6E+eg66ULLRer1qelH813U8Ipw== x-ms-office365-filtering-correlation-id: c3754c7c-e977-4ff1-21c1-08d4719d7656 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39840400002)(305945005)(3846002)(7736002)(54356999)(50986999)(76176999)(4326008)(102836003)(229853002)(122556002)(6246003)(6116002)(38730400002)(77096006)(6506006)(2900100001)(3660700001)(99286003)(110136004)(66066001)(86362001)(3280700002)(53936002)(189998001)(8676002)(2950100002)(2906002)(6916009)(9686003)(6306002)(74316002)(54906002)(6436002)(81166006)(7696004)(55016002)(33656002)(25786009)(8936002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 03:34:07.3891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: Re: [Sidrops] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:34:11 -0000 >> SIDR/GROW/IDR and well documented in IDR (see Section 4) >> ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitiga= tion-06 ). >> The solution involves AS-A setting a field (in an optional transitive >> attribute) >glad you liked the attribute approach well enough to plagarize it from >our draft. now you just need to change from misconfigurable statements >of relationships to plagarize the bgp open part of our draft and your >golden. Randy, To the response that Brian already offered,=20 I would like to add the following with due respect. Our version-00 working group draft was published July 22, 2015, and it stat= ed: " The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] updates in an optional transitive path attribute. "=20 https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 00 =20 =20 Your version-00 individual draft was published in March 2016.=20 Sriram =20 =20 From nobody Thu Mar 23 00:59:11 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 EDD341317BF for ; Thu, 23 Mar 2017 00:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIhwnNO6E8zk for ; Thu, 23 Mar 2017 00:59:09 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 C578A13145D for ; Thu, 23 Mar 2017 00:59:08 -0700 (PDT) X-Original-To: sidrops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 135BD61A13 for ; Thu, 23 Mar 2017 08:50:09 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9D47D61565; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 8EA3B6BACB; Thu, 23 Mar 2017 08:50:08 +0100 (CET) Date: Thu, 23 Mar 2017 08:50:08 +0100 From: Gert Doering To: Brian Dickson Cc: Gert Doering , "Sriram, Kotikalapudi (Fed)" , "grow@ietf.org" , "idr@ietf.org" , "sidrops@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidr wg list (sidr@ietf.org)" Message-ID: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mO1Hs8HP9h3I4vdI" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:59:10 -0000 --mO1Hs8HP9h3I4vdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 22, 2017 at 03:13:02PM -0700, Brian Dickson wrote: > There is direct benefit to partial (even very sparse) deployment. >=20 > The deployment is self-serving; whoever turns this on protects themselves > and their downstream customers. Those that are interested in doing so already do customer route filtering today. For those that are not interested, where's the incentive in starting to do so if you have to do a software upgrade first (*and* the other upstreams of your customers need to send this attribute)? > This becomes a differentiator with direct benefits, and creates market > pressure to deploy. A-ha. Right, exactly like "filter customer routes" is working today to give "market pressure". I always had the impression that *market* pressure is totally in favour of "accept everything from the customer, send down the pipe whatever you can, and then bill the customer for the traffic"... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --mO1Hs8HP9h3I4vdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAljTfi8ACgkQ31bAZeTO f8W7hw//bAlzlXD1a6H3ecoJAHNUCg3o/AlWjKcwx4Uh8ztyMcRUoGvnLnQKozCU nnKc+9Eglx14VKwsLhikTkj4pd9cZd/xe+uY5HtQOo1DQR2jWQaA/HX28Vqg/PMS yNIpz0ePpFFNvjIwZjjFojuZSX6WNl4ulYauJOHwOJicnFC6Vqy71RbjasWgyZMO PQ6QP9FYOkOj9oAmG9rJQGY0rzGUk0QIA+n4VvhqWnqeGQlThyzYnVlDIvkfbQMd BpPJcCq7ftzY5uQHXDPQReX+VBTfbIKgt9ngHTW6DUIHCXOyBm0GJ541r+y2nail 4qyaTbPrEdFtMGttU7IsGseXTVAQgf454ts0N4M+AmuhkErO8J8otSHM15DrA7yB BVYk+c3zlnxhk15Q4oThG2kW5iYkYlBLDc4AaRILjK0cl6MKf33IAwU8wodsNwwS J0BWUucy+Flbu9pV6PT1u6122dLxSNBmPstZr3k+NGKLYqMBPtdTUsVSLxqSUhbj PwFWNcts8wTDGaU5vy7BW/spcrElnamsA4DYnNGt5D4Ya/YE2DsTAlGiC73bkakt Qj90NEdpwvE78EVKhMmNEGB6umP9q8D3UEqwVnh684zrVokV+Rw6GI5yQaRyuqnA x+dISBRm9qA/EQZDaSQsLf8rUcQRKa2fZRuxT+Os1ug1mO4uGlU= =yv6G -----END PGP SIGNATURE----- --mO1Hs8HP9h3I4vdI-- From nobody Thu Mar 23 06:00:08 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 EB29F1293F8; Thu, 23 Mar 2017 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9lRRZcKlZu2; Thu, 23 Mar 2017 06:00:03 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F20371296EA; Thu, 23 Mar 2017 06:00:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.114; From: "Susan Hares" To: "'Brian Dickson'" , "'Randy Bush'" Cc: , , , "'sidr wg list'" , References: In-Reply-To: Date: Thu, 23 Mar 2017 08:54:28 -0400 Message-ID: <02fa01d2a3d4$9bff4dc0$d3fde940$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FB_01D2A3B3.14EEBF30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFy2aVjjW9G+WpNY0ppJr8stM1gVQGcf8JwAoeB1GSiQNC3IA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Sidrops] [GROW] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 13:00:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brian, Sriram and Randy:=20 =20 =20 Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR. The IDR Chairs noted when the = draft-ietf-idr-route-leak-detection mitigation was adopted that there = was overlap between you two documents. We also noted interests in both = technical approaches. We asked to you provide a combined document that = the chairs could present to the IDR WG. This IETF is a wonderful time = to work on this project. Chicago has many fine establishments in which = to discuss this combined document. =20 =20 I suggest we focused on the technical issues on the IDR mail lists. For = discussions of IDR on the grow list, I suggest that we listen to the = valuable input from the operators on what their needs and ask clarifying = questions. =20 =20 =20 Thank you,=20 =20 Sue Hares=20 =20 From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian Dickson Sent: Wednesday, March 22, 2017 9:10 PM To: Randy Bush Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); sidrops@ietf.org Subject: Re: [GROW] [Sidrops] operator inputs -- route leak solution =20 On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush wrote: > SIDR/GROW/IDR and well documented in IDR (see Section 4) > ( = https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigatio= n-06 ). > The solution involves AS-A setting a field (in an optional transitive > attribute) glad you liked the attribute approach well enough to plagarize it from our draft. now you just need to change from misconfigurable statements of relationships to plagarize the bgp open part of our draft and your golden. =20 Randy, =20 With all due respect, your draft fails to acknowledge the earlier work = by me (from 2012), outside of the recent drafts of which I am a = co-author. =20 Specifically: draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908) draft-dickson-sidr-route-leak-reqts draft-dickson-sidr-route-leak-solns =20 So, perhaps it would be best to avoid claims of plagiarizing, when (a) = there is clear evidence that the source of the material predates your = work, and (b) when your work does not credit the original work by me. =20 Pot calling the kettle black, throwing stones in glass houses, and all = that. =20 You might want to also read those (expired) I-Ds, to get clarity on = preserving leak prevention across "special" peering sessions They also cover the ability to prevent leaks, without requiring the = disclosure of customer relationships -- something for which you have = expressed a strong desire. =20 FWIW, I will be working with my co-authors on the = relationship-disclosure detail. =20 Maybe we can schedule some white-board time in Chicago. =20 Brian =20 P.S. It is "you're golden". ------=_NextPart_000_02FB_01D2A3B3.14EEBF30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Brian, Sriram and Randy:

     

    <IDR co-chair hat on>

    Let me suggest we take the rest of this discussion on these IDR two = drafts offline from IDR.=C2=A0 The IDR Chairs noted=C2=A0 when the = draft-ietf-idr-route-leak-detection mitigation was adopted =C2=A0that = there was overlap between you two documents.=C2=A0 We also noted = interests in both technical approaches.=C2=A0 We asked to you provide a = combined document that the chairs could present to the IDR WG.=C2=A0 = This IETF is a wonderful time to work on this project. = =C2=A0=C2=A0Chicago has many fine establishments in which to discuss = this combined document. =C2=A0=C2=A0

     

    I suggest we focused on the technical issues on the IDR mail = lists.=C2=A0 For discussions of IDR on the grow list, I suggest that we = listen to the valuable input from the operators on what their needs and = ask clarifying questions. =C2=A0

    <IDR co-chair hat off>

     

    Thank you,

     

    Sue Hares

     

    From:= = GROW [mailto:grow-bounces@ietf.org] On Behalf Of Brian = Dickson
    Sent: Wednesday, March 22, 2017 9:10 PM
    To: = Randy Bush
    Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org; = grow@ietf.org; sidr wg list (sidr@ietf.org); = sidrops@ietf.org
    Subject: Re: [GROW] [Sidrops] operator inputs = -- route leak solution

     

    On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush <randy@psg.com> = wrote:

    > SIDR/GROW/IDR = and well documented in IDR (see Section 4)
    > ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-d= etection-mitigation-06  ).
    > = The solution involves AS-A setting a field (in an optional = transitive
    > = attribute)

    glad you liked the attribute approach well = enough to plagarize it from
    our draft.  now you just need to = change from misconfigurable statements
    of relationships to plagarize = the bgp open part of our draft and your
    golden.

     

    Randy,

     

    With all due respect, your draft fails to acknowledge = the earlier work by me (from 2012), outside of the recent drafts of = which I am a co-author.

     

    Specifically:

    draft-dickson-sidr-route-leak-def (which became the = basis for RFC 7908)

    draft-dickson-sidr-route-leak-reqts

    draft-dickson-sidr-route-leak-solns

     

    So, perhaps it would be best to avoid claims of = plagiarizing, when (a) there is clear evidence that the source of the = material predates your work, and (b) when your work does not credit the = original work by me.

     

    Pot calling the kettle black, throwing stones in glass = houses, and all that.

     

    You might want to also read those (expired) I-Ds, to = get clarity on preserving leak prevention across "special" = peering sessions

    They also = cover the ability to prevent leaks, without requiring the disclosure of = customer relationships -- something for which you have expressed a = strong desire.

     

    FWIW, I will be working with my co-authors on the = relationship-disclosure detail.

     

    Maybe we can schedule some white-board time in = Chicago.

     

    Brian

     

    P.S.  It is "you're = golden".

    ------=_NextPart_000_02FB_01D2A3B3.14EEBF30-- From nobody Thu Mar 23 08:48:31 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 6BD1C129495; Thu, 23 Mar 2017 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 D9dHF6x3duA6; Thu, 23 Mar 2017 08:48:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2194D129405; Thu, 23 Mar 2017 08:48:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cr4yG-0005uC-7t; Thu, 23 Mar 2017 15:48:16 +0000 Date: Thu, 23 Mar 2017 10:48:15 -0500 Message-ID: From: Randy Bush To: Gert Doering Cc: Interminable Discussion Room , sidrops@ietf.org, GMO Crops In-Reply-To: <20170322143302.GG2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:48:25 -0000 > If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. not quite. if ntt and l3 told fiber@home "on or befofe next jan 1st, have draft-ymbk-idr-bgp-open-policy enabled," (as they do with route: object reg); beyond that, l3, ntt, and fiber@home need to do no more. it's all in the open. the leak does not happen. imiho, the other draft with the transitive eOTR attribute (draft-ymbk-idr-bgp-eotr-policy) is not needed. it is a way to diagnose at a distance, and i prefer to stop at the source. randy From nobody Thu Mar 23 13:17:18 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 87C91131648; Thu, 23 Mar 2017 13:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 AVoGpe_H90Yo; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 81F291315D3; Thu, 23 Mar 2017 13:17:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cr9AO-0007Ar-BF; Thu, 23 Mar 2017 20:17:04 +0000 Date: Thu, 23 Mar 2017 15:17:04 -0500 Message-ID: From: Randy Bush To: Gert Doering Cc: Brian Dickson , "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation.authors@ietf.org" , "sidrops@ietf.org" , "Sriram, Kotikalapudi (Fed)" , "sidr wg list (sidr@ietf.org)" , "grow@ietf.org" In-Reply-To: <20170323075008.GL2367@Space.Net> References: <20170321205513.GA2367@Space.Net> <20170322143302.GG2367@Space.Net> <20170323075008.GL2367@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] [sidr] [Idr] operator inputs -- route leak solution X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:17:10 -0000 >> The deployment is self-serving; whoever turns this on protects themselves >> and their downstream customers. > > Those that are interested in doing so already do customer route filtering > today. if god had meant us to fly in planes, she would not have given us trains. oh wait, americans don't have trains. :) randy From nobody Sat Mar 25 00:17:20 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 CE30E129409 for ; Sat, 25 Mar 2017 00:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t0t16YNWWvG for ; Sat, 25 Mar 2017 00:17:16 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190581293FB for ; Sat, 25 Mar 2017 00:17:15 -0700 (PDT) X-TM-DID: cb7af92e39e4cdb6026a29105c32e5bc From: Declan Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Sat, 25 Mar 2017 16:09:36 +0900 To: sidr wg list , sidrops@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Sidrops] RPSTIR updated X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 07:17:18 -0000 Hi, folks, We RPSTIR team just had the very software updated to support the = algorithm specified by Validation Reconsidered = (draft-ietf-sidr-rpki-validation-reconsidered-07) . Given the SIDR WG has not reach the agreement whether and how new OIDs = should be employed, this release, for the time being, is counting on the = old OIDs. And we will shift into new OIDs accordingly once the IETF has come into = a conclusion about that.=20 Welcome to have a try on this new version of RPSTIR.=20 We would appreciate your feedbacks.=20 https://github.com/bgpsecurity/rpstir/releases Declan(Di) Ma ZDNS From nobody Mon Mar 27 22:26:23 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 4D6D11294A0 for ; Mon, 27 Mar 2017 16:58:56 -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, RP_MATCHES_RCVD=-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 LQl25uGcKwKb for ; Mon, 27 Mar 2017 16:58:54 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AAB127F0E for ; Mon, 27 Mar 2017 16:58:54 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 76A1A3FEA4 for ; Mon, 27 Mar 2017 23:58:53 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (dhcp-860c.meeting.ietf.org [31.133.134.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 0297E304699F for ; Mon, 27 Mar 2017 23:58:51 +0000 (UTC) Date: Mon, 27 Mar 2017 17:58:50 -0600 Message-ID: From: Chris Morrow To: sidrops@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Mon, 27 Mar 2017 22:26:22 -0700 Subject: [Sidrops] We are on a slide hunt... X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:58:56 -0000 Howdy SidrOps Folks: The agenda is: Agenda Bashing - 5m SIDR Status Update - smurphy - 5m BGPSec Router Certificate Rollover - bweis - 15m Decoupling BGPSec and ExtMsgs - sriram - 15m The Use of MaxLength in the RPKI - sgoldbe - 15m Route Leak Detection and Filtering - rbush - 10m Detection/Mitigation of BGP Route Leaks - sriram - 15m RIPE NCC RPKI Validator 3.0 - tbruijnzeels - 10m Fini! There are slides from: sriram (2x slides) bweis smurphy (coming soon to an inbox near me) There are no slides yet from: (or I missed them, totes possible!) sgoldbe tbruijnnbzeels rbush Please send slides soon, prior to noon Tuesday (noon chicago time!)... Or alternately say you have no need of slides (rbush?)..y -chris/keyur From nobody Mon Mar 27 22:31:10 2017 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34657128D44 for ; Mon, 27 Mar 2017 22:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrcdQVBCEU2w for ; Mon, 27 Mar 2017 22:31:07 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1AB4A126D85 for ; Mon, 27 Mar 2017 22:31:07 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id x35so55512004qtc.2 for ; Mon, 27 Mar 2017 22:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mI6MsWSWUWK0hWNfcBLI5TqegjYiWievoNrfHpeIRuc=; b=ToDQsUKt6QtFLfmMCh+zkQIccIYKO0RaGDUJycBsVr6HGSCsxOk5KixF9fp9gVMFm5 tM/pm+tkuhx76H48+VBqI2ZWdCRBzc4gyQdWspvJ3hxy53O1OVM0Z+W7dhVPazA+BvZH AmhhOSjNhV0vmITgKyayHfIQJZcOM4j8AC8bxwDset09qUq2hqMwIqsvDfri0Fo6r3cI nbJLYhXm0kPRMvv8MKlT+VxSCQRrVvJtFwvxuaYU2S44h/xsKlPs0GrsQGRu93pdG/yy 27jTtEstrriGHq26eeBfqUz0dSS9GJuX6El9un1EAuwwSwKdW/p+MV1gL1Fj7gaTmvbL Xv8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mI6MsWSWUWK0hWNfcBLI5TqegjYiWievoNrfHpeIRuc=; b=s0AUqFX8HbKWs9ktS7ofC66FD7oo/C/Fd0YBiqqsoHAFmmbb2bCt9iUOH+sZurImKW 3pAq/X/+eJ7kBY7B6Iw7CDcOMmpBu8bj0VHMDNSSymnm5EB4DiwrcJAd39CYKbe2pLxN teSaCUXekiKnLyCKktFNfhDrxmvCqwka41MlEO7QcQmf0gVpe+s78IYj2ayaTOsq0MuI LXKHiI2iCUMv0dOYpjOSKjbcYELL98RaQUnHmQoTx7lDE9E+cLnhcakdDu12h+YwvdyH 0YA6ryxRaCTheWsMRKuOfqALqXFqMD/8uTF7D63Hxekp2RZ/TqqmAw5ifChQoai9TzTh bHww== X-Gm-Message-State: AFeK/H2vxhh9CWcCkwGVkKbA8nJNIgIFO3m38VoTeyXbw5BDVyjRZt9tbZHx1RuiGmxUsIhbg5U6lzW6j+o+/A== X-Received: by 10.200.45.137 with SMTP id p9mr24707801qta.201.1490679066188; Mon, 27 Mar 2017 22:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.75 with HTTP; Mon, 27 Mar 2017 22:31:05 -0700 (PDT) In-Reply-To: References: From: Christopher Morrow Date: Mon, 27 Mar 2017 23:31:05 -0600 Message-ID: To: Chris Morrow Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary=001a1136fb1836e5c9054bc3c4d3 Archived-At: Subject: Re: [Sidrops] We are on a slide hunt... X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 05:31:09 -0000 --001a1136fb1836e5c9054bc3c4d3 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 27, 2017 at 5:58 PM, Chris Morrow wrote: > Howdy SidrOps Folks: > > The agenda is: > > Agenda Bashing - 5m > SIDR Status Update - smurphy - 5m > BGPSec Router Certificate Rollover - bweis - 15m > Decoupling BGPSec and ExtMsgs - sriram - 15m > The Use of MaxLength in the RPKI - sgoldbe - 15m > Route Leak Detection and Filtering - rbush - 10m > Detection/Mitigation of BGP Route Leaks - sriram - 15m > RIPE NCC RPKI Validator 3.0 - tbruijnzeels - 10m > Fini! > > There are slides from: > sriram (2x slides) > bweis > smurphy (coming soon to an inbox near me) > > There are no slides yet from: (or I missed them, totes possible!) > sgoldbe > sgoldbe's slides arrived, thanks! > tbruijnnbzeels > rbush > > Please send slides soon, prior to noon Tuesday (noon chicago time!)... > Or alternately say you have no need of slides (rbush?)..y > -chris/keyur > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --001a1136fb1836e5c9054bc3c4d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Mon, Mar 27, 2017 at 5:58 PM, Chris Morrow <morrowc@ops-netman= .net> wrote:
    Howdy SidrOps = Folks:

    The agenda is:

    Agenda Bashing - 5m
    SIDR Status Update - smurphy - 5m
    BGPSec Router Certificate Rollover - bweis - 15m
    Decoupling BGPSec and ExtMsgs - sriram - 15m
    The Use of MaxLength in the RPKI - sgoldbe - 15m
    Route Leak Detection and Filtering - rbush - 10m
    Detection/Mitigation of BGP Route Leaks - sriram - 15m
    RIPE NCC RPKI Validator 3.0 - tbruijnzeels - 10m
    Fini!

    There are slides from:
    =C2=A0 sriram (2x slides)
    =C2=A0 bweis
    =C2=A0 smurphy (coming soon to an inbox near me)

    There are no slides yet from: (or I missed them, totes possible!)
    =C2=A0 sgoldbe

    sgoldbe's slides arrived, thanks!
    =C2=A0
    =C2=A0 tbruijnnbzeels
    =C2=A0 rbush

    Please send slides soon, prior to noon Tuesday (noon chicago time!)...
    Or alternately say you have no need of slides (rbush?)..y
    -chris/keyur

    _______________________________________________
    Sidrops mailing list
    Sidrops@ietf.org
    https://www.ietf.org/mailman/listinfo/sidrops<= br>

    --001a1136fb1836e5c9054bc3c4d3-- From nobody Fri Mar 31 08:00:44 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 37D4C12950A; Fri, 31 Mar 2017 08:00:42 -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 vT0U5ZNibNv7; Fri, 31 Mar 2017 08:00:33 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 801EF1299DC; Fri, 31 Mar 2017 08:00:25 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id r142so69119545qke.2; Fri, 31 Mar 2017 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DzjPzTm43uK8Wr2XIulIesIa9pdFezxarcia4Cn9dNk=; b=hAi2gYNxqA69w65elS1pE8EuEz2gInxR7lo/MKqjQAkNeuD2xnNOLz6g7SLvKrk9j4 7+6kwjlNnilvJc9C2kmHlf8alp0DZPPhnpIODHzJHyldeOF93kNkYhb1YrZ69aB+4FSz Dte35wA2RHblg/Kh0xrtYLQ7Ixm9p5BTc4iXpV7NnJuJ0KfBSG7zKttsf+9O8XG5Tb2E coofa1jzqHH9+3sy/yNTk3FYUL9a1dGS8W1D/QdnSV3E7ihynJWTzZnrVV/Vs+KaRcKL woFgLwdx+YSJIUYF2Wtr+yS3R/bRpo0FQqw53/dmHFuU+wmaefCH68ZvbSbOvC2gXt36 XMQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DzjPzTm43uK8Wr2XIulIesIa9pdFezxarcia4Cn9dNk=; b=GkpmrCAZbUJnk920TPGJezivXWFDEc2CXhviQKAuMka6rDFl5CqDF3mVXPyJ0pWsyF xQ4CWhq1tATqnrD3qRCAdEPqSrsqYF1ykJrH3X5/bTqatkKRx7/qsqZioHpPIQC8qHON vS7j6LaST1ja2Nqy2vCxlk9Yrl7Ji9WwKh8tamcB2Gt5T75HV1osFLicAckJUgx+YrFH RFVOIGSoHy1uAO1UjSP191yUWCzebvqH3XfmvLZg3l0WO8deUebIz4w1u42v/HPHRTX/ oX2Xe/1ddBVHkX8bE+kwkMpY29VMaNeeJC+Y06lP0HoyDQvN8y5RhExUFLIigUBzrkeB puzQ== X-Gm-Message-State: AFeK/H1biG8VpHgnW8Hy9Qf5uSSQvn4v1WDmsht42K6BH87Er0VdlVj9DxnHBeIbmC6Us4QErTbW27ra7xzMlg== X-Received: by 10.55.135.7 with SMTP id j7mr2885319qkd.58.1490972424416; Fri, 31 Mar 2017 08:00:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.75 with HTTP; Fri, 31 Mar 2017 08:00:24 -0700 (PDT) From: Christopher Morrow Date: Fri, 31 Mar 2017 09:00:24 -0600 Message-ID: To: sidrops@ietf.org, sidrops-ads@ietf.org, sidrops-chairs@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07480cba3a74054c08111a Archived-At: Subject: [Sidrops] WGLC for draft-ietf-sidrops-bgpsec-rollover-00 - ENDS: 04/21/2017 (April 21 2017) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:00:42 -0000 --94eb2c07480cba3a74054c08111a Content-Type: text/plain; charset=UTF-8 Howdy WG folks: This is the start of a WGLC for the subject draft, I set the end to April 21, because this is the end of travel-week. The draft abstract: "BGPsec will need to address the impact from regular and emergency rollover processes for the BGPsec end-entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec EE certificates must be carefully managed in order to synchronize distribution of router public keys and the usage of those public keys by BGPsec routers. This memo provides general recommendations for that process, as well as describing reasons why the rollover of BGPsec EE certificates might be necessary." Please give the document a read-through, it's 9 whole pages of joy and bliss, and send comments/complaints/suggestions/"Terrific docuemnt!" to this thread. Thanks! -chris morrow co-chair sidrops. --94eb2c07480cba3a74054c08111a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Howdy WG folks:

    This is the start of a = WGLC for the subject draft, I set the end to April 21, because this is the = end of travel-week.

    The draft abstract:
    =C2=A0 = "BGPsec will need to address the impact from regular and emergency
    =C2=A0 =C2=A0rollover processes for the BGPsec end-entity (EE) certi= ficates that
    =C2=A0 =C2=A0will be performed by Certificate Author= ities (CAs) participating at
    =C2=A0 =C2=A0the Resource Public Key= Infrastructure (RPKI).=C2=A0 Rollovers of BGPsec
    =C2=A0 =C2=A0EE= certificates must be carefully managed in order to synchronize
    = =C2=A0 =C2=A0distribution of router public keys and the usage of those publ= ic keys
    =C2=A0 =C2=A0by BGPsec routers.=C2=A0 This memo provides = general recommendations for
    =C2=A0 =C2=A0that process, as well as= describing reasons why the rollover of
    =C2=A0 =C2=A0BGPsec EE ce= rtificates might be necessary."

    Please give t= he document a read-through, it's 9 whole pages of joy and bliss, and se= nd comments/complaints/suggestions/"Terrific docuemnt!" to this t= hread.


    Thanks!
    -chris mor= row
    co-chair sidrops.
    --94eb2c07480cba3a74054c08111a-- From nobody Fri Mar 31 08:36:59 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 1E6D61298B7; Fri, 31 Mar 2017 08:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 hpn-Tn_WB0tV; Fri, 31 Mar 2017 08:36:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 13293129A12; Fri, 31 Mar 2017 08:36:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ctyba-0000v2-TT; Fri, 31 Mar 2017 15:36:51 +0000 Date: Fri, 31 Mar 2017 10:36:50 -0500 Message-ID: From: Randy Bush To: Christopher Morrow Cc: sidrops@ietf.org, sidrops-ads@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-bgpsec-rollover-00 - ENDS: 04/21/2017 (April 21 2017) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:36:58 -0000 ship it From nobody Fri Mar 31 08:47:04 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 DB91C129435; Fri, 31 Mar 2017 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUSPICIOUS_RECIPS=2.51] 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 GgBg301WeObg; Fri, 31 Mar 2017 08:46:55 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD831294DF; Fri, 31 Mar 2017 08:46:55 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 9DAC53FD95; Fri, 31 Mar 2017 15:46:53 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (dhcp-860c.meeting.ietf.org [31.133.134.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 4E0DA395433E; Fri, 31 Mar 2017 15:46:53 +0000 (UTC) Date: Fri, 31 Mar 2017 09:46:52 -0600 Message-ID: From: Chris Morrow To: sidr-chairs@ietf.org, sidrops-chairs@ietf.org, sidr-ads@ietf.org, sidrops-ads@ietf.org, sidrops@ietf.org, sidr@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] WGLC - draft-ietf-sidr-lta-use-cases-07 - ENDS 04/21/2017 (April 21 2017) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:46:57 -0000 howdy Sidr/SidrOps folks, I believe the draft: draft-ietf-sidr-lta-use-cases-07 has been prepared for publication, and we must decide as WGs that this is the case. As a reminder this is one of several drafts started in SIDR which was moved to SIDROPS, so this is really a 'SIDROPS WGLC', but there are still interested parties on SIDR's mailing list, so the call is going to both groups. Document Abstract: "There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them." Please review the 5 short pages of text, send along updates/comments/complaints/'terrific work!' notes to this thread, so the authors can be aprised and we can plan to send this document in the proper direction. Thanks! -chris morrow co-chair