From nobody Thu Nov 2 23:31:45 2017 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 D42C813FC53 for ; Thu, 2 Nov 2017 23:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fdSxLp4H9CZ for ; Thu, 2 Nov 2017 23:31:42 -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 29E4213FC52 for ; Thu, 2 Nov 2017 23:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6172; q=dns/txt; s=iport; t=1509690702; x=1510900302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Npgcc5nnLfnpiD31lLch5AUycUnDYUCCxRKCfn/VQNo=; b=L57Gld1tbSDGsKns6rX8xH522++twbcnAwkqcZWSX8rL4PaIMPcaiWS1 3+uPaT7xurOD+AgypxG05k2ibv5LTNwUVrc9RtXFtvWWUC/av3Lu2DxPT 1RmOFGQtd68xyGaNaQy5GS29fNtWjNCBWxp0PgDC+2pMVViZF5RUZFsy6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAABnDPxZ/5xdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzRkbicHg3aKH48cgXyWRRCBIgNcChgLhRgCGoQ2PxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAwEBIRE6CxACAQgOCgICERUCAgIlCxUQAgQOBYojEKgQgieLE?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4IfggeBU4FpKYMBgz6BDkUXKIJWMII?= =?us-ascii?q?yBaIOAodkjRaCFV+FJIscii2CNIkIAhEZAYE4AR84T4EdehUfKi0BgjYJhFZ3i?= =?us-ascii?q?1SBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,337,1505779200"; d="scan'208";a="26137848" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 06:31:41 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vA36VegX029489 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Nov 2017 06:31:41 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 3 Nov 2017 02:31:39 -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; Fri, 3 Nov 2017 02:31:39 -0400 From: "Eric Vyncke (evyncke)" To: Erik Kline CC: "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-12.txt Thread-Index: AQHTUjtY8t7H4zsiVki/logFKmCPqqMCijGA Date: Fri, 3 Nov 2017 06:31:39 +0000 Message-ID: References: <150939915107.7814.12431141772022433801@ietfa.amsl.com> <05F0E97C-CA5E-465B-A0A6-39134AF55FDB@cisco.com> 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.61.199.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-12.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: Fri, 03 Nov 2017 06:31:44 -0000 RXJpaw0KDQpUaGFua3MgZm9yIHlvdXIgdGltZSBvbiB0aGlzIEktRC4gDQoNCkkgd2lsbCBNZXJp a2UgKHdobyB3cm90ZSB0aGlzIHNlY3Rpb24pIHJlcGx5LCBidXQsIHNwZWFraW5nIGZvciBteXNl bGYgdGhlIGdvYWwgaXMgTk9UIHRvIHJlY29tbWVuZCBVTEEgKyBOUFR2NiA6LU8NCg0KLcOpcmlj DQoNCk9uIDMxLzEwLzE3IDEyOjI3LCAiRXJpayBLbGluZSIgPGVrQGdvb2dsZS5jb20+IHdyb3Rl Og0KDQogICAgSSBzdGlsbCBoYXZlIG9iamVjdGlvbnMgdG8gc2VjdGlvbiAyLjEuMi4gIExldCdz IHRha2UganVzdCB0aGlzIG9uZQ0KICAgIHBhcmFncmFwaCB0byBzdGFydCB3aXRoOg0KICAgIA0K ICAgICIiIg0KICAgICAgIFVMQXMgYXJlIGludGVuZGVkIGZvciBzY2VuYXJpb3Mgd2hlcmUgSVAg YWRkcmVzc2VzIHdpbGwgbm90IGhhdmUNCiAgICAgICBnbG9iYWwgc2NvcGUgc28gdGhleSBzaG91 bGQgbm90IGFwcGVhciBpbiB0aGUgZ2xvYmFsIEJHUCByb3V0aW5nDQogICAgICAgdGFibGUuICBU aGUgaW1wbGljaXQgZXhwZWN0YXRpb24gZnJvbSB0aGUgUkZDIGlzIHRoYXQgYWxsIFVMQXMgd2ls bA0KICAgICAgIGJlIHJhbmRvbWx5IGNyZWF0ZWQgYXMgLzQ4cy4gIEFueSB1c2Ugb2YgVUxBcyB0 aGF0IGFyZSBub3QgY3JlYXRlZCBhcw0KICAgICAgIGEgLzQ4IHZpb2xhdGVzIFJGQzQxOTMgW1JG QzQxOTNdLg0KICAgICIiIg0KICAgIA0KICAgIFRoZSBtb3N0IG9idmlvdXMgcHJvYmxlbXMgaW5j bHVkZToNCiAgICANCiAgICAgICAgWzFdIFVMQSBhZGRyZXNzZXMgaGF2ZSBnbG9iYWwgc2NvcGUg YnV0IGFyZSBub3QgZ3VhcmFudGVlZCB0byBiZQ0KICAgIGdsb2JhbGx5IHJvdXRhYmxlLiAgVGhl IGZpcnN0IHNlbnRlbmNlIGFzIHdyaXR0ZW4gZG9lcyBub3QgY2xlYXJseQ0KICAgIGNvbnZleSB0 aGlzIHN1YnRsZXR5Lg0KICAgIA0KICAgICAgICBbMl0gVGhlIHNlY29uZCBzZW50ZW5jZSBpcyBu b3QgY29ycmVjdC4gIFBzZXVkby1yYW5kb20gYXNzaWdubWVudA0KICAgIGlzIGEgTVVTVCBmb3Ig bG9jYWxseS1hc3NpZ25lZCBnbG9iYWwgSURzLCBmb3Igb25lLg0KICAgIA0KICAgICAgICBbM10g VGhlIGxhc3Qgc2VudGVuY2UgbWlzc2VzIHRoZSBwb2ludDogaXQncyB0aGUgcHJvYmFiaWxpc3Rp Yw0KICAgIGd1YXJhbnRlZSBvZiB1bmlxdWVuZXNzIHRoYXQncyBjcml0aWNhbCwgbm90IGp1c3Qg dGhlICIvNDgtbmVzcyIuDQogICAgDQogICAgT25lIHRoaW5nIHRoYXQgY291bGQgYmUgY2FsbGVk IG91dCBsYXRlciBpbiB0aGlzIHNlY3Rpb24gaXMgdGhlDQogICAgcG90ZW50aWFsIGFjY2lkZW50 YWwgVUxBIGFkZHJlc3MgbGVha2FnZSB2aWEgSUNNUHY2IHJlc3BvbnNlcy4NCiAgICANCiAgICBU aGUgcmVzdCBvZiB0aGUgc2VjdGlvbiBzdGlsbCByZWFkcyB0byBtZSBsaWtlIGFuIG9ibGlxdWUN CiAgICByZWNvbW1lbmRhdGlvbiBmb3IgVUxBcyB3aXRoIE5QVHY2LCBmcmFua2x5LiAgSSBndWVz cyBJIHNob3VsZCBleHBlY3QNCiAgICB0byBkaXNjdXNzIHRoaXMgbW9yZSBpbiBTaW5nYXBvcmUu DQogICAgDQogICAgT24gMzEgT2N0b2JlciAyMDE3IGF0IDA3OjA5LCBFcmljIFZ5bmNrZSAoZXZ5 bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPiB3cm90ZToNCiAgICA+IEl0IGlzIGFuIHVwZGF0ZSB0 byB0YWtlIGludG8gYWNjb3VudCB0aGUgcmV2aWV3IG9mIE1pa2FlbCBBYnJhaGFtc3NvbiBhbmQg VG9iaWFzIEZpZWJpZy4NCiAgICA+DQogICAgPiBTZWUgeW91IGluIFNpbmdhcG9yZSBpZiB5b3Ug cGFydGljaXBhdGUgaW4gdGhlIE9QU0VDIFdHIG1lZXRpbmcgb24gTW9uZGF5IChhZ2VuZGEgcHVi bGlzaGVkIEJUVykNCiAgICA+DQogICAgPiAtw6lyaWMNCiAgICA+DQogICAgPiBPbiAzMC8xMC8x NyAyMjozMiwgIk9QU0VDIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxv cHNlYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+IHdyb3RlOg0KICAgID4NCiAgICA+DQogICAgPiAgICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KICAgID4gICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE9wZXJhdGlvbmFs IFNlY3VyaXR5IENhcGFiaWxpdGllcyBmb3IgSVAgTmV0d29yayBJbmZyYXN0cnVjdHVyZSBXRyBv ZiB0aGUgSUVURi4NCiAgICA+DQogICAgPiAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBP cGVyYXRpb25hbCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBmb3IgSVB2NiBOZXR3b3Jrcw0KICAg ID4gICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRXJpYyBWeW5ja2UNCiAgICA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEtpcmFuIEsuIENoaXR0aW1hbmVuaQ0KICAgID4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVyaWtlIEthZW8NCiAgICA+ICAgICAgICAgRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1vcHNlYy12Ni0xMi50eHQNCiAgICA+ICAgICAgICAg UGFnZXMgICAgICAgICAgIDogNDgNCiAgICA+ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAx Ny0xMC0zMA0KICAgID4NCiAgICA+ICAgICBBYnN0cmFjdDoNCiAgICA+ICAgICAgICBLbm93bGVk Z2UgYW5kIGV4cGVyaWVuY2Ugb24gaG93IHRvIG9wZXJhdGUgSVB2NCBzZWN1cmVseSBpcw0KICAg ID4gICAgICAgIGF2YWlsYWJsZTogd2hldGhlciBpdCBpcyB0aGUgSW50ZXJuZXQgb3IgYW4gZW50 ZXJwcmlzZSBpbnRlcm5hbA0KICAgID4gICAgICAgIG5ldHdvcmsuICBIb3dldmVyLCBJUHY2IHBy ZXNlbnRzIHNvbWUgbmV3IHNlY3VyaXR5IGNoYWxsZW5nZXMuICBSRkMNCiAgICA+ICAgICAgICA0 OTQyIGRlc2NyaWJlcyB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIHRoZSBwcm90b2NvbCBidXQgbmV0 d29yaw0KICAgID4gICAgICAgIG1hbmFnZXJzIGFsc28gbmVlZCBhIG1vcmUgcHJhY3RpY2FsLCBv cGVyYXRpb25zLW1pbmRlZCBkb2N1bWVudCB0bw0KICAgID4gICAgICAgIGVudW1lcmF0ZSBhZHZh bnRhZ2VzIGFuZC9vciBkaXNhZHZhbnRhZ2VzIG9mIGNlcnRhaW4gY2hvaWNlcy4NCiAgICA+DQog ICAgPiAgICAgICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgb3BlcmF0aW9uYWwgc2VjdXJp dHkgaXNzdWVzIGluIGFsbCBwbGFjZXMNCiAgICA+ICAgICAgICBvZiBhIG5ldHdvcmsgKGVudGVy cHJpc2VzLCBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgcmVzaWRlbnRpYWwgdXNlcnMpDQogICAgPiAg ICAgICAgYW5kIHByb3Bvc2VzIHRlY2huaWNhbCBhbmQgcHJvY2VkdXJhbCBtaXRpZ2F0aW9ucyB0 ZWNobmlxdWVzLg0KICAgID4NCiAgICA+DQogICAgPiAgICAgVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPiAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy12Ni8NCiAgICA+DQogICAgPiAgICAg VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgID4gICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2LTEyDQogICAg PiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9w c2VjLXY2LTEyDQogICAgPg0KICAgID4gICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNlYy12Ni0xMg0KICAgID4NCiAgICA+DQogICAgPiAgICAg UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPg0KICAgID4g ICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCiAgICA+ICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgID4N CiAgICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgID4gICAgIE9QU0VDIG1haWxpbmcgbGlzdA0KICAgID4gICAgIE9QU0VDQGlldGYub3Jn DQogICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0K ICAgID4NCiAgICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4gT1BTRUMgbWFpbGluZyBsaXN0DQogICAgPiBPUFNFQ0BpZXRmLm9y Zw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0KICAg IA0KDQo= From nobody Mon Nov 13 01:09:07 2017 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 22F29126B6E for ; Mon, 13 Nov 2017 01:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxa2Rf8AM6_V for ; Mon, 13 Nov 2017 01:09:05 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201F1129483 for ; Mon, 13 Nov 2017 01:09:05 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id l25so2644080uag.8 for ; Mon, 13 Nov 2017 01:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=grdEHcg9I+1iSI6dOa3wSSKS9JbtoR0e8qXo+7x5nk8=; b=PW43vucmte5LHX9d3wUXQfCzw0arPCps3O6bSMWD/N4JQmyNnl9jkkz73lpQ4PiF3w g3Kba3LO4OdHPOxBypFfF46D4OeFBHHyUfLUALKkKBAht0XUfnodcIpbi7Kdo54ds8zc MgtP3+V6OQ3pSEjbuMPFF3t9Rm6787CF0XuvtuwERzb9ftbXz/9afh92NNW9UgF2EA6M OpK+36OmJ1KfwS8ssDILQ3R4QOHCfb1hwniQscgittgQJ6ENXKdFhePrX38lGDw9fbuC woHWCvSiMqdylklWxUWP0zVsW5uQm5cil4brS0ldqXDCNCrOhJY6RsrRxvGu+4p5xD0O v+jg== 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=grdEHcg9I+1iSI6dOa3wSSKS9JbtoR0e8qXo+7x5nk8=; b=YZGxhixjSsJFMwrElOe6sxvxzXm9g/rH6aIsWMRXorczpGQjKRKuyL9tDLysMSR/Zz MK/rFGLUhPE7z/Jx1rn5p/mp4aufl8OgBctnWQX6PuqYE90CcCyi/BBC9i0ARbntze8N /z+O2Yn6LCnPOMs/Ew9+vemi7bXIisCkv2uoKNVNNSxAUsKijf/IrxV99U+Bmezn6zxV cRTrFlMcny+/46Uo08kCZgGjBJNrl7Bko1uJgMqHGOHSbtY45izI2nW/+d4oz7RvkxZ8 48vqsJZieDOMZkQvNm7apnqXBYy81aH32aON9BMN2TySLIeenXefJNJcSmSvlz+ieb3e xD+g== X-Gm-Message-State: AJaThX4iyHmKx6SYvyUBQfd4C9rV4+KBanGyMUlGzTJ5mklWK/u9bN30 kBhmxUrgRnaPgRJUbEmT/EO86yvHAjJ3vaoazJ79ZSF1 X-Google-Smtp-Source: AGs4zMb4AvSJh5ODo5Rt6wDwMRIcr1O2NYi7/r+gcH7YSiFDB8C/GoqMOK8UVSZ2OatEnbgFG8uJYxK0v/B3hDx83wI= X-Received: by 10.176.83.132 with SMTP id k4mr6214443uaa.144.1510564143976; Mon, 13 Nov 2017 01:09:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.59.206 with HTTP; Mon, 13 Nov 2017 01:09:03 -0800 (PST) From: Christopher Morrow Date: Mon, 13 Nov 2017 20:09:03 +1100 Message-ID: To: opsec wg mailing list Content-Type: multipart/alternative; boundary="f403045e3db0365c2c055dd99fe3" Archived-At: Subject: [OPSEC] Comment for: draft-fairhurst-tsvwg-transport-encrypt-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: Mon, 13 Nov 2017 09:09:07 -0000 --f403045e3db0365c2c055dd99fe3 Content-Type: text/plain; charset="UTF-8" If the goal of the draft is to raise awareness that: "things are changing, old tools (tcpdump, etc) are not going to be as useful for network troubleshooting when more of the packet is encrypted" That's a fine goal, but statements in the draft like: " Encryption of the transport layer brings some well-known privacy and security benefits, but also introduces various costs that need to be considered." maybe 'considered' there should be: "planned for" ... There's also this: "Pervasive use of transport header encryption can impact the ways that protocols are designed, standardised, deployed, and operated. The choice of whether future transport protocols encrypt their protocol headers therefore needs to be taken based not solely on security and privacy considerations, but also taking into account the impact on operations, standards, and research." >From an operations perspective it seems that better/different tools is still the end result of these changes. Holding back the tide of better privacy for users in favor of not producing tooling to solve operations problems seems contradictory to a better world for users. --f403045e3db0365c2c055dd99fe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the goal of the draft is to raise awareness that:
= =C2=A0 "things are changing, old tools (tcpdump, etc) are not going to= be as useful for network troubleshooting when more of the packet is encryp= ted"

