From nobody Thu Mar 1 04:56:39 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2122F1204DA; Thu, 1 Mar 2018 04:56:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151990899208.10164.14016335944193541325@ietfa.amsl.com> Date: Thu, 01 Mar 2018 04:56:32 -0800 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-13.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 12:56:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Operational Security Considerations for IPv6 Networks Authors : Eric Vyncke Kiran K. Chittimaneni Merike Kaeo Enno Rey Filename : draft-ietf-opsec-v6-13.txt Pages : 49 Date : 2018-03-01 Abstract: Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-v6-13 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 1 05:08:30 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757BD126D85; Thu, 1 Mar 2018 05:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AHSI_Tc1VC0o; Thu, 1 Mar 2018 05:08:20 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486D9126D45; Thu, 1 Mar 2018 05:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6908; q=dns/txt; s=iport; t=1519909700; x=1521119300; h=from:to:cc:subject:date:message-id:mime-version; bh=QryMJIQ+XkQ38cit0dmLCs3C0TUoSDLvf8+tPYorYGo=; b=aZtMfcQTN7Bbu8V0q4AsfnKq8G7dOs91Twh8HdSPRyjjeFAWe4pcs40X DHdm75fWx85jYB9clOJCPgEZaKwYbo8HIuAcRHng6oJmFCH2ipFc3uTkq rgNKFlkFjtgvtTSjFDWXqR4fbx7y6SgU6LVoVMbs5WWyvHq10Fj8jWmou E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AgAk+pda/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadmZwKAqDSpgVgVuBPY8MhSCCFQojhQ0cgkMhNhYBAgEBAQE?= =?us-ascii?q?BAQJrKIVNVhIBSgIEMCcEAQ2EPGQQqxOCJyaIQYIWAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWHTYFXgg8MhiYCAgEYgTODMDCCMgWIN5IhCQKBUoR+iiiOdol7hys?= =?us-ascii?q?CERkBgS0BJQIvgVJwFWQBghiEWncBi2+BFwEBAQ?= X-IronPort-AV: E=Sophos; i="5.47,408,1515456000"; d="scan'208,217"; a="77302381" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2018 13:08:19 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w21D8Jnj001911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Mar 2018 13:08:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 1 Mar 2018 08:08:18 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 1 Mar 2018 08:08:17 -0500 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" , "v6ops@ietf.org WG" CC: "draft-ietf-opsec-v6.authors@ietf.org" , "erey@ernw.de" Thread-Topic: What is new in draft-ietf-opsec-v6-13.txt ? Thread-Index: AQHTsV5d1CvXh4YmeEu9TUqIp+knmg== Date: Thu, 1 Mar 2018 13:08:17 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.12] Content-Type: multipart/alternative; boundary="_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: [OPSEC] What is new in draft-ietf-opsec-v6-13.txt ? X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 13:08:23 -0000 --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGEgbG90IG9mIGNoYW5nZXMgaW4gdGhlIC0xMyB2ZXJzaW9uLCBtYW55IG1pbm9y IGFuZCBhIGNvdXBsZSBvZiBiaWdnZXIgb25lcyAoc3VjaCB0aGUgVUxBIHNlY3Rpb24pLiBBIG5l dyBhdXRob3IsIEVubm8gUmV5LCBoYXMgam9pbmVkIHRoZSB0ZWFtIGFuZCBoYXMgcHJvdmlkZWQg YSB0cmVtZW5kb3VzIGFtb3VudCBvZiBzdWdnZXN0aW9ucy9jaGFuZ2VzLiBXZSBhbHNvIGhhdmUg YWN0ZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gT2xlIFRyb2FuLCBSb24gQm9ubmljYSwgQmVybmll IFZvbHosIEZlcm5hbmRvIEdvbnQgYW5kIEVyaWsgS2xpbmUuDQoNCkFzIHVzdWFsIHlvdSBjYW4g Y29tcGFyZSB0aGUgdmVyc2lvbnMgd2l0aDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMTMudHh0DQoNClRoZSBhdXRob3JzIHdpbGwgd2Vs Y29tZSByZXZpZXdzIGFuZCBjb21tZW50cyBlc3BlY2lhbGx5IG9uIHRoZSBuZXcgc2VjdGlvbiAy LjEuMiAoVXNlIG9mIFVMQXMpOiB0aGlzICd1Z2x5JyB0b3BpYyBuZWVkcyB0byBiZSBpbiB0aGlz IGRvY3VtZW50IGFuZCBubyBhdXRob3Igd2FudHMgdG8gcmVjb21tZW5kIGl0IG9idmlvdXNseSA7 LSkNCg0KT25lIG9wZW4gcG9pbnQgaXMgd2hhdCB0byBkbyB3aXRoICdtb3N0bHkgb2Jzb2xldGUn IHR1bm5lbGluZyBzdWNoIGFzIFRlcmVkbyBhbmQgNnRvNCA/IE9sZSB3YW50cyB0byByZW1vdmUg dGhvc2Ugc2VjdGlvbnMgY29tcGxldGVseSBidXQgdGhlIGF1dGhvcnMgZmVlbCB0aGF0IHdlIG5l ZWQgdG8ga2VlcCB0aGVtIHRvIGJlIGV4aGF1c3RpdmUuDQoNClNhbWUgZm9yIHRoZSBDR04gKE5B VDQ0NCkgc2VjdGlvbiwgbm90IHJlYWxseSBhbiBJUHY2IHRvcGljLCBidXQgYW4gaW1wb3J0YW50 IHJlbGF0ZWQtb25lIGFuZCB0aGUgZG9jdW1lbnQgaXMgaW4gT1BTRUMgV0cgKHdoaWNoIGlzIHBy b3RvY29sIHZlcnNpb24gYWdub3N0aWMpLg0KDQpUaGFuayB5b3UgaW4gYWR2YW5jZSBhbmQgc2Vl IHlvdSBpbiBMb25kb24NCg0KLcOpcmljDQo= --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1142C9D42D61BA4F8A49306493BEE553@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ VGhlcmUgYXJlIGEgbG90IG9mIGNoYW5nZXMgaW4gdGhlIC0xMyB2ZXJzaW9uLCBtYW55IG1pbm9y IGFuZCBhIGNvdXBsZSBvZiBiaWdnZXIgb25lcyAoc3VjaCB0aGUgVUxBIHNlY3Rpb24pLiBBIG5l dyBhdXRob3IsIEVubm8gUmV5LCBoYXMgam9pbmVkIHRoZSB0ZWFtIGFuZCBoYXMgcHJvdmlkZWQg YSB0cmVtZW5kb3VzIGFtb3VudCBvZiBzdWdnZXN0aW9ucy9jaGFuZ2VzLg0KIFdlIGFsc28gaGF2 ZSBhY3RlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBPbGUgVHJvYW4sIFJvbiBCb25uaWNhLCBCZXJu aWUgVm9seiwgRmVybmFuZG8gR29udCBhbmQgRXJpayBLbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHVzdWFsIHlvdSBjYW4gY29tcGFyZSB0aGUgdmVy c2lvbnMgd2l0aDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNlYy12Ni0xMy50eHQiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMTMudHh0PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGF1dGhvcnMgd2ls bCB3ZWxjb21lIHJldmlld3MgYW5kIGNvbW1lbnRzIGVzcGVjaWFsbHkgb24gdGhlIG5ldyBzZWN0 aW9uIDIuMS4yIChVc2Ugb2YgVUxBcyk6IHRoaXMgJ3VnbHknIHRvcGljIG5lZWRzIHRvIGJlIGlu IHRoaXMgZG9jdW1lbnQgYW5kIG5vIGF1dGhvciB3YW50cyB0byByZWNvbW1lbmQgaXQgb2J2aW91 c2x5IDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T25lIG9w ZW4gcG9pbnQgaXMgd2hhdCB0byBkbyB3aXRoICdtb3N0bHkgb2Jzb2xldGUnIHR1bm5lbGluZyBz dWNoIGFzIFRlcmVkbyBhbmQgNnRvNCA/IE9sZSB3YW50cyB0byByZW1vdmUgdGhvc2Ugc2VjdGlv bnMgY29tcGxldGVseSBidXQgdGhlIGF1dGhvcnMgZmVlbCB0aGF0IHdlIG5lZWQgdG8ga2VlcCB0 aGVtIHRvIGJlIGV4aGF1c3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5TYW1lIGZvciB0aGUgQ0dOIChOQVQ0NDQpIHNlY3Rpb24sIG5vdCByZWFsbHkgYW4g SVB2NiB0b3BpYywgYnV0IGFuIGltcG9ydGFudCByZWxhdGVkLW9uZSBhbmQgdGhlIGRvY3VtZW50 IGlzIGluIE9QU0VDIFdHICh3aGljaCBpcyBwcm90b2NvbCB2ZXJzaW9uIGFnbm9zdGljKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSBpbiBhZHZh bmNlIGFuZCBzZWUgeW91IGluIExvbmRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+LcOpcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_-- From nobody Thu Mar 1 09:37:34 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256451275F4 for ; Thu, 1 Mar 2018 09:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 Uizis64jY6Dv for ; Thu, 1 Mar 2018 09:37:30 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3D5D2126C25 for ; Thu, 1 Mar 2018 09:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519925848; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lr8iXmlqJA9ALSC0Ir26dOfQWmeAkJfstk3fYiUjqjo=; b=U6nBKPiGHdJZ80uzmXYkpd/t0/VJhEvg2Wczt1wYmSojZB+EFf/DCUDWbOcRu938 r6BeMdSp5YCHMA4x4B2uHMMXJlbc3sbniJnJC5XzEWFKdlpe39S92vFtwryCZCah 9cnVZW7JH2TjbVve6v9GI1OfrYNQyFMkDc5/fL+V+I4=; X-AuditID: c1b4fb3a-35fff700000067b4-3b-5a983a581bbb Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0E.A9.26548.85A389A5; Thu, 1 Mar 2018 18:37:28 +0100 (CET) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.352.0; Thu, 1 Mar 2018 18:37:27 +0100 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id EE77A4815C7; Thu, 1 Mar 2018 19:37:27 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 64A32481568; Thu, 1 Mar 2018 19:37:27 +0200 (EET) To: "C. M. Heard" , Fernando Gont CC: OPSEC , Michael Richardson , Pascal Thubert References: <674.1511883811@obiwan.sandelman.ca> <31dd06ae-d314-15af-8ff2-9a05547c457b@si6networks.com> <5679d8f1-b643-a862-69c1-eb6664e8edeb@si6networks.com> From: Ines Robles Message-ID: <5c5ec26b-ace0-e529-c435-5027b155b802@ericsson.com> Date: Thu, 1 Mar 2018 19:37:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdSzfCakaUwf4uZYsnq96wWdzYM4fF oudQP7vFh6132SxmTHnH6MDqMeX3RlaPJUt+MnlcvKTs0TJnD7PHh0M97AGsUVw2Kak5mWWp Rfp2CVwZyx5MZy24xF/x9sge5gbG4zxdjBwcEgImEu8XhnUxcnEICRxmlPhzvZkRwtnOKHFi djM7hLOJUWLCwRNsEM4CRonWCcuAyjg5hAXiJa4sXMoMYosIeEksfPqEHWQss0CuxN3PmRD1 35kk5n+ZzwZSwyZgJHH2w08wm1fAXuLS4unMIPUsAioS3/pEQMKiAhESnSvns0CUCEqcnPkE zOYUCJQ4+nIvE4jNLGAhMXP+eUYIW15i+9s5zBC2uMStJ/PBaiQElCUWtCwCqxES0JaYPvc+ ywRGkVlIxs5CMmoWklGzkIxawMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwlg5u+W21 g/Hgc8dDjAIcjEo8vKu0ZkQJsSaWFVfmHmKU4GBWEuE9vX1alBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFepzSLKCGB9MSS1OzU1ILUIpgsEwenVAOjgczvO+dv83MKX/KbHGn7M+hOSscyf8VH 9xu2mBz2fbc6pr13k5TGdaG/b/lDfz18snL+HalI09tyXCqFdq7h5xjO5R1yXMy7/8n7jlPd 3R//pK7SYKo9tpbrxM/qso121b1b2L+6Fx2wkTxQoZj4Nttj9+lp8Yxn3zmIPZl1dNOE/oy8 XK2XSizFGYmGWsxFxYkAUYeHqqECAAA= Archived-At: Subject: Re: [OPSEC] Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:37:32 -0000 Thank you very much Mike for addressing this topic :) , and thank you Fernando for bringing this up. :) We added a clarification related to this issue in the just submitted new version , https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-22 Cheers, Ines. On 01.03.2018 05:04, C. M. Heard wrote: > On Wed, Feb 28, 2018 at 8:39 AM, Fernando Gont wrote: >> On 02/28/2018 01:29 PM, C. M. Heard wrote: >>> The option type is being changed from 0x63 to 0x23 precisely so >>> that non-RPL routers will NOT drop packets with that option. >>> See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-21, >>> which has recently been submitted to the IESG for publication. >> It would seem that such decision has been a response to publication of >> RFC8200... but I don't follow. > The wording of the draft can certainly give that impression, but that is not > the case. The change was made to prevent packets with the RPI option that > exit from an RPL domain from being discarded by a non-RPL node. > >> What's the reason for which 0x63 was required to be dropped, but 0x23 is >> required not to? > Because 0x63 has the upper two bits that say "discard the packet" if the > option is unrecognized, which would be the case for a non-RPL aware > node, while 0x23 has the upper two bits that say "skip over this option > and continue processing the header." > >> Am I missing something, or is the motivation of the change to "comply >> with RFC8200"? -- [i]f so, such change is not really required. > The motivation is not to comply with RFC 8200, but rather to make it possible > for an RPL-aware end node to send an IPv6 datagram to a non-RPL aware > node on the general Internet without the need for IP-in-IP encapsulation. > See the example in Section 6.2.1 of the above-referenced draft. If a > firewall were to (un)helpfully filter packets with the RPI option, then > that objective could not be realized. > > Mike Heard From nobody Sat Mar 3 12:12:10 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1E1243FE for ; Sat, 3 Mar 2018 12:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 IzV1-sL_J4_D for ; Sat, 3 Mar 2018 12:12:06 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CEC12008A for ; Sat, 3 Mar 2018 12:12:06 -0800 (PST) Received: from [192.168.3.68] (unknown [186.138.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 520C786300; Sat, 3 Mar 2018 21:11:59 +0100 (CET) To: "Pascal Thubert (pthubert)" , Michael Richardson , "C. M. Heard" Cc: OPSEC , Ines Robles References: <674.1511883811@obiwan.sandelman.ca> <5553d3d161d24c5cbb5aabae4e1bc6a0@XCH-RCD-001.cisco.com> From: Fernando Gont Message-ID: <90390496-8c5d-fbe3-2536-55d05ff11ad2@si6networks.com> Date: Sat, 3 Mar 2018 10:34:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5553d3d161d24c5cbb5aabae4e1bc6a0@XCH-RCD-001.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 20:12:08 -0000 On 11/28/2017 01:00 PM, Pascal Thubert (pthubert) wrote: > Hello Michael: > > Clarifiation would be that dropping 0x63 is OK but dropping 0x23 or whatever it is that IANA assigns (as Brian said) for us is not. > It would be simpler that we just remove the HbH Hdr at the egress of the RPL network systematically; this overrides a rule in RFC 8200 but still makes sense in the particular case. Will do. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 5 10:51:37 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D9D12D86B for ; Mon, 5 Mar 2018 10:51:36 -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, 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=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3xLDjmep9M for ; Mon, 5 Mar 2018 10:51:35 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B51A12D7E8 for ; Mon, 5 Mar 2018 10:51:35 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id z9so17546758wmb.3 for ; Mon, 05 Mar 2018 10:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oUuNW3CAAtpvHxm/soaVcVxH+RypHXaGwhdLBvv/EnQ=; b=szbxT20dU7pwAsAyDrfGj0dXzh3qEL3qpp3Hej9ejcGDFoebdZOnFgudPm6w3a1VPq F4GmMdNYd404V8AdOgxLxOYCgoXYZ7zngo/KmQQGAza10yV5P6x3uS1U0SM7jchoo2hl Q0HofBWmfjbdxdX09w0waB0ndSBnGu6wxyfbNd3Hufqx2tio/3x3B09gn2rbFl4H3kIS scb4nYB/J6ES+4QVicVIBEpcM6LAkH8NjEesmrVeGVw42v41VfLCgEoUqXFGs+52/PJr +MxPPP6GVCLYrdelnxoPfRo2E7y0QebqzT+JVRaDxWe4+kicJ8OywvAeNqDuOY2xE3kv OrPg== 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=oUuNW3CAAtpvHxm/soaVcVxH+RypHXaGwhdLBvv/EnQ=; b=Fk/RPGvxQ0MYhKw1mGucvaU97IfVs9xN5MafUuagfqAt3aFkeU3jse8Yd8OIZ9FHGA cO4srIlUlhJk2fSHEKrEqFk+VL5RndU2rk0TnI+47JA2BVWDW1pSvIMSIzfOcRuUnC2Z 0Lgg+tQF+vyi5DYVmm7KJjDSAgg3SSemfQfz8ajQ+xPh+sULrmleITOO1LAQ552RFfU8 uJdYCb/4Le6CmJ4txjkstFfVCoKhTGvjAsVCYwXHOkrZfG5XBaiEaDN7e2NAi6nElLj1 n2cTVIsnAVhf80+1lnVOTVYXBnFX2JtLvJaqL8Cio1SpfxJgxDDmuwOaWsmB70td8uFa xDkA== X-Gm-Message-State: AElRT7F6L5Uxj9UoYIf6Oe1eEJ7fIHPS0IGlujY4cw5zvj1YEUajXFLo 42xFz+Fhj9wbfSbeNraiNRExK6gcnxp3gQj1AgRxieBS X-Google-Smtp-Source: AG47ELuhM/fLuBrtAZmuAlRqIZd23J6b3mU7VvKRmn6F5iQHDe/zxN6dBGjtR4J1WvsPdc/qFV7VvuTg50bxHEQXcHY= X-Received: by 10.28.191.138 with SMTP id o10mr4217428wmi.26.1520275893219; Mon, 05 Mar 2018 10:51:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.152.235 with HTTP; Mon, 5 Mar 2018 10:50:52 -0800 (PST) From: Warren Kumari Date: Mon, 5 Mar 2018 13:50:52 -0500 Message-ID: To: opsec wg mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OPSEC] Appointing Ron Bonica as new OpSec chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 18:51:37 -0000 Hi all, I'm pleased to announce that Ron Bonica has agreed to become the new OpSec chair, replacing Gunter who is stepping down to be able to focus on chairing LSVR (and running the OpsDir group). Let's take a moment to thank Gunther again, and please welcome Ron. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Mar 5 15:31:52 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC012EAF8; Mon, 5 Mar 2018 15:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152029270864.12765.1089785466220033128@ietfa.amsl.com> Date: Mon, 05 Mar 2018 15:31:48 -0800 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 23:31:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers Authors : Fernando Gont Will(Shucheng) Liu Filename : draft-ietf-opsec-ipv6-eh-filtering-05.txt Pages : 35 Date : 2018-03-05 Abstract: It is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic *not* directed to them, for those cases in which such filtering is deemed as necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 17:51:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8E124217 for ; Mon, 5 Mar 2018 17:51:00 -0800 (PST) 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, 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 MurPM8BgOgbs for ; Mon, 5 Mar 2018 17:50:58 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8CA127286 for ; Mon, 5 Mar 2018 17:50:57 -0800 (PST) Received: from [192.168.3.68] (unknown [186.138.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8847386365; Tue, 6 Mar 2018 02:50:53 +0100 (CET) To: Ines Robles , Ines Robles , "C. M. Heard" , "Pascal Thubert (pthubert)" Cc: opsec@ietf.org References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> From: Fernando Gont Message-ID: <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> Date: Mon, 5 Mar 2018 22:22:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152029270864.12765.1089785466220033128@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 01:51:00 -0000 Folks, This rev is meant to address your feedback regarding opt 0x23 (draft-ietf-roll-useofrplinfo). Please do let us know if your concerns have been addressed. Thanks! Cheers, Fernando On 03/05/2018 08:31 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. > > Title : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers > Authors : Fernando Gont > Will(Shucheng) Liu > Filename : draft-ietf-opsec-ipv6-eh-filtering-05.txt > Pages : 35 > Date : 2018-03-05 > > Abstract: > It is common operator practice to mitigate security risks by > enforcing appropriate packet filtering. This document analyzes both > the general security implications of IPv6 Extension Headers and the > specific security implications of each Extension Header and Option > type. Additionally, it discusses the operational and > interoperability implications of discarding packets based on the IPv6 > Extension Headers and IPv6 options they contain. Finally, it > provides advice on the filtering of such IPv6 packets at transit > routers for traffic *not* directed to them, for those cases in which > such filtering is deemed as necessary. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05 > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 6 00:32:31 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536FB124D37 for ; Tue, 6 Mar 2018 00:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Wqc4CixlVgMw for ; Tue, 6 Mar 2018 00:32:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 59ED2120724 for ; Tue, 6 Mar 2018 00:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520325146; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QEw10e62yLAD6nE98L9wZac3bpfgt0cCQySE3VIcZ+4=; b=Ld2jBfzTErV++42YSVYwZXWfnKNQeyFvib/Rj7gSjmUhuoJEP4Gqa243WGmBIUVh JYg01dLCuMaeBbEjavjLvKQGH+vhx90H51Q0wYHHEmIsKJ0DjUCmomMdBODlGApD VDgmU/Bo6Zwoa6afRJvbqg7ZE9Bx0NyaAb1spdjhUCI=; X-AuditID: c1b4fb3a-35fff700000067b4-61-5a9e521a892f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.FB.26548.A125E9A5; Tue, 6 Mar 2018 09:32:26 +0100 (CET) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.352.0; Tue, 6 Mar 2018 09:32:25 +0100 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id ED3344817AB; Tue, 6 Mar 2018 10:32:25 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 84DFA4815C3; Tue, 6 Mar 2018 10:32:25 +0200 (EET) To: Fernando Gont CC: Ines Robles , "C. M. Heard" , "Pascal Thubert (pthubert)" , References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> From: Ines Robles Message-ID: Date: Tue, 6 Mar 2018 10:32:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> Content-Type: multipart/alternative; boundary="------------6761BEC4250ACD8F0F35A7C1" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7k65U0Lwog22/1S2erHrDZnFjzxwW iw0t/1ksPmy9y2YxY8o7RgdWjym/N7J6PJ0wmd1jyZKfTB4XLyl7fDjUwx7AGsVlk5Kak1mW WqRvl8CV8XxTJ0vBSpuKw/ta2RoYFxh2MXJySAiYSPw6+4W1i5GLQ0jgMKPEvgermSCc7YwS 7/seMUM4mxgltrz4CJVZwCgx/2EjE0i/sICXxL79X5lBbBEBTYm5z4+AFTELzGSUeHhoMytI QkigRuLlwzNgRWwCRhJnP/xk62Lk4OAVsJdYOhHsDhYBFYn2z//AykUFIiQ6V85nAbF5BQQl Ts58AmZzCjhLtHRcBtvLLBAm8WxbFxuELS5x68l8Joh/lCUWtCxihFirLTF97n2WCYzCs5CM moWkfRaSdgjbQmLm/POMELa8RPPW2cwQtoZE65y57MjiCxjZVzGKFqcWF+emGxnppRZlJhcX 5+fp5aWWbGIExt/BLb+tdjAefO54iFGAg1GJh1fNe16UEGtiWXFl7iFGCQ5mJRHeCH2gEG9K YmVValF+fFFpTmrxIUZpDhYlcV6nNIsoIYH0xJLU7NTUgtQimCwTB6dUA6Oox87UM6wLV3/0 SVnFPFF8+vfTztKBnbFhXiEWK74G15ZsmR732/ACk9v5+nPNSV7pR9Q97uu35orFxwRf6zh7 /rbo24SGvu+vQ5azXhfhuFvpY+3/aNGGeSdv/7iXM39Fq5HIJp3HGsstArhvL1E5qq2tz7aB 2eOb+9aSk7fZ94jEHPeN6FJiKc5INNRiLipOBAC8UzPauwIAAA== Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 08:32:30 -0000 --------------6761BEC4250ACD8F0F35A7C1 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Fernando, Thank you very much for the updated document. It looks good to me, Just a comment: where states  "...This option was originally specified in [RFC6553 ]. It has been deprecated by [I-D.ietf-roll-useofrplinfo ]." I would replace "deprecated" by "updated", since the roll-I-D updates the RPL Option with a new value. What do you think? Thanks, Ines. On 06.03.2018 03:22, Fernando Gont wrote: > Folks, > > This rev is meant to address your feedback regarding opt 0x23 > (draft-ietf-roll-useofrplinfo). > > Please do let us know if your concerns have been addressed. > > Thanks! > > Cheers, > Fernando > > > > > On 03/05/2018 08:31 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. >> >> Title : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers >> Authors : Fernando Gont >> Will(Shucheng) Liu >> Filename : draft-ietf-opsec-ipv6-eh-filtering-05.txt >> Pages : 35 >> Date : 2018-03-05 >> >> Abstract: >> It is common operator practice to mitigate security risks by >> enforcing appropriate packet filtering. This document analyzes both >> the general security implications of IPv6 Extension Headers and the >> specific security implications of each Extension Header and Option >> type. Additionally, it discusses the operational and >> interoperability implications of discarding packets based on the IPv6 >> Extension Headers and IPv6 options they contain. Finally, it >> provides advice on the filtering of such IPv6 packets at transit >> routers for traffic *not* directed to them, for those cases in which >> such filtering is deemed as necessary. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05 >> https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > --------------6761BEC4250ACD8F0F35A7C1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Fernando,