That's a fine goal, but statements in the = draft like:

" Encryption of the transport layer brings some wel= l-known privacy and
=C2=A0 =C2=A0security benefits, but also intr= oduces various costs that need to be
=C2=A0 =C2=A0considered.&quo= t;

maybe 'considered' there should be: &qu= ot;planned for" ... There's also this:

=C2=A0 &q= uot;Pervasive use of transport header encryption can impact the ways that
=C2=A0 =C2=A0protocols are designed, standardised, deployed, and o= perated.=C2=A0 The
=C2=A0 =C2=A0choice of whether future transpor= t protocols encrypt their protocol
=C2=A0 =C2=A0headers therefore= needs to be taken based not solely on security and
=C2=A0 =C2=A0= privacy considerations, but also taking into account the impact on
=C2=A0 =C2=A0operations, standards, and research."

From an operations perspective it seems that better/different tools= is still the end result of these changes. Holding back the tide of better = privacy for users in favor of not producing tooling to solve operations pro= blems seems contradictory to a better world for users.

=

--f403045e3db0365c2c055dd99fe3-- From nobody Mon Nov 13 01:19:19 2017 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 03B301294E6 for ; Mon, 13 Nov 2017 01:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAn6QvJMrtQP for ; Mon, 13 Nov 2017 01:19:17 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 D7023120713 for ; Mon, 13 Nov 2017 01:19:16 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id p96so13758058wrb.7 for ; Mon, 13 Nov 2017 01:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R3uS48YOITedBtTa4W+5PYh+rjbBC24gpRIbS+8sh1s=; b=wT2YD1CHxRiGEtcsglOCujHrYDxKjE67oz1WZrZHsVMlQE5GTLO7xwR6NOvn4lHO5j klSb1Ztvy72AHBU8EoPTHwwT9e9bPS7L/Evz7RYi9JrJORq9aruhgF9vlA2lq/O+sWuq zl2qspTiZKOBqf10BbeammL49NhvnXKpQoQOcgHEnDKTd3Q1h0IhZyS2oiZj4PnEmD18 5J2BPaKXKdqDRd2cj3cbBq1jocysgmRjHBA0VnrHmnxNuXGMz8sTFZCpHc6GmAp6GAr+ nx97i16sJ1mTO33b5XoSXq3QGT9u/Rn6B812dGlMXKXDA6/WZF3aqylnAtuPxYrpwBe8 gA1Q== 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=R3uS48YOITedBtTa4W+5PYh+rjbBC24gpRIbS+8sh1s=; b=BL/jS3m5l5Lcv05yll2+AvO1vcPhmNsq5R4S8pdoIIsrRpGsIbtFlf5LcpPgb1nzsD XepnFeSVqggi3ZewLeT34s0JB0+e6gta8S2YtmUGGnOEXTRr355gJMCcnqMW9O9MSbHe 3IoEhT5axJfrxTQGvGqPoSJZYtaMCaXBaOSxtJxnCaHrbVzaDG6SRdsq7g8Y/gemtkRH wz7Yr0CPHLhUqt5LQpXLWu8LxRE5UcCjuXcxyKqY2Dirc2lUlsFSG3Djwk8UvPWZJwvr NkRWQ55YjFUKHXGC4aTjAF3rzWpbAE5DJOBJStJfHBdYiSLgge8b78c3W6sQd+Q5VcDC k0QQ== X-Gm-Message-State: AJaThX7AjaEuaDNvboU/KOVfr1c7z0KhVqb3usNHnLK4Ihswe/mhS5kQ QSrVnC016UVgRVf7+ECnv+ywRhsptW0UWd3dIw0vrA== X-Google-Smtp-Source: AGs4zMaynjDfXcP4sROXnf3XHhFlj8l5kyK3NgarOoPIStjRGMPssoGPJtWwFlaEUI81CA0VqFIjMdfLOnKT+C/N/GA= X-Received: by 10.223.133.242 with SMTP id 47mr6938281wru.170.1510564754930; Mon, 13 Nov 2017 01:19:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Mon, 13 Nov 2017 01:18:34 -0800 (PST) In-Reply-To: References: From: Warren Kumari Date: Mon, 13 Nov 2017 17:18:34 +0800 Message-ID: To: Christopher Morrow Cc: opsec wg mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OPSEC] Comment for: draft-fairhurst-tsvwg-transport-encrypt-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: Mon, 13 Nov 2017 09:19:19 -0000 The (very) related document that I had mentioned is: Effect of Pervasive Encryption on Operators draft-mm-wg-effect-encrypt This discusses "current security and network management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable, secure networks." It is trying to just note that some information which operators may had been using becomes unavailable when there is pervasive encryption, and that things like tools / management will need to change as a result. W On Mon, Nov 13, 2017 at 5:09 PM, Christopher Morrow wrote: > If the goal of the draft is to raise awareness that: > "things are changing, old tools (tcpdump, etc) are not going to be as > useful for network troubleshooting when more of the packet is encrypted" > > That's a fine goal, but statements in the draft like: > > " Encryption of the transport layer brings some well-known privacy and > security benefits, but also introduces various costs that need to be > considered." > > maybe 'considered' there should be: "planned for" ... There's also this: > > "Pervasive use of transport header encryption can impact the ways that > protocols are designed, standardised, deployed, and operated. The > choice of whether future transport protocols encrypt their protocol > headers therefore needs to be taken based not solely on security and > privacy considerations, but also taking into account the impact on > operations, standards, and research." > > From an operations perspective it seems that better/different tools is still > the end result of these changes. Holding back the tide of better privacy for > users in favor of not producing tooling to solve operations problems seems > contradictory to a better world for users. > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- 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 Nov 27 13:36:43 2017 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 34A551274D0 for ; Mon, 27 Nov 2017 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 5F86qmaLlQbN for ; Mon, 27 Nov 2017 13:36:40 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0F112702E for ; Mon, 27 Nov 2017 13:36:39 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 72622C6339 for ; Mon, 27 Nov 2017 16:36:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=pGo e+FL6IkRVKZHp7+ncISi7lZE=; b=wTegvwEG34BqnMphXKhNP9tx/bO27aizIGR UNUkM2931ZeslnBdLt3Ou4tP4HNDNI0ogyp+Ddx438CHPAyZ6X42MHQIcEvmZML8 tsU4ErYdED/BMnyFIIXxR2IUvyI/t+bRI9x+L4XSNi81NaTBUgVXCPtxD9W7x63K HsJZzp4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= Wq1vz1ydBr1bfgSFmKj9FK2iY2JUDHcOrOUUtJGskx+ub4AU3tW4ZcYpG1fnWONC nffS1tIz1xiFgvlEBHG5Q+nMnhu5ERfFa6DyUVH/zI9Q59nuMEDnvKuiOqoplqR6 Dytm9qy9P3ipA9dFmK+g3f3pyst3fJ2DQ7b3DUEqQfY= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6ABC5C6338 for ; Mon, 27 Nov 2017 16:36:37 -0500 (EST) Received: from mail-qk0-f170.google.com (unknown [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 0CDD8C6335 for ; Mon, 27 Nov 2017 16:36:37 -0500 (EST) Received: by mail-qk0-f170.google.com with SMTP id f63so34428460qke.8 for ; Mon, 27 Nov 2017 13:36:37 -0800 (PST) X-Gm-Message-State: AJaThX4jY8ARkmlz00BXvuqH1+GTuN859wTOukjRk4+pLo+jMo+ZmySp azC6Pzx7WC1F7IscrywQXi0t2gf0HNk4H/ybySw= X-Google-Smtp-Source: AGs4zMYk5/qcbk8aXLhCB4fvrJzgCSsahLS+eZjAKbTl9O6MTVAGRwetOZ9f0VvGtMJMruToZpoH2dEopmLtCAugHHw= X-Received: by 10.55.153.3 with SMTP id b3mr32262766qke.230.1511818596515; Mon, 27 Nov 2017 13:36:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.86.239 with HTTP; Mon, 27 Nov 2017 13:36:16 -0800 (PST) From: "C. M. Heard" Date: Mon, 27 Nov 2017 13:36:16 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OPSEC Cc: Michael Richardson , Ines Robles , Pascal Thubert Content-Type: multipart/alternative; boundary="94eb2c07d55669035a055efdb20d" X-Pobox-Relay-ID: 0BEECAD6-D3BB-11E7-B4A6-575F0C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: [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: Mon, 27 Nov 2017 21:36:41 -0000 --94eb2c07d55669035a055efdb20d Content-Type: text/plain; charset="UTF-8" Greetings, It seems to me that the option description and filtering advice given in https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4 is not consistent with the revised definition of the RPI option in https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19 which is now in WG last call in ROLL. I have cc:'d the authors of useofrplinfo. Thanks & regards, Mike Heard --94eb2c07d55669035a055efdb20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --94eb2c07d55669035a055efdb20d-- From nobody Mon Nov 27 16:32:46 2017 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 12BA112943C for ; Mon, 27 Nov 2017 16:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Chws1EyIss for ; Mon, 27 Nov 2017 16:32:41 -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 2D79712943A for ; Mon, 27 Nov 2017 16:32:41 -0800 (PST) X-AuditID: c1b4fb30-a25ff70000002554-d8-5a1caea727b3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.8B.09556.7AEAC1A5; Tue, 28 Nov 2017 01:32:39 +0100 (CET) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.352.0; Tue, 28 Nov 2017 01:32:38 +0100 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id DA2314EE5E; Tue, 28 Nov 2017 02:35:23 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 5B28F4E689; Tue, 28 Nov 2017 02:35:23 +0200 (EET) To: "C. M. Heard" , OPSEC CC: Michael Richardson , Pascal Thubert , Fernando Gont References: From: Ines Robles Message-ID: Date: Tue, 28 Nov 2017 02:32:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdT3f5Opkogx13JC2erHrDZnFjzxwW i55D/ewWH7beZbOYMeUdowOrx5TfG1k9liz5yeRx8ZKyR8ucPcweHw71sAewRnHZpKTmZJal FunbJXBl/Fz0n7XgpUjFm6ZtrA2M1wW6GDk5JARMJLZ+XsTUxcjFISRwmFHi2Z7frBDODkaJ 3ZPWQGU2Mkr8PraUHcJZwChxb8UrVpB+YYFwiZ9b/jKB2CIC1hId16czgtjMAjUSL96tZAex hQQCJJb/Og9mswkYSZz98JOti5GDg1fAXuLBAisQk0VAVWLSPk+QClGBCInnze/BpvMKCEqc nPmEBcTmFAiU+HGmgQliuoXEzPnnoTbJSzRvnc0MYYtL3HoynwniMzWJq+c2MUNcoC0xfe59 lgmMIrOQjJ2FZNQsJKNmIRm1gJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgLB3c8ttg B+PL546HGAU4GJV4eO+tlokSYk0sK67MPcQowcGsJMIr+1A6Sog3JbGyKrUoP76oNCe1+BCj NAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVANjzKk9eiujK9sutPTWVnqculfM+V1i1UWV gIZFvszeEsdNJS5Upl4wyZu6R8Xi/opzOyN/7E72OuSzS49tWzbrxvjbSnGhcRPivoq+9A5x Mb/8S8208UNRlW92p1y7/a7l4ad3hgVedY+/pMzwJWFzv6puwJu5BU5FZpFTt1zp2q8e3Oxz b4oSS3FGoqEWc1FxIgAuDwRwoQIAAA== 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: Tue, 28 Nov 2017 00:32:43 -0000 Thank you very much Mike! Yes, we propose to update RFC 6553 from 0x63 to 0x23 based on: "....[RFC6553] states  that in the Option Type field of    the RPL Option header, the two high order bits MUST be set to '01'    and the third bit is equal to '1'.  The first two bits indicate that    the IPv6 node MUST discard the packet if it doesn't recognize the    option type, and the third bit indicates that the Option Data may    change en route.  The remaining bits serve as the option type. Recent changes in [RFC8200] (section 4, page 8), states: "it is now    expected that nodes along a packet's delivery path only examine and    process the Hop-by-Hop Options header if explicitly configured to do    so".  Processing of the Hop-by-Hop Options header (by IPv6    intermediate nodes) is now optional, but if they are configured to    process the header, and if such nodes encounter an option with the    first two bits set to 01, they will drop the packet (if they conform    to [RFC8200]).  Host systems should do the same, irrespective of the    configuration.    Based on That, if an IPv6 (intermediate) node (RPL-not-capable)    receives a packet with an RPL Option, it should ignore the HBH RPL    option (skip over this option and continue processing the header).    Thus, this document updates the Option Type field to: the two high    order bits MUST be set to '00' and the third bit is equal to '1'.    The first two bits indicate that the IPv6 node MUST skip over this    option and continue processing the header ([RFC8200] Section 4.2) if    it doesn't recognize the option type, and the third bit continues to be set to indicate that the Option Data may change en route.  The    remaining bits serve as the option type and remain as 0x3. This    ensures that a packet that leaves the RPL domain of an LLN (or that    leaves the LLN entirely) will not be discarded when it contains the    [RFC6553] RPL Hop-by-Hop option known as RPI...." [https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19#section-3.1] Thanks, Ines On 27.11.2017 23:36, C. M. Heard wrote: > Greetings, > > It seems to me that the option description and filtering advice given in > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4 > > is not consistent with the revised definition of the RPI option in > > https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19 > > which is now in WG last call in ROLL. I have cc:'d the authors of > useofrplinfo. > > Thanks & regards, > > Mike Heard From nobody Tue Nov 28 07:43:34 2017 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 B3A92126BF3 for ; Tue, 28 Nov 2017 07:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaN9wXdAXsAm for ; Tue, 28 Nov 2017 07:43:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A001242EA for ; Tue, 28 Nov 2017 07:43:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B2C52008D; Tue, 28 Nov 2017 10:45:58 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A6D88807CC; Tue, 28 Nov 2017 10:43:31 -0500 (EST) From: Michael Richardson To: "C. M. Heard" cc: OPSEC , Ines Robles , Pascal Thubert In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m 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: Tue, 28 Nov 2017 15:43:34 -0000 --=-=-= Content-Type: text/plain C. M. Heard wrote: > It seems to me that the option description and filtering advice given > in > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4 a) it only coverts 0x63, and we are changing to 0x23. b) yes, the advice to drop is not good. I'm unclear from a quick read if this the black-list advice, or the white-list advice. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlodhCMACgkQgItw+93Q 3WVT4gf/eclXnlr4QHAFHvlTcCHMzkqS9ke4d9ygKUOHraK/u9kkFvzP5AvhZG4b MnAha+HznktOTE35o61t0fj3bP1XGgMnihVwZDNkA++ZLMf0IaNTnJTy/HiW+Iaa FM7924dhGvCPb7Enjraer71MythYWCXCJz0MFx/SEh1mh4Rtyoa6nKX4QvCKg8x1 AjfJ47rVFRxj91FHEPuoo+y9zUr1ghXnok88UfOaCM9UnGWuOEWgXZhvUftTKKpd lJaqPqePZpegiDLSH5e/7kXAvCNuUe3eHBTX+68UWYS9wEow48z83J/lVaJk/kPb r8HeiT0+6KPVlkBEvs3GyFWXmAlZKw== =6xUF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 28 08:01:07 2017 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 24A611270B4 for ; Tue, 28 Nov 2017 08:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh5wzR6Qxxw8 for ; Tue, 28 Nov 2017 08:01:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E0C127B73 for ; Tue, 28 Nov 2017 08:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1511884860; x=1513094460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wl4bAq7uQFgY9wUiwEmyDPbXLnsOWrcU4wsm2C82hCc=; b=N9ld4ZjepnJJ2SiegrRDiKPGIErP1MmNmrlwMdhcoL5nW3s3YwUtZzY1 kHe4qgkWnO2yJ856A9ojRBQy8mf5z67WJw9PmZsCaPsk0gIj7d+7NJIf1 ZIahe4rEDUEekal7QUjWrD4lQ089y5wqCpLhaAMmsCIt2Q7FzsyPNv4p5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAABThx1a/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4nB44YjxeBfZZyghEKJYFcgzoChQY/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohR8BAQEBAzo/DAQCAQgRBAEBAR4JBzIUCQgCBAENBQiKGhCqC4p+AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDPIIJgVWBaYMrgzGHZgWiSQKHcY0Rgh+KFIcljHe?= =?us-ascii?q?JGwIRGQGBOQEfOYFRbxU6gimCUhyBZ3cBAYlOgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.44,468,1505779200"; d="scan'208";a="324126857" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 16:00:59 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vASG0x9w008617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Nov 2017 16:00:59 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 28 Nov 2017 10:00:58 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 28 Nov 2017 10:00:58 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "C. M. Heard" CC: OPSEC , Ines Robles Thread-Topic: Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04 Thread-Index: AQHTZ8fYLHUJmV+LBkiRIFuUOx3JBKMqVE2A//+es1A= Date: Tue, 28 Nov 2017 16:00:39 +0000 Deferred-Delivery: Tue, 28 Nov 2017 16:00:30 +0000 Message-ID: <5553d3d161d24c5cbb5aabae4e1bc6a0@XCH-RCD-001.cisco.com> References: <674.1511883811@obiwan.sandelman.ca> In-Reply-To: <674.1511883811@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 28 Nov 2017 16:01:06 -0000 Hello Michael: Clarifiation would be that dropping 0x63 is OK but dropping 0x23 or whateve= r 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 RP= L network systematically; this overrides a rule in RFC 8200 but still makes= sense in the particular case. Cheers, Pascal -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: mardi 28 novembre 2017 16:44 To: C. M. Heard Cc: OPSEC ; Ines Robles ; P= ascal Thubert (pthubert) Subject: Re: Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-fi= ltering-04 C. M. Heard wrote: > It seems to me that the option description and filtering advice given > in > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#sec= tion-4.3.4 a) it only coverts 0x63, and we are changing to 0x23. b) yes, the advice to drop is not good. I'm unclear from a quick read if this the black-list advice, or the white-l= ist advice. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Tue Nov 28 16:13:30 2017 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 4C6461292F4 for ; Tue, 28 Nov 2017 16:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 shJv-lSU7plh for ; Tue, 28 Nov 2017 16:13:27 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AF5127735 for ; Tue, 28 Nov 2017 16:13:27 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D1DA0B7E7A for ; Tue, 28 Nov 2017 19:13:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=I3Dd6gT5PRHmTE1VfSRNx4O6XAY=; b=QrlYzZ aVHuLgqaa1IWag+p47YE9UwlZXef+TkjqM0FoGdCzrgoHydTVPKepeSIijxqi+zH C4kKGGLMdR57iUgzfBZ0aPmptc/G8SRO72RGTdEnHEn7sXZzn7EItXptnE3AXiFV 1CZsFHPNqbwWy8jQAoig3TZsBlv50/hER5qag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=fIKwRMmK/7Shi+bJFtd6m8K3lezIMuNw Hhnf1rTSt4I7kZ1eypfr+0Km9ru6E8yeRGXIkO3mrRGlHOvTyXKj5hnXBaMXhFvk yahefwlrM0Ua+34pMV9TRx1eLvMOxTt4Jzmo2Vq+R9kW6iQ6DQNwcDbZUh3wI/Gm nLsu0tytnMU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id C9F8BB7E79 for ; Tue, 28 Nov 2017 19:13:25 -0500 (EST) Received: from mail-qt0-f182.google.com (unknown [209.85.216.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 522B1B7E76 for ; Tue, 28 Nov 2017 19:13:25 -0500 (EST) Received: by mail-qt0-f182.google.com with SMTP id k19so2261930qtj.6 for ; Tue, 28 Nov 2017 16:13:25 -0800 (PST) X-Gm-Message-State: AJaThX4Oc9W8oyCsBQbVa0+skueT0XDJYPqZtFGtqCChdum8isFBaWyC t7lcJcAUlgz7mldi+822fo2A/ISI3XqihC/Mcis= X-Google-Smtp-Source: AGs4zMYTl5FBPG2WHZlAaYeoHXraIcNaNUK/O1bnw1nxwmheRlx59NYXz+1QDqU5FC2LiQ0yulR9pBGl9HH1Olb4yiQ= X-Received: by 10.200.52.137 with SMTP id w9mr1735326qtb.290.1511914404922; Tue, 28 Nov 2017 16:13:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.86.239 with HTTP; Tue, 28 Nov 2017 16:13:04 -0800 (PST) In-Reply-To: <5553d3d161d24c5cbb5aabae4e1bc6a0@XCH-RCD-001.cisco.com> References: <674.1511883811@obiwan.sandelman.ca> <5553d3d161d24c5cbb5aabae4e1bc6a0@XCH-RCD-001.cisco.com> From: "C. M. Heard" Date: Tue, 28 Nov 2017 16:13:04 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "Pascal Thubert (pthubert)" Cc: Michael Richardson , "C. M. Heard" , OPSEC , Ines Robles Content-Type: multipart/alternative; boundary="001a1149cdbe094b89055f140104" X-Pobox-Relay-ID: 1E1F4BD8-D49A-11E7-8EBA-575F0C78B957-06080547!pb-smtp2.pobox.com 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: Wed, 29 Nov 2017 00:13:29 -0000 --001a1149cdbe094b89055f140104 Content-Type: text/plain; charset="UTF-8" Removing the HbH header should not be necessary once the new RPI code point is in use, if it is possible to prevail on draft-ietf-opsec-ipv6-eh-filtering to give the right advice and to prevail upon operators to follow said advice. The advice now in draft-ietf-opsec-ipv6-eh-filtering is just plain wrong for 0x23 (or whatever new code point is chosen), since the explicit intent of useofrplino is to allow packets leaving the RPL domain to be processed normally by RPL-unaware nodes without stripping the option. That after all was the whole point of changing to a code point that allows nodes that don't recognize it to ignore it. --cmh On Tue, Nov 28, 2017 at 8:00 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> 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. > > Cheers, > > Pascal > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: mardi 28 novembre 2017 16:44 > To: C. M. Heard > Cc: OPSEC ; Ines Robles ; > Pascal Thubert (pthubert) > Subject: Re: Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh- > filtering-04 > > > C. M. Heard wrote: > > It seems to me that the option description and filtering advice given > > in > > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh- > filtering-04#section-4.3.4 > > a) it only coverts 0x63, and we are changing to 0x23. > b) yes, the advice to drop is not good. > > I'm unclear from a quick read if this the black-list advice, or the > white-list advice. > > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > > > --001a1149cdbe094b89055f140104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Removing the HbH header should = not be necessary once the new RPI code point is in use, if it is possible t= o prevail on draft-ietf-opsec-ipv6-eh-filtering to give the right advice an= d to prevail upon operators to follow said advice.

The advice now in draft-ietf-o= psec-ipv6-eh-filtering is just plain wrong for 0x23 (or whatever new code p= oint is chosen), since the explicit intent of useofrplino is to allow packe= ts leaving the RPL domain to be processed normally by RPL-unaware nodes wit= hout stripping the option. That after all was the whole point of changing t= o a code point that allows nodes that don't recognize it to ignore it.<= /div>

--cmh<= /div>

On Tue, Nov = 28, 2017 at 8:00 AM, Pascal Thubert (pthubert) <pthubert@cisco.com>= ; wrote:
Hello Michael:

Clarifiation would be that dropping 0x63 is OK but dropping 0x23 or whateve= r 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 RP= L network systematically; this overrides a rule in RFC 8200 but still makes= sense in the particular case.

Cheers,

Pascal
-----Original Message--= ---
From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
Sent: mardi 28 novembre 2017 16:44
To: C. M. Heard <heard@pobox.com&= gt;
Cc: OPSEC <opsec@ietf.org>; Ine= s Robles <maria.ines.r= obles@ericsson.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>
Subject: Re: Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04


C. M. Heard <heard@pobox.com> = wrote:
=C2=A0 =C2=A0 > It seems to me that the option description and filtering= advice given
=C2=A0 =C2=A0 > in
=C2=A0 =C2=A0 > ht= tps://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#s= ection-4.3.4

a) it only coverts 0x63, and we are changing to 0x23.
b) yes, the advice to drop is not good.

I'm unclear from a quick read if this the black-list advice, or the whi= te-list advice.


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works=C2=A0 -=3D IPv6 IoT consulti= ng =3D-




--001a1149cdbe094b89055f140104--