Thank you very much for the updated document. It looks good to me,

Just a comment:

where states  "...This option was originally specified in [RFC6553]. It has been deprecated by [I-D.ietf-roll-useofrplinfo]."

I would replace "deprecated" by "updated", since the roll-I-D updates the RPL Option with a new value. What do you think?

Thanks,

Ines.


On 06.03.2018 03:22, Fernando Gont wrote:
Folks,

This rev is meant to address your feedback regarding opt 0x23
(draft-ietf-roll-useofrplinfo).

Please do let us know if your concerns have been addressed.

Thanks!

Cheers,
Fernando




On 03/05/2018 08:31 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF.

        Title           : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers
        Authors         : Fernando Gont
                          Will(Shucheng) Liu
	Filename        : draft-ietf-opsec-ipv6-eh-filtering-05.txt
	Pages           : 35
	Date            : 2018-03-05

Abstract:
   It is common operator practice to mitigate security risks by
   enforcing appropriate packet filtering.  This document analyzes both
   the general security implications of IPv6 Extension Headers and the
   specific security implications of each Extension Header and Option
   type.  Additionally, it discusses the operational and
   interoperability implications of discarding packets based on the IPv6
   Extension Headers and IPv6 options they contain.  Finally, it
   provides advice on the filtering of such IPv6 packets at transit
   routers for traffic *not* directed to them, for those cases in which
   such filtering is deemed as necessary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------6761BEC4250ACD8F0F35A7C1-- From nobody Tue Mar 6 00:37:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2893E124D37 for ; Tue, 6 Mar 2018 00:37:01 -0800 (PST) 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 k879vm3Snrso for ; Tue, 6 Mar 2018 00:36:59 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4511120724 for ; Tue, 6 Mar 2018 00:36:58 -0800 (PST) Received: from [192.168.3.68] (unknown [186.138.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B179B8637F; Tue, 6 Mar 2018 09:36:54 +0100 (CET) To: Ines Robles Cc: Ines Robles , "C. M. Heard" , "Pascal Thubert (pthubert)" , opsec@ietf.org References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> From: Fernando Gont Message-ID: <5eff8a4c-f780-adfb-17a1-d2f2ed793000@si6networks.com> Date: Tue, 6 Mar 2018 05:36:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 08:37:01 -0000 Hola, Ines, On 03/06/2018 05:32 AM, Ines Robles wrote: > Hi Fernando, > > Thank you very much for the updated document. It looks good to me, > > Just a comment: > > where states  "...This option was originally specified in [RFC6553 > ]. It has been deprecated by > [I-D.ietf-roll-useofrplinfo > ]." > > I would replace "deprecated" by "updated", since the roll-I-D updates > the RPL Option with a new value. What do you think? My description was based on the "IANA Considerations" of your document, which says: [RFCXXXX] represents this document. Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- 0x23 00 1 00011 RPL Option [RFCXXXX] 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] SO, while you don't say that elsewhere, it would seem to me that you *are* deprecating it? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 6 00:47:41 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AB5126D0C for ; Tue, 6 Mar 2018 00:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 e1S3Ra2sX6bG for ; Tue, 6 Mar 2018 00:47:38 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0E6D7126BF0 for ; Tue, 6 Mar 2018 00:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520326056; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/fMX2dJ7M5JW9ho/KQPBzsMyecrT5zoxPgyvSj2F0kA=; b=ViiNCBxqZV9IPOeRnGsumYRY8Tt/pOeaWkas2EpyO+TS/TYyWrSLR4kAYW0MHkt9 IO9Q879OFkkGJ4DseCaF8upiTiGNfuDzXZecm+HrHyqnMD/yyhRvz7xVk1TMcTF5 acZ2Q5xg6Yn2PMhdIXmE8wzFt/okOhf59B+0CyUQHx0=; X-AuditID: c1b4fb30-3b1ff70000004778-cf-5a9e55a83bfa Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.1E.18296.8A55E9A5; Tue, 6 Mar 2018 09:47:36 +0100 (CET) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.352.0; Tue, 6 Mar 2018 09:47:35 +0100 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id B4D904817AB; Tue, 6 Mar 2018 10:47:35 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 4764F4815C3; Tue, 6 Mar 2018 10:47:35 +0200 (EET) To: Fernando Gont CC: Ines Robles , "C. M. Heard" , "Pascal Thubert (pthubert)" , References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> <5eff8a4c-f780-adfb-17a1-d2f2ed793000@si6networks.com> From: Ines Robles Message-ID: <31f6072e-0819-446f-7510-7bb3d8b7f811@ericsson.com> Date: Tue, 6 Mar 2018 10:47:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5eff8a4c-f780-adfb-17a1-d2f2ed793000@si6networks.com> Content-Type: multipart/alternative; boundary="------------19287F3361849C3197F93AE2" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7pe6K0HlRBueuSlo8WfWGzeLGnjks Fhta/rNYfNh6l81ixpR3jA6sHlN+b2T1eDphMrvHkiU/mTwuXlL2+HCohz2ANYrLJiU1J7Ms tUjfLoErY8PKX6wFb7UrPm5cxNbAOFuji5GTQ0LAROLCyy8sILaQwGFGiWut6l2MXED2dkaJ g3e/MUM4mxglXi/rZINwFjBKbGj7zgzSIizgJbFv/1cwW0RAU2Lu8yNMIEXMAjMZJR4e2sza xcgB1PGaUeIzJ0gNm4CRxNkPP9lAbF4Be4md9+axg9gsAioSTZtWMYHYogIREp0r57NA1AhK nJz5BMzmFHCWuH5vLSuIzSwQJjH9bzuULS5x68l8Joh3lCUWtCxihHhHW2L63PssExiFZyEZ NQtJ+ywk7RC2hcTM+ecZIWx5ie1v5zBD2BoSrXPmskPYihJTuh+yL2BkX8UoWpxanJSbbmSk l1qUmVxcnJ+nl5dasokRGH0Ht/w22MH48rnjIUYBDkYlHt45nvOihFgTy4orcw8xSnAwK4nw RugDhXhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTCar8rd deMG+9WbX9qF/1969e1xw99vvi4H7vcsKI8+avCu5fT3SZUqG1gSflzd6HTeZtrGbU3Hw9Wk FPMUlrA9Pu4tWjDXkjfddn8/84F5wg4qcu9+RYY5/lOaepxRV0vmn5+Yu9rX+MjdssbbXRtn lNbW7f0eb1679VGfxfuqtEyBbQ3/rVuUWIozEg21mIuKEwHuxLk7ugIAAA== Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 08:47:40 -0000 --------------19287F3361849C3197F93AE2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Fer, On 06.03.2018 10:36, Fernando Gont wrote: > [RFCXXXX] represents this document. > > Hex Value Binary Value > act chg rest Description Reference > --------- --- --- ------- ----------------- ---------- > 0x23 00 1 00011 RPL Option [RFCXXXX] > 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] > > > SO, while you don't say that elsewhere, it would seem to me that you > *are* deprecating it? Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not the option, so what about to say: Something like: " This option was originally specified in [RFC6553 ]. [I-D.ietf-roll-useofrplinfo ] updates the registration made in [RFC6553 ] Destination Options and Hop-by-Hop Options registry from 0x63 to 0x23." or " This option was originally specified in [RFC6553 ]. The value of 0x63 has been deprecated by [I-D.ietf-roll-useofrplinfo ], which proposes a new value (0x23) for the RPL Option." What do you think? Thanks, Ines. > > Thanks! > > Best regards, --------------19287F3361849C3197F93AE2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPHA+SGkgRmVyLDwvcD4KICAg IDxicj4KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMDYuMDMuMjAxOCAx MDozNiwgRmVybmFuZG8gR29udAogICAgICB3cm90ZTo8YnI+CiAgICA8L2Rpdj4KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiCiAgICAgIGNpdGU9Im1pZDo1ZWZmOGE0Yy1mNzgwLWFk ZmItMTdhMS1kMmYyZWQ3OTMwMDBAc2k2bmV0d29ya3MuY29tIj4KICAgICAgW1JGQ1hYWFhd IHJlcHJlc2VudHMgdGhpcyBkb2N1bWVudC4KICAgICAgPHByZSB3cmFwPSIiPgoKICAgSGV4 IFZhbHVlICBCaW5hcnkgVmFsdWUKICAgICAgICAgICAgICBhY3QgIGNoZyAgcmVzdCAgICAg RGVzY3JpcHRpb24gICAgICAgICAgICAgIFJlZmVyZW5jZQogICAtLS0tLS0tLS0gIC0tLSAg LS0tICAtLS0tLS0tICAtLS0tLS0tLS0tLS0tLS0tLSAgICAgICAtLS0tLS0tLS0tCiAgICAw eDIzICAgICAgMDAgICAgMSAgIDAwMDExICAgUlBMIE9wdGlvbiAgICAgICAgICAgICAgICBb UkZDWFhYWF0KICAgIDB4NjMgICAgICAwMSAgICAxICAgMDAwMTEgICBSUEwgT3B0aW9uKERF UFJFQ0FURUQpIFtSRkM2NTUzXVtSRkNYWFhYXQoKClNPLCB3aGlsZSB5b3UgZG9uJ3Qgc2F5 IHRoYXQgZWxzZXdoZXJlLCBpdCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQgeW91CiphcmUqIGRl cHJlY2F0aW5nIGl0PzwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgQWggT2ssIEkgdW5k ZXJzdGFuZCwgc28geWVzLCB3ZSBkZXByZWNhdGVkIHRoZSB2YWx1ZSBvZiAweDYzLCBidXQK ICAgIG5vdCB0aGUgb3B0aW9uLCBzbyB3aGF0IGFib3V0IHRvIHNheTo8YnI+CiAgICA8YnI+ CiAgICBTb21ldGhpbmcgbGlrZTogIiA8YnI+CiAgICA8cHJlIGNsYXNzPSJuZXdwYWdlIiBz dHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPiBUaGlzIG9wdGlvbiB3 YXMgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2NTUzIiB0aXRsZT0iJnF1b3Q7VGhlIFJvdXRpbmcgUHJvdG9jb2wg Zm9yIExvdy0gUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChSUEwpIE9wdGlvbiBmb3IgQ2Fy cnlpbmcgUlBMIEluZm9ybWF0aW9uIGluIERhdGEtUGxhbmUgRGF0YWdyYW1zJnF1b3Q7Ij5S RkM2NTUzPC9hPl0uIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZy0wNSNyZWYtSS1ELmlldGYtcm9sbC11 c2VvZnJwbGluZm8iPkktRC5pZXRmLXJvbGwtdXNlb2ZycGxpbmZvPC9hPl0gdXBkYXRlcyB0 aGUgcmVnaXN0cmF0aW9uIG1hZGUgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NTUzIiB0aXRsZT0iJnF1b3Q7VGhlIFJvdXRpbmcgUHJvdG9jb2wgZm9y IExvdy0gUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChSUEwpIE9wdGlvbiBmb3IgQ2Fycnlp bmcgUlBMIEluZm9ybWF0aW9uIGluIERhdGEtUGxhbmUgRGF0YWdyYW1zJnF1b3Q7Ij5SRkM2 NTUzPC9hPl0gRGVzdGluYXRpb24KICAgT3B0aW9ucyBhbmQgSG9wLWJ5LUhvcCBPcHRpb25z IHJlZ2lzdHJ5IGZyb20gMHg2MyB0byAweDIzLiIKCm9yCgoiIFRoaXMgb3B0aW9uIHdhcyBv cmlnaW5hbGx5IHNwZWNpZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY1NTMiIHRpdGxlPSImcXVvdDtUaGUgUm91dGluZyBQcm90b2NvbCBmb3Ig TG93LSBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKFJQTCkgT3B0aW9uIGZvciBDYXJyeWlu ZyBSUEwgSW5mb3JtYXRpb24gaW4gRGF0YS1QbGFuZSBEYXRhZ3JhbXMmcXVvdDsiPlJGQzY1 NTM8L2E+XS4gIFRoZSB2YWx1ZSBvZiAweDYzIGhhcyBiZWVuCiAgIGRlcHJlY2F0ZWQgYnkg WzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2Vj LWlwdjYtZWgtZmlsdGVyaW5nLTA1I3JlZi1JLUQuaWV0Zi1yb2xsLXVzZW9mcnBsaW5mbyI+ SS1ELmlldGYtcm9sbC11c2VvZnJwbGluZm88L2E+XSwgd2hpY2ggcHJvcG9zZXMgYSBuZXcg dmFsdWUgKDB4MjMpIGZvciB0aGUgUlBMIE9wdGlvbi4iIAoKV2hhdCBkbyB5b3UgdGhpbms/ CgpUaGFua3MsCgpJbmVzLgo8L3ByZT4KICAgIDxicj4KICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiCiAgICAgIGNpdGU9Im1pZDo1ZWZmOGE0Yy1mNzgwLWFkZmItMTdhMS1kMmYyZWQ3 OTMwMDBAc2k2bmV0d29ya3MuY29tIj4KICAgICAgPHByZSB3cmFwPSIiPgoKVGhhbmtzIQoK QmVzdCByZWdhcmRzLAo8L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIDxicj4KICA8L2Jv ZHk+CjwvaHRtbD4K --------------19287F3361849C3197F93AE2-- From nobody Tue Mar 6 02:55:18 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A31127369 for ; Tue, 6 Mar 2018 02:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 tiVjjGP2lRBF for ; Tue, 6 Mar 2018 02:55:16 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 0D762126CF6 for ; Tue, 6 Mar 2018 02:55:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9F24DAF; Tue, 6 Mar 2018 11:55:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1520333713; bh=mUCSJ/ctKVGgSKVhLb0WRkZt/na2dN+SYUIA/mcm4fs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BbLXr5npPIv6U8g1katG8GfCdTjbzM/uEqkjYQjUBrbNBcVVnCvLLEemJDyvWNwDa 2zlsfcdEJtWIQTtXEFn/5s3Gq69vddaa9DCZ6qCYlTLwWargPBrCZ/K/h52eHzcFRd gNj0nAojCD+YRM98Vsy9h7yn4LvVY0aLoDgfB1cE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9D7D59F; Tue, 6 Mar 2018 11:55:13 +0100 (CET) Date: Tue, 6 Mar 2018 11:55:13 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont cc: opsec@ietf.org In-Reply-To: <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> Message-ID: References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 10:55:17 -0000 On Mon, 5 Mar 2018, Fernando Gont wrote: > Folks, > > This rev is meant to address your feedback regarding opt 0x23 > (draft-ietf-roll-useofrplinfo). > > Please do let us know if your concerns have been addressed. (re-)Read document in its entirety and this is what came to mind: 3.4.1.4, I've made this error (at least) once, can we have a link and short explanation what a "jumbogram" is? Just so people (like me) don't get them mixed up with jumbo frame? (I realise this is in 4.3.3, but adding a link here might still help) 3.5. Can we add a "(yet)" as in "have not (yet) been assigned" ? 3.5.4 The second paragraph is really important, can we emphasise this a bit more? Or even break it out into a separate item in the list? 3.5.5 What about adding a sentence that devices should have configuration option to allow EHs based on codepoints so that older software can be made to allow EHs that are not known to that software at the point of compile? Also applies to 4.4.4 4.3.2.5 here it says "should not discard" and in other items it says "should permit". Would help if this is done in the same way throughout the document? I just noticed that a lot of the paragraph headers contain the word "Blocked". This is first mentioned in 3.4.1.4 and it's never mentioned earlier in the document together with what "discarded", "filtered", "rejected" means. 4.4.5 what does "enterprise" mean here? Perhaps another term can be used, such as "very security conscious" or something like that? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 6 05:11:33 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCA1267BB for ; Tue, 6 Mar 2018 05:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Buc_zuTqIdju for ; Tue, 6 Mar 2018 05:11:30 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF3C127775 for ; Tue, 6 Mar 2018 05:11:29 -0800 (PST) Received: from [192.168.3.68] (unknown [186.138.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3A5D286373; Tue, 6 Mar 2018 14:11:23 +0100 (CET) To: Ines Robles Cc: Ines Robles , "C. M. Heard" , "Pascal Thubert (pthubert)" , opsec@ietf.org References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> <5eff8a4c-f780-adfb-17a1-d2f2ed793000@si6networks.com> <31f6072e-0819-446f-7510-7bb3d8b7f811@ericsson.com> From: Fernando Gont Message-ID: <92ed585c-fdcb-895c-4767-486c7f80ec9d@si6networks.com> Date: Tue, 6 Mar 2018 06:00:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <31f6072e-0819-446f-7510-7bb3d8b7f811@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 13:11:32 -0000 On 03/06/2018 05:47 AM, Ines Robles wrote: > Hi Fer, > > > On 06.03.2018 10:36, Fernando Gont wrote: >> [RFCXXXX] represents this document. >> >> Hex Value Binary Value >> act chg rest Description Reference >> --------- --- --- ------- ----------------- ---------- >> 0x23 00 1 00011 RPL Option [RFCXXXX] >> 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] >> >> >> SO, while you don't say that elsewhere, it would seem to me that you >> *are* deprecating it? > Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not > the option, so what about to say: > > Something like: " > > This option was originally specified in [RFC6553 ]. [I-D.ietf-roll-useofrplinfo > ] updates the registration made in [RFC6553 ] Destination > Options and Hop-by-Hop Options registry from 0x63 to 0x23." > > or > > " This option was originally specified in [RFC6553 ]. The value of 0x63 has been > deprecated by [I-D.ietf-roll-useofrplinfo > ], which proposes a new value (0x23) for the RPL Option." I like this second option. But will say "specifies" (rather than "proposes"), since by the time this doc is published, I-D.ietf-roll-useofrplinfo whould have been published already. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 6 05:16:08 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456F127735 for ; Tue, 6 Mar 2018 05:16:06 -0800 (PST) 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=googlemail.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 cQGJnR7CnfPe for ; Tue, 6 Mar 2018 05:16:00 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 CD6941276AF for ; Tue, 6 Mar 2018 05:15:59 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g21so21976016ioj.5 for ; Tue, 06 Mar 2018 05:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MnjcQCQh2qKbbGRGv8aVFdhHZIEbBNhDxrlNkEv5vio=; b=fodzqjPcDVyhKwkUyJNhVKMMGizqA4V1FbRPuXkUh7/Yg0n0jts8f23GK844jYffio FCxwOSvKAmZkpNhQ+5oXojC0hGeRDwJUaYu/jGbgcWuXaTy7Ldy6zrJG1inEdJ6QnIvx Y9hA4oCt4ZbUO1eXKP8Y9jQtmLmKx/GSsHDq2bUM6CzIeOhKuuw6gXegIT+VM0G2NqNF VLxFYXLqBEIdUWcuS0fpygXT9SsC9CZihfkV0cc/FKqpGgd3/cYquJaQa8sdF4V5nw2q /driHAHmWMOi3+yzhMKaxF/PEtUvZMTU4lfenR0lOdIzgZBrbW6nqOd3BTZCDR7wyQ4a 5u2g== 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=MnjcQCQh2qKbbGRGv8aVFdhHZIEbBNhDxrlNkEv5vio=; b=KbfJbyWzqb/Wy3UX2jgkZ+cafufdkpbTRq6vmaWv+49yYWKNpqiHyFGiK1su0JKy6V gVBgsZzFTeph22PWh7Gz1pfAJjtKup9+wjD/cASraYuwlB2vd1vpawiLfBRMaLpvUxmZ OA6UAVgi7v47SPagR5UCxF6/H5X5QgND9lKiwXbZljCkuJDm7hpesKm5t9hzgdRF6XcO FcUR7OTkDNdFyHk4GWtNDE5ZoTJN1gh+MNLwQ6pvDyxF/kFhQ8VSV3vBWzdA/xB1xwY6 qOi5Kx3M0s+dYrHlxO2zWhS2Ob2DP6h4jYuSjqqofXmM5LvfNoA2H+iYashUqxoHUn8B Rlow== X-Gm-Message-State: APf1xPA24UXvyauao499p5sNv94JveNknsbvK5rZCWe6XhQACim573rn 0q5wVBCfHex66W7J/oeZ43fSuktJH28MLg9Y/os= X-Google-Smtp-Source: AG47ELvD5oBVpZlQhW6vL681qUwUm/fMeeBDUFNsA4uw29An/GDGjZ9+WOnQEXt4GIxEiqdayA5x9EX4xD9wD8/SbLQ= X-Received: by 10.107.17.20 with SMTP id z20mr21531876ioi.274.1520342158812; Tue, 06 Mar 2018 05:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.140 with HTTP; Tue, 6 Mar 2018 05:15:57 -0800 (PST) Received: by 10.79.201.140 with HTTP; Tue, 6 Mar 2018 05:15:57 -0800 (PST) In-Reply-To: References: <152029270864.12765.1089785466220033128@ietfa.amsl.com> <7e7593b9-c130-5515-ad78-462d0de5e9f4@si6networks.com> <5eff8a4c-f780-adfb-17a1-d2f2ed793000@si6networks.com> <31f6072e-0819-446f-7510-7bb3d8b7f811@ericsson.com> <92ed585c-fdcb-895c-4767-486c7f80ec9d@si6networks.com> From: Ines Robles Date: Tue, 6 Mar 2018 15:15:57 +0200 Message-ID: To: Fernando Gont Cc: MARIA INES ROBLES , "C. M. Heard" , "Pascal Thubert (pthubert)" , opsec@ietf.org Content-Type: multipart/alternative; boundary="001a113eda8a502a4f0566be3e67" Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 13:16:07 -0000 --001a113eda8a502a4f0566be3e67 Content-Type: text/plain; charset="UTF-8" I agree with you Fernando, thanks, ines On Mar 6, 2018 15:11, "Fernando Gont" wrote: On 03/06/2018 05:47 AM, Ines Robles wrote: > Hi Fer, > > > On 06.03.2018 10:36, Fernando Gont wrote: >> [RFCXXXX] represents this document. >> >> Hex Value Binary Value >> act chg rest Description Reference >> --------- --- --- ------- ----------------- ---------- >> 0x23 00 1 00011 RPL Option [RFCXXXX] >> 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] >> >> >> SO, while you don't say that elsewhere, it would seem to me that you >> *are* deprecating it? > Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not > the option, so what about to say: > > Something like: " > > This option was originally specified in [RFC6553 < https://tools.ietf.org/html/rfc6553>]. [I-D.ietf-roll-useofrplinfo > ] updates the registration made in [RFC6553 ] Destination > Options and Hop-by-Hop Options registry from 0x63 to 0x23." > > or > > " This option was originally specified in [RFC6553 < https://tools.ietf.org/html/rfc6553>]. The value of 0x63 has been > deprecated by [I-D.ietf-roll-useofrplinfo > ], which proposes a new value (0x23) for the RPL Option." I like this second option. But will say "specifies" (rather than "proposes"), since by the time this doc is published, I-D.ietf-roll-useofrplinfo whould have been published already. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --001a113eda8a502a4f0566be3e67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with you Fernando,
thanks,
=
ines

On Mar 6, 2018 15:11, "Fernando Gont" <fgont@si6networks.com> wrote:
On= 03/06/2018 05:47 AM, Ines Robles wrote:
> Hi Fer,
>
>
> On 06.03.2018 10:36, Fernando Gont wrote:
>> [RFCXXXX] represents this document.
>>
>>=C2=A0 =C2=A0 Hex Value=C2=A0 Binary Value
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0act=C2=A0 ch= g=C2=A0 rest=C2=A0 =C2=A0 =C2=A0Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Reference
>>=C2=A0 =C2=A0 ---------=C2=A0 ---=C2=A0 ---=C2=A0 -------=C2=A0 ---= --------------=C2=A0 =C2=A0 =C2=A0 =C2=A0----------
>>=C2=A0 =C2=A0 =C2=A00x23=C2=A0 =C2=A0 =C2=A0 00=C2=A0 =C2=A0 1=C2= =A0 =C2=A000011=C2=A0 =C2=A0RPL Option=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [RFCXXXX]
>>=C2=A0 =C2=A0 =C2=A00x63=C2=A0 =C2=A0 =C2=A0 01=C2=A0 =C2=A0 1=C2= =A0 =C2=A000011=C2=A0 =C2=A0RPL Option(DEPRECATED) [RFC6553][RFCXXXX]
>>
>>
>> SO, while you don't say that elsewhere, it would seem to me th= at you
>> *are* deprecating it?
> Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not<= br> > the option, so what about to say:
>
> Something like: "
>
>=C2=A0 This option was originally specified in [RFC6553 <https://tools.ietf.org/html/rfc6553>]. [I-D.ietf-roll-useo= frplinfo
> <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filteri= ng-05#ref-I-D.ietf-roll-useofrplinfo>] updates the registration= made in [RFC6553 <https://tools.ietf.org/html/rfc6553<= /a>>] Destination
>=C2=A0 =C2=A0 Options and Hop-by-Hop Options= registry from 0x63 to 0x23."
>
> or
>
> " This option was originally specified in [RFC6553 <https://tools.ietf.org/html/rfc6553>].=C2=A0 The value of= 0x63 has been
>=C2=A0 =C2=A0 deprecated by [I-D.ietf-roll-useofrplinfo
> <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filteri= ng-05#ref-I-D.ietf-roll-useofrplinfo>], which proposes a new va= lue (0x23) for the RPL Option."

I like this second option. But will say "specifies" (rather than<= br> "proposes"), since by the time this doc is published,
I-D.ietf-roll-useofrplinfo whould have been published already.

Thoughts?

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a113eda8a502a4f0566be3e67-- From nobody Tue Mar 6 09:14:26 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63076120721; Tue, 6 Mar 2018 09:14:24 -0800 (PST) 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, 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 hwu_aqJDxafZ; Tue, 6 Mar 2018 09:14:22 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0449E12420B; Tue, 6 Mar 2018 09:14:21 -0800 (PST) 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=tKkUVrBTdMVqV/HFMbmvPV6isAMJbDBQMCNmOXannXU=; b=Bx4X+ChBnn+LEtMjRMbbFdAJaoVWgmlslcPEUA10M0s/JeM0IRoFB7ip+KSY2fxIi25iHnD9tN++sPunA5LCsp1Uq5wPIvpyQTDTnDXsAinLSJZMXBck1ld0bWFfIknaS51c8qj4V2NBCtDYeeJVXPaPuPVi2Grw3Ia+DN1Te1E= Received: from BYAPR09MB2773.namprd09.prod.outlook.com (52.135.224.26) by BYAPR09MB2775.namprd09.prod.outlook.com (52.135.224.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 17:14:19 +0000 Received: from BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::d015:9eb2:757:ba95]) by BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::d015:9eb2:757:ba95%13]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 17:14:19 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "opsec@ietf.org" CC: "opsec-chairs@ietf.org" , GROW WG Thread-Topic: New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt Thread-Index: AQHTtNhsjry+RREQGUiWmVtSQDaqAKPDYzei Date: Tue, 6 Mar 2018 17:14:19 +0000 Message-ID: References: <152029196185.12856.17191127990460094784.idtracker@ietfa.amsl.com> In-Reply-To: <152029196185.12856.17191127990460094784.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [71.255.240.48] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR09MB2775; 7:MuQme83/4GSW1IZlv4nb51z8oIpuoVKIMDzifllqKmISZDLWwtNsECj2KAO+2UjgphRZWInKQywCst92HOKu2pa/+pt+YxmVW26ChOfwVc8HTx7fyZMyuAENrGpIY98Ax5UXP2tA77Zrqwo3A/VZEjRznR+b05yaw044mjHGaTg9AI3VocNYdUCLYGKjpjNxCONgvyeFGiflFvY4ziBXAJhA6g+uWMhTAVcvsbGc/JzBv32ms82dFmqKy9A4WK7W x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bdfc0251-54a4-484d-5f26-08d58385b2ca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR09MB2775; x-ms-traffictypediagnostic: BYAPR09MB2775: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(244540007438412); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BYAPR09MB2775; BCL:0; PCL:0; RULEID:; SRVR:BYAPR09MB2775; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(396003)(346002)(376002)(189003)(199004)(377424004)(26005)(6116002)(74316002)(3846002)(54906003)(14454004)(25786009)(102836004)(68736007)(229853002)(305945005)(478600001)(33656002)(15650500001)(316002)(3280700002)(3660700001)(66066001)(2351001)(59450400001)(76176011)(6506007)(2906002)(966005)(5660300001)(106356001)(7736002)(6916009)(2950100002)(99286004)(53546011)(7696005)(53936002)(55016002)(8936002)(5640700003)(105586002)(8666007)(6436002)(4326008)(97736004)(1730700003)(81166006)(8676002)(9686003)(81156014)(6306002)(2501003)(186003)(2900100001)(6246003)(5250100002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR09MB2775; H:BYAPR09MB2773.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: gne+Zro8RuVICeIWbXeAMkqh3LlNje2urJIGB3PQqE6b1mk6IZioTV0marsiHYMIog2tD3hgrPhScEprkfrpQ6N08ztFPr9OcoPWhHwtTUQ/PdVv4recYLzN6d0uTr9zplydRczBKb/IROT7gtOEDCbELrFsxKI3q9bIKqW8x51wix0IP3BelhtyH/JQC+9wyLEp03Hct8FADUhLDnoApHz75VvF9t11ia+ON3OM7o0JW764OykinNsmnXrr45bTK3puEbJzLTaUfzgDYVObE7nn9Gh2R6R/sP8uwrFbSfk9CXJ8nnaGkibr4kFEHFakK0ZCwHF4OdFTGPcYAt8f8w== 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-Network-Message-Id: bdfc0251-54a4-484d-5f26-08d58385b2ca X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 17:14:19.4726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR09MB2775 Archived-At: Subject: Re: [OPSEC] New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 17:14:24 -0000 [Posting on OPSEC and GROW lists. There has been interest in this work in G= ROW also.] We (the authors) have gone through the draft carefully once again=20 and made significant edits/rewrites to carefully address the comments=20 we received in the OPSEC meeting in Prague last summer and to make the draf= t read better. https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03=20 Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-sriram-opsec-urpf-improve= ments-03.txt Now the document specifies the two algorithms clearly:=20 (1) for the not so challenging customer cone scenario (Algorithm A in Secti= on 3.1.1); and (2) for the challenging customer cone scenario (Algorithm B in Section 3.4)= . Also, Section 3.6 (Summary of Recommendations) is new. We've requested the chairs for a slot in OPSEC meeting in London to give an= update. We look forward to additional comments/discussion on the list anytime, and also in person in London.=20 Thanks. Sriram ________________________________________ From: internet-drafts@ietf.org Sent: Monday, March 5, 2018 6:19 PM To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Jeffrey Haas Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-= 03.txt A new version of I-D, draft-sriram-opsec-urpf-improvements-03.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-sriram-opsec-urpf-improvements Revision: 03 Title: Enhanced Feasible-Path Unicast Reverse Path Filtering Document date: 2018-03-05 Group: Individual Submission Pages: 15 https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03=20 Abstract: This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) [BCP84] for source address validation (SAV) [BCP38]. The strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two [BCP84]. However, as shown in this draft, the existing feasible-path uRPF still has short comings. This document describes an enhanced feasible-path uRPF technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF. It can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques. From nobody Thu Mar 8 08:35:15 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A01272E1 for ; Thu, 8 Mar 2018 08:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFpgpsjHXlgc for ; Thu, 8 Mar 2018 08:35:12 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 56819127137 for ; Thu, 8 Mar 2018 08:35:12 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w28GVFvM001893 for ; Thu, 8 Mar 2018 08:35:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=SDhHruGFL5mIOdYLS6JRExdcQRLAad5n3tvQxodrYKQ=; b=Frs6ZWcY7DkSfDD/WKWeYOfJ6kgf2vU2AujypGWVjB5hXOe74HNr/lbQfS8c8vGeL9nS xdzYOdDFupgzGFiTL9gP7vhyvd3WMLQm+noorqGxPv8U5GyLvM1ainYM5xS5MIKlOFjp tqHfD+LXkSOaczLp4+6aPjJGsaf0ia37HwN4+lgkm4h63Ec78vam/IVe+e/L4UgwKrr1 MFgvJUku78Q9wRQliz3pMqrE65Q5UCG7eV4GYTI75hMxtzREjOhsSa1U4shudO2denfl K5APGzj0s5ftFCK44OdCjoL/0nNFyXsGCnhJFocj6DnsFoqzvbLLAz808pK0ZTUMO4XH XA== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0b-00273201.pphosted.com with ESMTP id 2gk8s280b3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Mar 2018 08:35:10 -0800 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com (10.163.227.23) by SN1PR0501MB1712.namprd05.prod.outlook.com (10.163.130.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Thu, 8 Mar 2018 16:35:08 +0000 Received: from SN1PR0501MB2062.namprd05.prod.outlook.com ([fe80::7d59:beeb:5f68:c714]) by SN1PR0501MB2062.namprd05.prod.outlook.com ([fe80::7d59:beeb:5f68:c714%4]) with mapi id 15.20.0567.012; Thu, 8 Mar 2018 16:35:08 +0000 From: Ron Bonica To: "opsec@ietf.org" Thread-Topic: Agenda Thread-Index: AdO2+xtCwIcuUpN5QU+MbeyRIi9VRw== Date: Thu, 8 Mar 2018 16:35:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1712; 7:rFLM+MRRPpUW6f2F2TvB526UDICv07JFBVZJqhM8hwR/Ynyuar0ixG4OMcg8kCsv6VXeIB5eWxNzmxfKveSEhH6vD2aDk8iJdbM48HGYrp9TDIbAA8Ckd4ml5J+7r6u+7wkPCarU4YABoFAOVq08JDWAMjpVvR5hau93vSdKZuJ+QSL75vU6/1c/AD7qjwTPO/LRSBCddb957BPQg5LBlomIFUUdp1H+M4AQ5SvoDMk7fKmajcNPShfE1xlyRjYr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c870a941-11dc-4c80-7f64-08d585128e35 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN1PR0501MB1712; x-ms-traffictypediagnostic: SN1PR0501MB1712: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231220)(944501244)(52105095)(93006095)(93001095)(6055026)(6041288)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:SN1PR0501MB1712; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1712; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(39380400002)(396003)(376002)(189003)(199004)(81166006)(55016002)(1730700003)(3480700004)(6916009)(86362001)(6116002)(8676002)(2351001)(9686003)(3846002)(2906002)(6436002)(5640700003)(81156014)(106356001)(8936002)(99286004)(102836004)(7696005)(68736007)(33656002)(74316002)(53936002)(3280700002)(2900100001)(478600001)(316002)(25786009)(7736002)(305945005)(105586002)(5660300001)(5250100002)(7116003)(14454004)(2501003)(186003)(97736004)(558084003)(66066001)(221733001)(3660700001)(6506007)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1712; H:SN1PR0501MB2062.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5n52Ll49UF/BdpoqcvsDSO/heKLRQ1Zebegsgac/hy7h0i3/76QLzidiFpwPhpxNT5qBcW196S1CfiAGl3DFf58IyPpoCSJWMKdKMggsuncDBq2dkKv4SFE4mNTpe9oixdIScNOe3CSiAJegsiTuqSwiN+QiBNq+HSkbxEpmpXZlDKRr+s6dhRFf3zWLwXAyg5+MZIHeO6cNNJt8WJDzqxeb5txRmhejiStqyE3mHJB4oIDglYQljwgbKoiXCQIwvWkaWi4IzNDHHx5oadvVT9xg9fmTI2OCeXCSjuI0sbaam/cgwSZNNFHlgjdeZ42yw+wBRSfm30DLoYh0N1FUSQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c870a941-11dc-4c80-7f64-08d585128e35 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 16:35:08.3938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1712 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=354 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803080190 Archived-At: Subject: [OPSEC] Agenda X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 16:35:14 -0000 Folks, I have posted an agenda for IETF 101. If you think that you should be on th= e agenda, please take a look at it to make sure that you haven't been dropp= ed. Also, we are looking for note takers and jabber scribes. Volunteers will be= richly rewarded. Ron From nobody Thu Mar 8 11:42:12 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D551270AC; Thu, 8 Mar 2018 11:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 m4diQUIyEmdm; Thu, 8 Mar 2018 11:42:08 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 6C081124BFA; Thu, 8 Mar 2018 11:42:05 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id q27so2616383pgn.8; Thu, 08 Mar 2018 11:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h4dMh84JXdrW50zgRlCOgATdnXQ4BQ2bFwiHo5rjUWk=; b=gV6XCs50eBiB/Bwfy6DlL4ajuA9Uu7MrijS2Wcl/4YwjCLdvXfNKJVlcGBhQI2v2P7 jaMawXj3omCp82ZrothRG55yCalrXDOHPN8A5RG7+Q46Xp/SumSpZt9pm9RBCHWpj3xV 6p9o9AbO2bRmRm36wZgmUeFiO5xxGhSpsAqgru3yKe/Vk7Y97Wk//Yd1KvAGxKDeidEV qHZySPDCe2Qz9P7UZYiOD/uSBcdyKp/WjMS2v4H9hth8FNqJW8y1lk0nwxrAaA83kAOX xEiQhYHa25kOPrKj5jMEA2+qoSFAZ0Kh71bUtKVvGWZDGN5cZohOTHPoCeo/fDDGQxSj QS2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h4dMh84JXdrW50zgRlCOgATdnXQ4BQ2bFwiHo5rjUWk=; b=E4XR8DyfqME8Hh91YLBXsDt+IxNVprraelsx5EfB07CsREbfzrMUpuD5GNZXMXPE6s WBC46eaN81OBgrpqSyMpcsyH906s+8zuWSVoq9nHzHGV1JQQmusANSCd2gX/v7TBfuAR GIr6tldrD24qR4NuSBrww6NrS6nhS4hf9pAx4qQOYt7X+E1qrOpGck6U4wEYgzVBJJoL TvzE+Rki2sxeyioMoh0yfHJTC+NMEyGkq1RDx03L45Lz0IBeiLahj5hnVh0zASdiQ31x vKOntLvqmh2pyXZNbJRCY1y+r0bReVcCGLWT/mjhCUPklWqslq4oIOZduh1RPziB+H1B Rs6g== X-Gm-Message-State: APf1xPBQMVKY0OL2ycA8MnDkz7PTmY5dmkvGDNa21hn65kLiyzchKOUe q/2YAPICtg44N2vZ0OYT8EyYad4c X-Google-Smtp-Source: AG47ELvW+2CZfRenEhi27ifhBaKd21UlhKSLJnI9bc7N0xrFnYLupiTDnM4MIAMcALyNvX7JnxQAKA== X-Received: by 10.101.83.140 with SMTP id x12mr21429817pgq.288.1520538124781; Thu, 08 Mar 2018 11:42:04 -0800 (PST) Received: from [192.168.43.75] ([118.148.220.220]) by smtp.gmail.com with ESMTPSA id r1sm22183847pgq.41.2018.03.08.11.42.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 11:42:03 -0800 (PST) Sender: Brian Carpenter To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , "v6ops@ietf.org WG" Cc: "draft-ietf-opsec-v6.authors@ietf.org" References: From: Brian E Carpenter Message-ID: <733d8fa5-eb9c-23ec-5beb-81d17bd87a24@gmail.com> Date: Fri, 9 Mar 2018 08:30:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [v6ops] What is new in draft-ietf-opsec-v6-13.txt ? X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:42:10 -0000 Eric, On 02/03/2018 02:08, Eric Vyncke (evyncke) wrote: > There are a lot of changes in the -13 version, many minor and a couple of bigger ones (such the ULA section). A new author, Enno Rey, has joined the team and has provided a tremendous amount of suggestions/changes. We also have acted on the comments from Ole Troan, Ron Bonnica, Bernie Volz, Fernando Gont and Erik Kline. > > As usual you can compare the versions with: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-13.txt > > The authors will welcome reviews and comments especially on the new section 2.1.2 (Use of ULAs): this 'ugly' topic needs to be in this document and no author wants to recommend it obviously ;-) I don't see anything ugly in the new text of 2.1.2; it is neutral and accurate. (There are specialised use cases for ULAs such as draft-ietf-anima-autonomic-control-plane, but I don't think it's necessary to mention them here.) > One open point is what to do with 'mostly obsolete' tunneling such as Teredo and 6to4 ? Ole wants to remove those sections completely but the authors feel that we need to keep them to be exhaustive. I agree with the authors. Also, you say: "Teredo is now mostly never used and it is no more automated in most environment, so, it is less of a threat." I was amazed recently to discover that this statement is untrue. I refer to fully updated Windows 10 Home laptops (two of them) which came up with an active Teredo interface that I had to disable. Actually, such a statement is more true of 6to4 today, which I think nobody configures by default. > Same for the CGN (NAT444) section, not really an IPv6 topic, but an important related-one and the document is in OPSEC WG (which is protocol version agnostic). However, the scope of the draft is "IPv6 Networks" so this really does seem out of scope to me. Brian From nobody Wed Mar 21 09:47:18 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181C127775 for ; Wed, 21 Mar 2018 09:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GdeVvmoXRAw for ; Wed, 21 Mar 2018 09:47:15 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1038A126CC7 for ; Wed, 21 Mar 2018 09:47:15 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7719528B0043 for ; Wed, 21 Mar 2018 12:47:14 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5D8401F804E; Wed, 21 Mar 2018 12:47:14 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 21 Mar 2018 12:47:12 -0400 Cc: Sandra Murphy To: opsec@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [OPSEC] some questions about the blockchain draft presented at IETF 101 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 16:47:17 -0000 These questions were too long to ask the jabber scribe to relay. At the = scribe=E2=80=99s request, I summarized for the meeting, and promised a = fuller version. (Lucky you.) And then question time was scraped. Oh, = well. So here=E2=80=99s the full version. Questions, then comments Questions about some parts of the draft: 6.1.2. Multi-signature transactions the holder of the block of addresses must trust the owners of the keys participating in the multi-signature transaction. Since participants can generate their own keys, does this allow for = sybil attacks - generating new =E2=80=9Cowners of the keys=E2=80=9D in = order to make a multi-signature succeed? 6.1.3. Revocation transaction accepting the revocation transaction automatically when issued by the accepted authority Does this re-introduce a centralized authority into the system? Comments on certain statements made in the draft, and the relationship = to IP address allocation and use: =E2=80=9CCannot be assigned to two entities at the same time.=E2=80=9D The use of IP addresses shows shared authority over address space - more = than one entity has authority over IP address space. I=E2=80=99m not = sure how that works in blockchain. Example: If an ISP holding a /16 sub-delegates a /20 to a customer, it = does not give up the ability to announce the /16. Example: RIPE tells its members that they are responsible for their = entire allocation, no matter if they have sub-delegated some of it to a = customer. And they carefully instruct their members how to use the = authorization features of the RIPE database to ensure that they retain = control over resources they have sub delegated. And they have recently = changed the authorization structure to make it possible to delete = objects for resources that were sub-delegated out of resources they = hold. (Note: I=E2=80=99m not a part of the RIPE NCC. RIPE NCC people = present should speak up.) =E2=80=9CAS domains holding large blocks of IP addresses=E2=80=9D There are many organizations that hold IP addresses but do not hold AS = numbers. There are many organization that hold IP addresses and AS = numbers, but have some other ISP originate announcements for them. So = an IP address to AS number mapping or vice versa is not possible or a = fit to the way IP addresses are used. =E2=80=9CThese parties have a reduced incentive in tampering the = blockchain because they would suffer the consequences: an insecure = Internet.=E2=80=9D I don=E2=80=99t see that this agrees with experience. The Internet = impact is sometimes deliberate (those who have deliberately impacted the = routing of someone else=E2=80=99s prefix), sometimes a mistake = (yesterday=E2=80=99s mis-origination of a Univ of Iowa=E2=80=99s = prefix), and sometimes self-serving (spammers' mis-origination of = prefixes for their own gain) =E2=80=94Sandy From nobody Mon Mar 26 01:54:02 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513961205F0 for ; Mon, 26 Mar 2018 01:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zxg-zL55L1Ys for ; Mon, 26 Mar 2018 01:53:59 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482881204DA for ; Mon, 26 Mar 2018 01:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4602; q=dns/txt; s=iport; t=1522054439; x=1523264039; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DJrZyMGZIdzn404Gs+/+PCjI1PBHpPmf0/Dp/nqahNE=; b=G4EFPgFzV1GM2xwj6MOIQ96e5KzWSZ+CTRqfiUsGrrdBmDNJPvAT+Whd Id3LbGPkxe7ZBcWp99Nk3b/4RZTk2zJ2aFpC9YDklUJEhHPv88r4D46Mc XckSkAQu8Dj8x3WZcb9qgxyLXVXY1RRAu/BLnRkZiyN4d+MIYukXt1uj8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AgBttLha/5NdJa1eDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQWFwKAqDUpUNgVOBMpJRggYLGAuBSoMYAhqDXyE2FgECAQE?= =?us-ascii?q?BAQEBAmsohSYCBAEBIRE4AgQEEwIBCA4MAiYCAgIlCxUQAgQBEoUOD6pvgiCIP?= =?us-ascii?q?YIVBYEIhlCBVECBDCIMglmBQYFSAQGBdYJqMIIkA5c/CAKIH4YQjDmPTwIREwG?= =?us-ascii?q?BJAEjBC1AgRJwFToqAYIYgi2NaTpvjxKBFwEB?= X-IronPort-AV: E=Sophos;i="5.48,364,1517875200"; d="scan'208";a="88888105" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2018 08:53:58 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w2Q8rw7F002096 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 08:53:58 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Mar 2018 04:53:57 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 26 Mar 2018 04:53:57 -0400 From: "Eric Vyncke (evyncke)" To: Sandra Murphy , "opsec@ietf.org" , =?utf-8?B?Sm9yZGkgUGFpbGxpc3PDqSBWaWxhbm92YQ==?= Thread-Topic: [OPSEC] some questions about the blockchain draft presented at IETF 101 Thread-Index: AQHTwTRNiA2UuiP3u0KaRJuwWw2lDKPikVyA Date: Mon, 26 Mar 2018 08:53:57 +0000 Message-ID: <76709248-4E6E-4103-8FA4-0CFE58D98922@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.5] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] some questions about the blockchain draft presented at IETF 101 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 08:54:01 -0000 QWRkaW5nIEpvcmRpIHRvIHRoZSByZWNpcGllbnRzIGFzIGhlIGlzIG5vdCBhIE9wc2VjIG1haWxp bmcgbWVtYmVyIEFGQUlLDQoNCi3DqXJpYw0KDQoNCk9uIDIxLzAzLzE4IDE3OjQ3LCAiT1BTRUMg b24gYmVoYWxmIG9mIFNhbmRyYSBNdXJwaHkiIDxvcHNlYy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBzYW5keUB0aXNsYWJzLmNvbT4gd3JvdGU6DQoNCiAgICBUaGVzZSBxdWVzdGlvbnMg d2VyZSB0b28gbG9uZyB0byBhc2sgdGhlIGphYmJlciBzY3JpYmUgdG8gcmVsYXkuICBBdCB0aGUg c2NyaWJl4oCZcyByZXF1ZXN0LCBJIHN1bW1hcml6ZWQgZm9yIHRoZSBtZWV0aW5nLCBhbmQgcHJv bWlzZWQgYSBmdWxsZXIgdmVyc2lvbi4gIChMdWNreSB5b3UuKSAgQW5kIHRoZW4gcXVlc3Rpb24g dGltZSB3YXMgc2NyYXBlZC4gIE9oLCB3ZWxsLg0KICAgIA0KICAgIA0KICAgIA0KICAgIFNvIGhl cmXigJlzIHRoZSBmdWxsIHZlcnNpb24uDQogICAgDQogICAgUXVlc3Rpb25zLCB0aGVuIGNvbW1l bnRzDQogICAgDQogICAgUXVlc3Rpb25zIGFib3V0IHNvbWUgcGFydHMgb2YgdGhlIGRyYWZ0Og0K ICAgIA0KICAgIA0KICAgIDYuMS4yLiAgTXVsdGktc2lnbmF0dXJlIHRyYW5zYWN0aW9ucw0KICAg IA0KICAgICAgIHRoZSBob2xkZXIgb2YgdGhlIGJsb2NrIG9mDQogICAgICAgYWRkcmVzc2VzIG11 c3QgdHJ1c3QgdGhlIG93bmVycyBvZiB0aGUga2V5cyBwYXJ0aWNpcGF0aW5nIGluIHRoZQ0KICAg ICAgIG11bHRpLXNpZ25hdHVyZSB0cmFuc2FjdGlvbi4NCiAgICANCiAgICBTaW5jZSBwYXJ0aWNp cGFudHMgY2FuIGdlbmVyYXRlIHRoZWlyIG93biBrZXlzLCBkb2VzIHRoaXMgYWxsb3cgZm9yIHN5 YmlsIGF0dGFja3MgLSBnZW5lcmF0aW5nIG5ldyDigJxvd25lcnMgb2YgdGhlIGtleXPigJ0gaW4g b3JkZXIgdG8gbWFrZSBhIG11bHRpLXNpZ25hdHVyZSBzdWNjZWVkPw0KICAgIA0KICAgIDYuMS4z LiAgUmV2b2NhdGlvbiB0cmFuc2FjdGlvbg0KICAgIA0KICAgICAgIGFjY2VwdGluZyB0aGUgcmV2 b2NhdGlvbg0KICAgICAgIHRyYW5zYWN0aW9uIGF1dG9tYXRpY2FsbHkgd2hlbiBpc3N1ZWQgYnkg dGhlIGFjY2VwdGVkIGF1dGhvcml0eQ0KICAgIA0KICAgIERvZXMgdGhpcyByZS1pbnRyb2R1Y2Ug YSBjZW50cmFsaXplZCBhdXRob3JpdHkgaW50byB0aGUgc3lzdGVtPw0KICAgIA0KICAgIA0KICAg IA0KICAgIENvbW1lbnRzIG9uIGNlcnRhaW4gc3RhdGVtZW50cyBtYWRlIGluIHRoZSBkcmFmdCwg YW5kIHRoZSByZWxhdGlvbnNoaXAgdG8gSVAgYWRkcmVzcyBhbGxvY2F0aW9uIGFuZCB1c2U6DQog ICAgDQogICAg4oCcQ2Fubm90IGJlIGFzc2lnbmVkIHRvIHR3byBlbnRpdGllcyBhdCB0aGUgc2Ft ZSB0aW1lLuKAnQ0KICAgIA0KICAgIFRoZSB1c2Ugb2YgSVAgYWRkcmVzc2VzIHNob3dzIHNoYXJl ZCBhdXRob3JpdHkgb3ZlciBhZGRyZXNzIHNwYWNlIC0gbW9yZSB0aGFuIG9uZSBlbnRpdHkgaGFz IGF1dGhvcml0eSBvdmVyIElQIGFkZHJlc3Mgc3BhY2UuICBJ4oCZbSBub3Qgc3VyZSBob3cgdGhh dCB3b3JrcyBpbiBibG9ja2NoYWluLg0KICAgIA0KICAgIEV4YW1wbGU6IElmIGFuIElTUCBob2xk aW5nIGEgLzE2IHN1Yi1kZWxlZ2F0ZXMgYSAvMjAgdG8gYSBjdXN0b21lciwgaXQgZG9lcyBub3Qg Z2l2ZSB1cCB0aGUgYWJpbGl0eSB0byBhbm5vdW5jZSB0aGUgLzE2Lg0KICAgIA0KICAgIEV4YW1w bGU6IFJJUEUgdGVsbHMgaXRzIG1lbWJlcnMgdGhhdCB0aGV5IGFyZSByZXNwb25zaWJsZSBmb3Ig dGhlaXIgZW50aXJlIGFsbG9jYXRpb24sIG5vIG1hdHRlciBpZiB0aGV5IGhhdmUgc3ViLWRlbGVn YXRlZCBzb21lIG9mIGl0IHRvIGEgY3VzdG9tZXIuICBBbmQgdGhleSBjYXJlZnVsbHkgaW5zdHJ1 Y3QgdGhlaXIgbWVtYmVycyBob3cgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGZlYXR1cmVzIG9m IHRoZSBSSVBFIGRhdGFiYXNlIHRvIGVuc3VyZSB0aGF0IHRoZXkgcmV0YWluIGNvbnRyb2wgb3Zl ciByZXNvdXJjZXMgdGhleSBoYXZlIHN1YiBkZWxlZ2F0ZWQuICBBbmQgdGhleSBoYXZlIHJlY2Vu dGx5IGNoYW5nZWQgdGhlIGF1dGhvcml6YXRpb24gc3RydWN0dXJlIHRvIG1ha2UgaXQgcG9zc2li bGUgdG8gZGVsZXRlIG9iamVjdHMgZm9yIHJlc291cmNlcyB0aGF0IHdlcmUgc3ViLWRlbGVnYXRl ZCBvdXQgb2YgcmVzb3VyY2VzIHRoZXkgaG9sZC4gIChOb3RlOiBJ4oCZbSBub3QgYSBwYXJ0IG9m IHRoZSBSSVBFIE5DQy4gIFJJUEUgTkNDIHBlb3BsZSBwcmVzZW50IHNob3VsZCBzcGVhayB1cC4p DQogICAgDQogICAg4oCcQVMgZG9tYWlucyBob2xkaW5nIGxhcmdlIGJsb2NrcyBvZiBJUCBhZGRy ZXNzZXPigJ0NCiAgICANCiAgICBUaGVyZSBhcmUgbWFueSBvcmdhbml6YXRpb25zIHRoYXQgaG9s ZCBJUCBhZGRyZXNzZXMgYnV0IGRvIG5vdCBob2xkIEFTIG51bWJlcnMuICBUaGVyZSBhcmUgbWFu eSBvcmdhbml6YXRpb24gdGhhdCBob2xkIElQIGFkZHJlc3NlcyBhbmQgQVMgbnVtYmVycywgYnV0 IGhhdmUgc29tZSBvdGhlciBJU1Agb3JpZ2luYXRlIGFubm91bmNlbWVudHMgZm9yIHRoZW0uICBT byBhbiBJUCBhZGRyZXNzIHRvIEFTIG51bWJlciBtYXBwaW5nIG9yIHZpY2UgdmVyc2EgaXMgbm90 IHBvc3NpYmxlIG9yIGEgZml0IHRvIHRoZSB3YXkgSVAgYWRkcmVzc2VzIGFyZSB1c2VkLg0KICAg IA0KICAgIOKAnFRoZXNlIHBhcnRpZXMgaGF2ZSBhIHJlZHVjZWQgaW5jZW50aXZlIGluIHRhbXBl cmluZyB0aGUgYmxvY2tjaGFpbiBiZWNhdXNlIHRoZXkgd291bGQgc3VmZmVyIHRoZSBjb25zZXF1 ZW5jZXM6IGFuIGluc2VjdXJlIEludGVybmV0LuKAnQ0KICAgIA0KICAgIEkgZG9u4oCZdCBzZWUg dGhhdCB0aGlzIGFncmVlcyB3aXRoIGV4cGVyaWVuY2UuICBUaGUgSW50ZXJuZXQgaW1wYWN0IGlz IHNvbWV0aW1lcyBkZWxpYmVyYXRlICh0aG9zZSB3aG8gaGF2ZSBkZWxpYmVyYXRlbHkgaW1wYWN0 ZWQgdGhlIHJvdXRpbmcgb2Ygc29tZW9uZSBlbHNl4oCZcyBwcmVmaXgpLCBzb21ldGltZXMgYSBt aXN0YWtlICh5ZXN0ZXJkYXnigJlzIG1pcy1vcmlnaW5hdGlvbiBvZiBhIFVuaXYgb2YgSW93YeKA mXMgcHJlZml4KSwgYW5kIHNvbWV0aW1lcyBzZWxmLXNlcnZpbmcgKHNwYW1tZXJzJyBtaXMtb3Jp Z2luYXRpb24gb2YgcHJlZml4ZXMgZm9yIHRoZWlyIG93biBnYWluKQ0KICAgIA0KICAgIOKAlFNh bmR5DQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBPUFNFQyBtYWlsaW5nIGxpc3QNCiAgICBPUFNFQ0BpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCiAgICANCg0K From nobody Wed Mar 28 01:05:09 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C58412426E for ; Wed, 28 Mar 2018 01:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.8 X-Spam-Level: X-Spam-Status: No, score=-6.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: SERVFAIL)" 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 N1HBJ7EWqpmw for ; Wed, 28 Mar 2018 01:05:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378A21200C1 for ; Wed, 28 Mar 2018 01:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1522224304; x=1523433904; h=from:to:subject:date:message-id:mime-version; bh=wC28caeEvbJzgQIXWlFUAO6B1fDp4VZqkNrA57bqQeA=; b=EVixi56pT/2mQL2AABWf/KqsXpwXkBYzs5nNhyQwhtSWnd1fZn6EKpfS l/jVBgeFMerbsqHA9Wnu3lf3LSvMA1WGUegoxuMuAhQyjTYQ2hXLcmCmF zoPFYyp20LrvAaFJicv5bHALO8asmH+3sp5o5YkqYXzbuvCvAQLtjSLkQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwCQS7ta/40NJK1dGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJNdGFvMoNSlQKBU4EwjWeGXQsjhH2DbSE4FAECAQEBAQEBAms?= =?us-ascii?q?dC4VPSx0BDD4CBDAnBIQ9ZA+rQYIcH4Q2g3aCJAWHWIFUP4EuDIQXgVACA4R?= =?us-ascii?q?ZMIIkApczCAKBMoQdiFeMMYIdhnSGPwIREwGBJAEzIYFScBU6KgGCGYIrjiG?= =?us-ascii?q?PdIEXAQE?= X-IronPort-AV: E=Sophos; i="5.48,370,1517875200"; d="scan'208,217"; a="90531153" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2018 08:05:03 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w2S8537R031559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Mar 2018 08:05:03 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 28 Mar 2018 04:05:02 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 28 Mar 2018 04:05:02 -0400 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" Thread-Topic: Minutes of OPSEC WG @ IETF-101 uploaded, comments are welcome Thread-Index: AQHTxmt5qToZ8jYSt0u6GCieY5qM0g== Date: Wed, 28 Mar 2018 08:05:02 +0000 Message-ID: <53FBE807-5596-43F4-A2FE-43B961F4E435@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.5] Content-Type: multipart/alternative; boundary="_000_53FBE807559643F4A2FE43B961F4E435ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [OPSEC] Minutes of OPSEC WG @ IETF-101 uploaded, comments are welcome X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 08:05:08 -0000 --_000_53FBE807559643F4A2FE43B961F4E435ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3VyIHByZXZpb3VzIGNvLWNoYWlyLCBHdW50ZXIgVmFuZGV2ZWxkZSwgaGFkIGtpbmRseSBhY2Nl cHRlZCB0byB0YWtlIHRoZSBtaW51dGVzIGR1cmluZyBvdXIgV0cgbWVldGluZyBsYXN0IHdlZWsu DQoNCkhpcyBtaW51dGVzIGFyZSB1cGxvYWRlZCwgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgY29ycmVj dGlvbnMgYXMgdXN1YWwuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAx L21hdGVyaWFscy9taW51dGVzLTEwMS1vcHNlYy0wMQ0KDQpWaWRlbyBpcyBhbHNvIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8veW91dHUuYmUvSnZRbFU2aGxicEUNCg0KU2VlIHlvdSBzb29uIG9uIHRo ZSBtYWlsaW5nIGxpc3Qgb3IgaW4gTW9udHJlYWwNCg0KLcOpcmljICYgLXJvbg0KDQo= --_000_53FBE807559643F4A2FE43B961F4E435ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <47942682E907B54B8E68B7B3F6E10271@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ T3VyIHByZXZpb3VzIGNvLWNoYWlyLCBHdW50ZXIgVmFuZGV2ZWxkZSwgaGFkIGtpbmRseSBhY2Nl cHRlZCB0byB0YWtlIHRoZSBtaW51dGVzIGR1cmluZyBvdXIgV0cgbWVldGluZyBsYXN0IHdlZWsu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaXMgbWludXRlcyBh cmUgdXBsb2FkZWQsIGZlZWwgZnJlZSB0byBzdWdnZXN0IGNvcnJlY3Rpb25zIGFzIHVzdWFsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAxL21hdGVyaWFscy9taW51dGVzLTEwMS1vcHNlYy0wMSI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvbWludXRlcy0xMDEtb3BzZWMtMDE8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5WaWRlbyBpcyBh bHNvIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly95b3V0 dS5iZS9KdlFsVTZobGJwRSI+aHR0cHM6Ly95b3V0dS5iZS9KdlFsVTZobGJwRTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlZSB5b3Ugc29vbiBvbiB0aGUg bWFpbGluZyBsaXN0IG9yIGluIE1vbnRyZWFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4tw6lyaWMgJmFtcDsgLXJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53FBE807559643F4A2FE43B961F4E435ciscocom_-- From nobody Wed Mar 28 12:16:40 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D97127735 for ; Wed, 28 Mar 2018 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BHigWXarAOMV for ; Wed, 28 Mar 2018 12:16:34 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id A4D891275AB for ; Wed, 28 Mar 2018 12:16:33 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w2SJGQY0000364; Wed, 28 Mar 2018 21:16:26 +0200 Received: from [192.168.42.127] (unknown [213.4.180.3]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 2ED824FA; Wed, 28 Mar 2018 21:15:03 +0200 (CEST) From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= To: "Eric Vyncke (evyncke)" , Sandra Murphy , "opsec@ietf.org" , Albert Cabellos References: <76709248-4E6E-4103-8FA4-0CFE58D98922@cisco.com> Message-ID: Date: Wed, 28 Mar 2018 21:14:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <76709248-4E6E-4103-8FA4-0CFE58D98922@cisco.com> Content-Type: multipart/alternative; boundary="------------E2549990A3296C5AA7E5DF5D" Content-Language: en-US Archived-At: Subject: Re: [OPSEC] some questions about the blockchain draft presented at IETF 101 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 19:16:38 -0000 This is a multi-part message in MIME format. --------------E2549990A3296C5AA7E5DF5D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, Éric, thanks for adding me to the discussion. Sandra, your comments are very welcome. Please find some responses inline. Regards, Jordi El 26/03/18 a les 10:53, Eric Vyncke (evyncke) ha escrit: > Adding Jordi to the recipients as he is not a Opsec mailing member AFAIK > > -éric > > > On 21/03/18 17:47, "OPSEC on behalf of Sandra Murphy" wrote: > > These questions were too long to ask the jabber scribe to relay. At the scribe’s request, I summarized for the meeting, and promised a fuller version. (Lucky you.) And then question time was scraped. Oh, well. > > > > So here’s the full version. > > Questions, then comments > > Questions about some parts of the draft: > > > 6.1.2. Multi-signature transactions > > the holder of the block of > addresses must trust the owners of the keys participating in the > multi-signature transaction. > > Since participants can generate their own keys, does this allow for sybil attacks - generating new “owners of the keys” in order to make a multi-signature succeed? Not exactly, only some keys are tied to the multi-signature transaction. If you generate a new key, it is not linked to it so you cannot affect its state. This section needs rewriting, I will update it shortly. > > 6.1.3. Revocation transaction > > accepting the revocation > transaction automatically when issued by the accepted authority > > Does this re-introduce a centralized authority into the system? I agree, this is exactly the tradeoff mentioned in sec. 6.1. An alternative approach could be this one: 1. The registry issues a revocation transaction 2. The holder of the prefix re-signs its prefix to prove it still holds its private key, and keeps the ownership of the prefix. 3. If the prefix holder does not issue the aforementioned transaction in 24h, the registry recovers the prefix. > > > > Comments on certain statements made in the draft, and the relationship to IP address allocation and use: > > “Cannot be assigned to two entities at the same time.” > > The use of IP addresses shows shared authority over address space - more than one entity has authority over IP address space. I’m not sure how that works in blockchain. > > Example: If an ISP holding a /16 sub-delegates a /20 to a customer, it does not give up the ability to announce the /16. > > Example: RIPE tells its members that they are responsible for their entire allocation, no matter if they have sub-delegated some of it to a customer. And they carefully instruct their members how to use the authorization features of the RIPE database to ensure that they retain control over resources they have sub delegated. And they have recently changed the authorization structure to make it possible to delete objects for resources that were sub-delegated out of resources they hold. (Note: I’m not a part of the RIPE NCC. RIPE NCC people present should speak up.) Thanks for the comment. I am not an expert in the mechanics of IP address allocations. However, since blockchains allow for complex management logic, this specificities can be integrated into them, typically in the code that validates new transactions. > > “AS domains holding large blocks of IP addresses” > > There are many organizations that hold IP addresses but do not hold AS numbers. There are many organization that hold IP addresses and AS numbers, but have some other ISP originate announcements for them. So an IP address to AS number mapping or vice versa is not possible or a fit to the way IP addresses are used. The base unit in this blockchain are IP prefixes, so it's not a problem if you don't hold an AS number. In short, if you have more addresses you add more blocks. Again, I will clarify this in the draft. > > “These parties have a reduced incentive in tampering the blockchain because they would suffer the consequences: an insecure Internet.” > > I don’t see that this agrees with experience. The Internet impact is sometimes deliberate (those who have deliberately impacted the routing of someone else’s prefix), sometimes a mistake (yesterday’s mis-origination of a Univ of Iowa’s prefix), and sometimes self-serving (spammers' mis-origination of prefixes for their own gain) I see your point. Here we are making two assumptions. First, that a majority of the players are honest (typically consensus algorithms tolerate up to 1/3 of malicious players). Second, at present we are recording in the blockchain only the binding of IP prefix and AS no., but not BGP announcements, so we are not providing full BGP security. Does this make sense? Thanks again for the comments! Jordi > > —Sandy > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > --------------E2549990A3296C5AA7E5DF5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

Éric, thanks for adding me to the discussion.

Sandra, your comments are very welcome. Please find some responses inline.

Regards,

Jordi


El 26/03/18 a les 10:53, Eric Vyncke (evyncke) ha escrit:
Adding Jordi to the recipients as he is not a Opsec mailing member AFAIK

-éric


On 21/03/18 17:47, "OPSEC on behalf of Sandra Murphy" <opsec-bounces@ietf.org on behalf of sandy@tislabs.com> wrote:

    These questions were too long to ask the jabber scribe to relay.  At the scribe’s request, I summarized for the meeting, and promised a fuller version.  (Lucky you.)  And then question time was scraped.  Oh, well.
    
    
    
    So here’s the full version.
    
    Questions, then comments
    
    Questions about some parts of the draft:
    
    
    6.1.2.  Multi-signature transactions
    
       the holder of the block of
       addresses must trust the owners of the keys participating in the
       multi-signature transaction.
    
    Since participants can generate their own keys, does this allow for sybil attacks - generating new “owners of the keys” in order to make a multi-signature succeed?
Not exactly, only some keys are tied to the multi-signature transaction. If you generate a new key, it is not linked to it so you cannot affect its state. This section needs rewriting, I will update it shortly.
    
    6.1.3.  Revocation transaction
    
       accepting the revocation
       transaction automatically when issued by the accepted authority
    
    Does this re-introduce a centralized authority into the system?
I agree, this is exactly the tradeoff mentioned in sec. 6.1. An alternative approach could be this one:
  1. The registry issues a revocation transaction
  2. The holder of the prefix re-signs its prefix to prove it still holds its private key, and keeps the ownership of the prefix.
  3. If the prefix holder does not issue the aforementioned transaction in 24h, the registry recovers the prefix.
    
    
    
    Comments on certain statements made in the draft, and the relationship to IP address allocation and use:
    
    “Cannot be assigned to two entities at the same time.”
    
    The use of IP addresses shows shared authority over address space - more than one entity has authority over IP address space.  I’m not sure how that works in blockchain.
    
    Example: If an ISP holding a /16 sub-delegates a /20 to a customer, it does not give up the ability to announce the /16.
    
    Example: RIPE tells its members that they are responsible for their entire allocation, no matter if they have sub-delegated some of it to a customer.  And they carefully instruct their members how to use the authorization features of the RIPE database to ensure that they retain control over resources they have sub delegated.  And they have recently changed the authorization structure to make it possible to delete objects for resources that were sub-delegated out of resources they hold.  (Note: I’m not a part of the RIPE NCC.  RIPE NCC people present should speak up.)
Thanks for the comment. I am not an expert in the mechanics of IP address allocations. However, since blockchains allow for complex management logic, this specificities can be integrated into them, typically in the code that validates new transactions.
    
    “AS domains holding large blocks of IP addresses”
    
    There are many organizations that hold IP addresses but do not hold AS numbers.  There are many organization that hold IP addresses and AS numbers, but have some other ISP originate announcements for them.  So an IP address to AS number mapping or vice versa is not possible or a fit to the way IP addresses are used.
The base unit in this blockchain are IP prefixes, so it's not a problem if you don't hold an AS number. In short, if you have more addresses you add more blocks. Again, I will clarify this in the draft.
    
    “These parties have a reduced incentive in tampering the blockchain because they would suffer the consequences: an insecure Internet.”
    
    I don’t see that this agrees with experience.  The Internet impact is sometimes deliberate (those who have deliberately impacted the routing of someone else’s prefix), sometimes a mistake (yesterday’s mis-origination of a Univ of Iowa’s prefix), and sometimes self-serving (spammers' mis-origination of prefixes for their own gain)
I see your point. Here we are making two assumptions. First, that a majority of the players are honest (typically consensus algorithms tolerate up to 1/3 of malicious players). Second, at present we are recording in the blockchain only the binding of IP prefix and AS no., but not BGP announcements, so we are not providing full BGP security. Does this make sense?

Thanks again for the comments!

Jordi
    
    —Sandy
    
    
    _______________________________________________
    OPSEC mailing list
    OPSEC@ietf.org
    https://www.ietf.org/mailman/listinfo/opsec

--------------E2549990A3296C5AA7E5DF5D--