From nobody Tue Apr 11 02:23:20 2017 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 DC3B5126D85; Tue, 11 Apr 2017 02:23:12 -0700 (PDT) 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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149190259286.15750.1719302946149897449@ietfa.amsl.com> Date: Tue, 11 Apr 2017 02:23:12 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-11.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: Tue, 11 Apr 2017 09:23:13 -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 of the IETF. Title : Operational Security Considerations for IPv6 Networks Authors : Kiran K. Chittimaneni Merike Kaeo Eric Vyncke Filename : draft-ietf-opsec-v6-11.txt Pages : 47 Date : 2017-04-11 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 all 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 00:39:35 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 0814812871F for ; Wed, 12 Apr 2017 00:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEZTLhibSc2s for ; Wed, 12 Apr 2017 00:39:31 -0700 (PDT) Received: from st11p00im-asmtp002.me.com (st11p00im-asmtp002.me.com [17.172.80.96]) (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 C0A661287A7 for ; Wed, 12 Apr 2017 00:39:30 -0700 (PDT) Received: from process-dkim-sign-daemon.st11p00im-asmtp002.me.com by st11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OOA00C00CVT2F00@st11p00im-asmtp002.me.com> for opsec@ietf.org; Wed, 12 Apr 2017 07:39:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1491982770; bh=lpC9k2MfHb7iMTxhAbSxvYyyHXOgZgndi6mNLN8NVzk=; h=MIME-version:Content-type:To:From:Subject:Date:Message-id; b=RYAExgkew0AVVmUruNChu1Gwrr2TSwwjpZw5EguX//Xe0AeFXX6ZNhCmN9MQHehJq 2wyXubaLNG3QxXmS7X/UGX0kzQPp+nVRtWizpNjK+cozcto33+UKzTaVseJRUYOu/g iRxXa2YOpMhPM7ELhOAbjbRmelzru3RybnxXj9UGy+oaCP1l6KF+PXK7/gIRCeKm+5 iG3V7KRngQq70hBAFyy13SOmeQgdc7WfK4Smv1Km4F9/AVm3ojKQE4cT0N6F7RHGx8 b+RjxwFgPKuhTth1epzfx+Gd3YbdZ71caLGOl+h80xgHuy3Xnj6v+xawM6IlMT2rrw UD68FCbwuBy3A== Received: from st13p11im-spool002.me.com ([17.164.40.213]) by st11p00im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OOA0088HD9SU510@st11p00im-asmtp002.me.com> for opsec@ietf.org; Wed, 12 Apr 2017 07:39:28 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=12 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1704120066 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MYfosk8KosS84mEiEA4KDA)" Received: from localhost ([17.164.40.63]) by st13p11im-spool002.mac.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OOA00ORGD9SM250@st13p11im-spool002.mac.com> for opsec@ietf.org; Wed, 12 Apr 2017 07:39:28 +0000 (GMT) To: opsec@ietf.org From: Gunter Van De Velde Date: Wed, 12 Apr 2017 07:39:28 +0000 (GMT) X-Mailer: iCloud MailClient17BProject86 MailServer17B92.25994-16A-1848-96e8bf599cd0 Message-id: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> Archived-At: Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 12 Apr 2017 07:39:33 -0000 --Boundary_(ID_MYfosk8KosS84mEiEA4KDA) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable This is to open a two week WGLC for=C2=A0https://tools.ietf.org/html/draft= -ietf-opsec-v6.=0AIf you have not read it, please do so now. You may send = nits to the author, but substantive discussion should go to the list.=0A=0A= I will close the call on 26 April 2017=0A=0AG/=C2=A0=0ASent from iCloud= --Boundary_(ID_MYfosk8KosS84mEiEA4KDA) Content-type: multipart/related; boundary="Boundary_(ID_QgNRuPE06pLGTOsv4HMXlg)"; type="text/html" --Boundary_(ID_QgNRuPE06pLGTOsv4HMXlg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
This is to open= a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.
If you have = not read it, please do so now. You may send nits to the author, but substa= ntive discussion should go to the list.

I will close t= he call on 26 April 2017

G/ 
Sent from iC=
loud
= --Boundary_(ID_QgNRuPE06pLGTOsv4HMXlg)-- --Boundary_(ID_MYfosk8KosS84mEiEA4KDA)-- From nobody Fri Apr 14 07:19:10 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 6494B12F28E for ; Fri, 14 Apr 2017 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOaXpbGnvI-t for ; Fri, 14 Apr 2017 07:19:07 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0136.outbound.protection.outlook.com [104.47.42.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED7312F27C for ; Fri, 14 Apr 2017 07:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4UhT/iEZ1Ea6098fTxygk6YrMRwk+OothHrPkUNYSwg=; b=LBhfV61qQpagQhtVV+RsQ2aCuNUX1CcQ/G2KNvQ9P2jFVT8A/SDhzYdWaLoOEaUNSwRqgTbkaMIMFAk68S7zn1mqzF+5xdyJua+DIIrbUwIpllp42cj+fQbiUO9g6mwxOHZ4Cnte1wZv+jDOnyI+B7e1A1ekaAw45ODU62VsjvA= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 14 Apr 2017 14:19:05 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1047.006; Fri, 14 Apr 2017 14:19:05 +0000 From: Ron Bonica To: "opsec@ietf.org" Thread-Topic: [Int-area] WG Adoption Call: Extended Ping (Xping) Thread-Index: AdK1KhFm61oqP1/aSOW5Z28gtMW4FQ== Date: Fri, 14 Apr 2017 14:19:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 7:LQtg7pCV17Jc/7RGhddu92LbnifepQd5VrISpx5w1ZN9gOGdZ4zD3qc1DPiOevEAK1+E1lolVFmUccNJ3W1MVPv2ejXBBO93I+45j/GgtgGkpEQs63pfeQmlKIv6YKZMsqNwo6/f9AfhruoRGy4cQufR270KdudMVpF63EU/cwd0yi4WgIttM0tPgyZsHnEOpblG8ZSkZQ8OmRWhQtffp608ye6WaJuZY7+Js+qJH8SM00LV9hp5gCY/9UqXFF1eg/EPuutKGjwHvGY3dOiijjo6nWh3hmTHcIH6kP+0XK0SappmwplyVC3GEaLvsbVmZgNI0NssefG/L4n3tuTvtQ== x-ms-office365-filtering-correlation-id: ab6b7681-de81-409d-9c9e-08d483413555 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(2900100001)(3660700001)(3280700002)(110136004)(38730400002)(66066001)(33656002)(5890100001)(2501003)(305945005)(77096006)(7736002)(5660300001)(2351001)(74316002)(2906002)(6116002)(3846002)(102836003)(86362001)(25786009)(50986999)(229853002)(8936002)(54356999)(7696004)(189998001)(512874002)(81166006)(122556002)(6916009)(1730700003)(8676002)(9686003)(6436002)(6506006)(5640700003)(99286003)(55016002)(6306002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 14:19:05.6217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: [OPSEC] FW: [Int-area] WG Adoption Call: Extended Ping (Xping) 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, 14 Apr 2017 14:19:09 -0000 Folks, A while back, OPSEC considered an Informational draft aimed at reducing a r= outer's attach surface. One recommendation was to use unnumbered interface = to the greatest degree possible. This recommendation was problematic becaus= e it is impossible to ping an unnumbered interface. This week, the INTAREA WG is considering adoption of an Extended PING (XPIN= G) draft. XPING allows operators to ping unnumbered interfaces. Please take a look at the draft (draft-bonica-intarea-eping-04). If you thi= nk that it is headed in the right direction, please voice support for adopt= ion on the INTAREA WG mailing list. = Ron Call for adoption =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Message: 2 Date: Thu, 13 Apr 2017 11:15:29 -0700 From: Wassim Haddad To: "int-area@ietf.org" Cc: Wassim Haddad , Subject: [Int-area] WG Adoption Call: Extended Ping (Xping) Message-ID: Content-Type: text/plain; charset=3D"utf-8" Dear all, We would like to start a WG adoption call for draft-bonica-intarea-eping-04= (?Extended Ping (Xping)?): https://tools.ietf.org/id/draft-bonica-intarea-eping-04.txt Please indicate your preferences on the mailling list. The deadline is Apri= l 28th. Regards, Wassim & Juan Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ------------------------------ End of Int-area Digest, Vol 140, Issue 10 ***************************************** From nobody Mon Apr 17 13:02:59 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 75C13129445 for ; Mon, 17 Apr 2017 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1daqWB2zkuA for ; Mon, 17 Apr 2017 13:02:54 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0136.outbound.protection.outlook.com [104.47.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55878129458 for ; Mon, 17 Apr 2017 13:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sbMq0BreFpnj6Vvw+uFIlUBNSAR53QQEvxhUz+I8b7U=; b=YsvZbbp0+gRliv1z31x+BxU+J4eQU188oBUIJAPAnze0WL7Y7OkwvI2sFpFqMxqbxSDNzG/9UDT4ro7/sxugq2I3v/hSGI5EJoz2jBCca6PnOoXkNFEKB/KJYK0xH3soFDI5+XG1E1aVudx5oIWs2Z49ZroktRdv4XJ1tP0/Rdo= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 20:02:51 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1047.006; Mon, 17 Apr 2017 20:02:51 +0000 From: Ron Bonica To: Gunter Van De Velde , "opsec@ietf.org" Thread-Topic: [OPSEC] WGLC for draft-ietf-opsec-v6 Thread-Index: AQHSs1/wtwa3CP4FW0+mXO4vHe5YGKHKAuGQ Date: Mon, 17 Apr 2017 20:02:51 +0000 Message-ID: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> In-Reply-To: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: icloud.com; dkim=none (message not signed) header.d=none;icloud.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:+wQa0rV/Of0a1n1uUfX89V3PlePMH0c46jJ1r4Q/8tL5W3n0T1NaclUz1jMulvx9zrfnc98p/PnwxMO7qavDlQTPT+UwXK+0h0LxhiJkHpXvss4tre2SjISODv+9GySi23PhWlxfk9Z389GHXz2VlW44huqE44hZUthrp0omHpGhjtYj75vtuYW26AqKwFeCjgXEdX1BtYGyK66wov3sO0xUmEbv+NKSWhfwl/L+/oyQTyMQkDQKUc6yDhW6l29RBJcuLauk8/K6BJ7LhAc/KmcaUfLUycZThYHQb8W2KOOHpQh+0AlVjKoF5D17Gdh6hCvCBMnfWcfz1ygdjbG0tQ== x-ms-office365-filtering-correlation-id: 4d68f3df-4ecd-488f-875c-08d485ccbaa6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(377454003)(77096006)(6306002)(9686003)(8936002)(5660300001)(54896002)(236005)(6246003)(74316002)(2900100001)(81166006)(99286003)(6436002)(8676002)(9326002)(3660700001)(790700001)(3280700002)(86362001)(19609705001)(606005)(3846002)(8666007)(6116002)(102836003)(53936002)(7736002)(7906003)(2950100002)(7696004)(76176999)(55016002)(2501003)(53546009)(66066001)(230783001)(25786009)(38730400002)(33656002)(6506006)(2906002)(50986999)(54356999)(101416001)(229853002)(189998001)(39060400002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB20512E6950AB4073EB4FC68CAE060BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2017 20:02:51.6599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 17 Apr 2017 20:02:57 -0000 --_000_BLUPR0501MB20512E6950AB4073EB4FC68CAE060BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gunter, I support publication of this draft, but see a small problem in Section 2.2= .2. In Section 2.2.2, the authors reference "ietf-6man-hbh-header-handling"= . This draft has been allowed to die on the vine, but artifacts can be seen= in the following text from RFC2460bis. " NOTE: While [RFC2460] required that = all nodes must examine and process the Hop-by-Hop Options header, 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." You might want to update the draft with this change to 2460 in mind. Ron From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van De Veld= e Sent: Wednesday, April 12, 2017 3:39 AM To: opsec@ietf.org Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-= opsec-v6. If you have not read it, please do so now. You may send nits to the author,= but substantive discussion should go to the list. I will close the call on 26 April 2017 G/ Sent from iCloud --_000_BLUPR0501MB20512E6950AB4073EB4FC68CAE060BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gunter,

 

I support publication of this draft, but see a small pr=
oblem in Section 2.2.2. In Section 2.2.2, the authors reference “ietf-6man-hbh-header-handling”. This draft has been allowed to die on the vine, but a=
rtifacts can be seen in the following text from RFC2460bis.
 
“ NOTE: While [RFC2460] required that all nodes must examine a=
nd
   process the Hop-by-Hop Option=
s header, it is now expected that nodes
   along a packet's delivery pat=
h only examine and process the Hop-by-
   Hop Options header if explici=
tly configured to do so.”

 =

You might want to update the draft wi= th this change to 2460 in mind.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   Ron

 

&nbs= p;

From: OPSEC [mailto:opsec-bounces@ie= tf.org] On Behalf Of Gunter Van De Velde
Sent: Wednesday, April 12, 2017 3:39 AM
To: opsec@ietf.org
Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

 

This is to open a two week WGLC fo= r https://= tools.ietf.org/html/draft-ietf-opsec-v6.

If you have not read it, please do= so now. You may send nits to the author, but substantive discussion should= go to the list.



I will close the call on 26 April = 2017



G/ 

Sent from i=
Cloud
--_000_BLUPR0501MB20512E6950AB4073EB4FC68CAE060BLUPR0501MB2051_-- From nobody Mon Apr 17 13:11:16 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 1BBB2129458 for ; Mon, 17 Apr 2017 13:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ygSm3Ju6ZOB for ; Mon, 17 Apr 2017 13:11:12 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0135.outbound.protection.outlook.com [104.47.37.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25E6129454 for ; Mon, 17 Apr 2017 13:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e5GrCXNtCGJZi/1jQyMgJcvRM5FdITaUf3ohFekd8ks=; b=hu7StuPofcu1sgrCKsLYqTXC6B34P/QRVLZb8rgvUV8P45QKb91B9M584uzXEL+XOJJrOjLLkiiKYEbb6UXGNpKhkiHwoK302X3MqJ0jDNQEsodRNMFBO4CjqsM7g0nPPSU7LE8mabvQMNgNi1jgY40u0DX7WqbBz0t5CWfc1Fk= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 20:11:11 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.1047.006; Mon, 17 Apr 2017 20:11:11 +0000 From: Ron Bonica To: Gunter Van De Velde , "opsec@ietf.org" Thread-Topic: [OPSEC] WGLC for draft-ietf-opsec-v6 Thread-Index: AQHSs1/wtwa3CP4FW0+mXO4vHe5YGKHKAuGQgAACK6A= Date: Mon, 17 Apr 2017 20:11:11 +0000 Message-ID: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: icloud.com; dkim=none (message not signed) header.d=none;icloud.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 7:ZekIuxMi6CbwFQTbgDUzfF6Kt68v3V+j6bEG3zAQhaue22425ofx8uC8dL7NQF1K1W3mzFEDhUPKsiqCfHEHcja6IOjat6ZCUstI51W/NlNTmwZKTmWyiI3LSrvK/bvITj4srsfCt79S8hyFx2msvOCg/CmTi2eo8Yv+kXubrSFoY/s8cR0+HgwrEVMQuchY4fW3v5N1YjaA9K9wo5JRJ7FSHfaYWFTEWEeRNoQlJZSIRcuq0zlcb+kqqnHuw6GlyTB5AuV3o9LZ00eH76ZBzvnZABh5F5AhmSPX+S+8nDopkIyUay9lH8NQ7dvRkJsFsLnWnKJ77Hk65e1EZVdcuw== x-ms-office365-filtering-correlation-id: 8f4cacdf-84eb-4d06-e121-08d485cde473 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(84792000423722)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(377454003)(77096006)(6306002)(9686003)(8936002)(5660300001)(54896002)(236005)(6246003)(74316002)(2900100001)(81166006)(99286003)(6436002)(8676002)(3660700001)(790700001)(3280700002)(86362001)(19609705001)(606005)(3846002)(8666007)(6116002)(102836003)(53936002)(7736002)(7906003)(7696004)(76176999)(55016002)(2501003)(53546009)(66066001)(230783001)(25786009)(38730400002)(33656002)(6506006)(2906002)(50986999)(54356999)(101416001)(229853002)(189998001)(39060400002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB205147EC906A1307873E0645AE060BLUPR0501MB2051_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2017 20:11:11.3046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 17 Apr 2017 20:11:15 -0000 --_000_BLUPR0501MB205147EC906A1307873E0645AE060BLUPR0501MB2051_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, the contents of 2.2.3 are covered by the following text from rfc 2460= bis: "If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded and an ICMP Parameter Problem, Code 3, message should be sent to the source of the fragment, with the Pointer field set to zero." Maybe you can drop Section 2.2.3 and replace it with a pointer to RFC2460bi= s? Ron From: Ron Bonica Sent: Monday, April 17, 2017 4:03 PM To: 'Gunter Van De Velde' ; opsec@ietf.org Subject: RE: [OPSEC] WGLC for draft-ietf-opsec-v6 Hi Gunter, I support publication of this draft, but see a small problem in Section 2.2= .2. In Section 2.2.2, the authors reference "ietf-6man-hbh-header-handling"= . This draft has been allowed to die on the vine, but artifacts can be seen= in the following text from RFC2460bis. " NOTE: While [RFC2460] required that = all nodes must examine and process the Hop-by-Hop Options header, 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." You might want to update the draft with this change to 2460 in mind. Ron From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van De Veld= e Sent: Wednesday, April 12, 2017 3:39 AM To: opsec@ietf.org Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-= opsec-v6. If you have not read it, please do so now. You may send nits to the author,= but substantive discussion should go to the list. I will close the call on 26 April 2017 G/ Sent from iCloud --_000_BLUPR0501MB205147EC906A1307873E0645AE060BLUPR0501MB2051_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also, the contents of 2.2.3 are cover= ed by the following text from rfc 2460bis:

 

       &nbs= p; “If the first fragment does not include all headers through an

       &nbs= p; Upper-Layer header, then that fragment should be discarded and

       &nbs= p; an ICMP Parameter Problem, Code 3, message should be sent to<= /span>

       &nbs= p; the source of the fragment, with the Pointer field set to zero.”

 

Maybe you can drop Section 2.2.3 and replace i= t with a pointer to RFC2460bis?

 

       &nbs= p;            &= nbsp;           &nbs= p;  Ron

 

 

&nbs= p;

From: Ron Bonica
Sent: Monday, April 17, 2017 4:03 PM
To: 'Gunter Van De Velde' <guntervandeveldecc@icloud.com>; ops= ec@ietf.org
Subject: RE: [OPSEC] WGLC for draft-ietf-opsec-v6<= /p>

 

Hi Gunter,

 

I support publication of this draft, but see a small pr=
oblem in Section 2.2.2. In Section 2.2.2, the authors reference “ietf-6man-hbh-header-handling&=
#8221;. This draft has been allowed to die on the vine, but artifacts can b=
e seen in the following text from RFC2460bis.
 
“ NOTE: While [RFC2460] required that all nodes must examine a=
nd
   process the Hop-by-Hop Option=
s header, it is now expected that nodes
   along a packet's delivery pat=
h only examine and process the Hop-by-
   Hop Options header if explici=
tly configured to do so.”

 =

You might want to update the draft wi= th this change to 2460 in mind.

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   Ron

 

 

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van De Velde
Sent: Wednesday, April 12, 2017 3:39 AM
To: opsec@ietf.org
Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

 

This is to open a two week WGLC fo= r https://= tools.ietf.org/html/draft-ietf-opsec-v6.

If you have not read it, please do= so now. You may send nits to the author, but substantive discussion should= go to the list.

 

I will close the call on 26 April = 2017

 

G/ 

Sent from i=
Cloud
--_000_BLUPR0501MB205147EC906A1307873E0645AE060BLUPR0501MB2051_-- From nobody Tue Apr 18 00:07:32 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 25BBE12778E for ; Tue, 18 Apr 2017 00:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 uALlH46QOrX4 for ; Tue, 18 Apr 2017 00:07:29 -0700 (PDT) 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 1F0A0127419 for ; Tue, 18 Apr 2017 00:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13804; q=dns/txt; s=iport; t=1492499249; x=1493708849; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8JvTsPVTcgHnFQ1ub+UzRkKT382Z4dO8Vgk9MfRfO90=; b=bJJV0K1QstKwJoCrlhpk62DNkj2X8tFOeguoMXWDtyYXUu/bAuez/zEN L4UE6f2ldI3WTNl7xGWvV0oIIro9NPDxuGIlIMz4rjBcRT7gPGoYeZMIK tmPEvgU3l6zBtUHrfMAX7QuGk+XnLUWHPayyXv8eNQwwu6ih71kaTY85p 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAgBMuvVY/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5lYYELB4NfihWRPiGQK4U0gg8shXgCGoNuPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMjZgIBCA4DAwEBASgDAgICMBQJCAIEARKJfwMVDqo7giYrhw0Qg?= =?us-ascii?q?1oBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZSgV0rCoJjhHcWglAugjEFihOTCAG?= =?us-ascii?q?HA4tigX+FMINdhjqIaYsgAR84gQVjFUQRAYZTdYgOgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,218,1488844800"; d="scan'208,217";a="413866534" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2017 07:07:28 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3I77Rck008876 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 07:07:28 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.1210.3; Tue, 18 Apr 2017 03:07:27 -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.1210.000; Tue, 18 Apr 2017 03:07:27 -0400 From: "Eric Vyncke (evyncke)" To: Ron Bonica , Gunter Van De Velde , "opsec@ietf.org" Thread-Topic: [OPSEC] WGLC for draft-ietf-opsec-v6 Thread-Index: AQHSs1/zAqT2GEaKCUyt76qDS1uIwKHKR32AgADbOAA= Date: Tue, 18 Apr 2017 07:07:27 +0000 Message-ID: <14BBD890-86C7-4366-AEB9-825DE9E44D68@cisco.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.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.163.34] Content-Type: multipart/alternative; boundary="_000_14BBD89086C74366AEB9825DE9E44D68ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 07:07:31 -0000 --_000_14BBD89086C74366AEB9825DE9E44D68ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJvbiBmb3IgdGhlIHJldmlldywgeW91ciAyIHBvaW50cyBhYm91dCB0aGUgbmV3IFJG QyAyNDYwYmlzIGFyZSByaWdodCB0byB0aGUgcG9pbnQgOi0pDQoNCi3DqXJpYw0KDQpGcm9tOiBP UFNFQyA8b3BzZWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJvbiBCb25pY2EgPHJi b25pY2FAanVuaXBlci5uZXQ+DQpEYXRlOiBNb25kYXkgMTcgQXByaWwgMjAxNyBhdCAyMjowMg0K VG86IEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPiwg Im9wc2VjQGlldGYub3JnIiA8b3BzZWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09QU0VDXSBX R0xDIGZvciBkcmFmdC1pZXRmLW9wc2VjLXY2DQoNCkhpIEd1bnRlciwNCg0KDQpJIHN1cHBvcnQg cHVibGljYXRpb24gb2YgdGhpcyBkcmFmdCwgYnV0IHNlZSBhIHNtYWxsIHByb2JsZW0gaW4gU2Vj dGlvbiAyLjIuMi4gSW4gU2VjdGlvbiAyLjIuMiwgdGhlIGF1dGhvcnMgcmVmZXJlbmNlIOKAnGll dGYtNm1hbi1oYmgtaGVhZGVyLWhhbmRsaW5n4oCdLiBUaGlzIGRyYWZ0IGhhcyBiZWVuIGFsbG93 ZWQgdG8gZGllIG9uIHRoZSB2aW5lLCBidXQgYXJ0aWZhY3RzIGNhbiBiZSBzZWVuIGluIHRoZSBm b2xsb3dpbmcgdGV4dCBmcm9tIFJGQzI0NjBiaXMuDQoNCg0KDQrigJwgTk9URTogV2hpbGUgW1JG QzI0NjA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI0NjA+XSByZXF1aXJlZCB0aGF0 IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUgYW5kDQoNCiAgIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3Ag T3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBleHBlY3RlZCB0aGF0IG5vZGVzDQoNCiAgIGFsb25n IGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhv cC1ieS0NCg0KICAgSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0 byBkbyBzby7igJ0NCg0KWW91IG1pZ2h0IHdhbnQgdG8gdXBkYXRlIHRoZSBkcmFmdCB3aXRoIHRo aXMgY2hhbmdlIHRvIDI0NjAgaW4gbWluZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KRnJvbTogT1BTRUMgW21h aWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3VudGVyIFZhbiBEZSBW ZWxkZQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMiwgMjAxNyAzOjM5IEFNDQpUbzogb3BzZWNA aWV0Zi5vcmcNClN1YmplY3Q6IFtPUFNFQ10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1vcHNlYy12Ng0K DQpUaGlzIGlzIHRvIG9wZW4gYSB0d28gd2VlayBXR0xDIGZvciBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNlYy12Ni4NCklmIHlvdSBoYXZlIG5vdCByZWFkIGl0LCBw bGVhc2UgZG8gc28gbm93LiBZb3UgbWF5IHNlbmQgbml0cyB0byB0aGUgYXV0aG9yLCBidXQgc3Vi c3RhbnRpdmUgZGlzY3Vzc2lvbiBzaG91bGQgZ28gdG8gdGhlIGxpc3QuDQoNCg0KDQpJIHdpbGwg Y2xvc2UgdGhlIGNhbGwgb24gMjYgQXByaWwgMjAxNw0KDQoNCg0KRy8NCg0KU2VudCBmcm9tIGlD bG91ZA0K --_000_14BBD89086C74366AEB9825DE9E44D68ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2F9C86E996467E40A2902FA2C2A62D74@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9z ZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uZ3JleQ0KCXttc28tc3R5bGUtbmFtZTpncmV5O30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRo YW5rcyBSb24gZm9yIHRoZSByZXZpZXcsIHlvdXIgMiBwb2ludHMgYWJvdXQgdGhlIG5ldyBSRkMg MjQ2MGJpcyBhcmUgcmlnaHQgdG8gdGhlIHBvaW50IDotKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPi3DqXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFy Z2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+T1BTRUMgJmx0O29wc2VjLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBSb24gQm9uaWNhICZsdDtyYm9uaWNhQGp1bmlwZXIubmV0Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXkgMTcgQXByaWwgMjAxNyBhdCAyMjowMjxicj4NCjxi PlRvOiA8L2I+R3VudGVyIFZhbiBEZSBWZWxkZSAmbHQ7Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91 ZC5jb20mZ3Q7LCAmcXVvdDtvcHNlY0BpZXRmLm9yZyZxdW90OyAmbHQ7b3BzZWNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT1BTRUNdIFdHTEMgZm9yIGRyYWZ0LWlldGYt b3BzZWMtdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjojMUY0OTdEIj5IaSBHdW50ZXIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFG NDk3RCI+SSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQsIGJ1dCBzZWUgYSBzbWFs bCBwcm9ibGVtIGluIFNlY3Rpb24gMi4yLjIuIEluIFNlY3Rpb24gMi4yLjIsIHRoZSBhdXRob3Jz IHJlZmVyZW5jZSDigJw8L3NwYW4+PGEgbmFtZT0icmVmLUktRC5pZXRmLTZtYW4taGJoLWhlYWRl ci1oYW5kbGluZyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5pZXRmLTZtYW4taGJoLWhlYWRl ci1oYW5kbGluZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7igJ0uIFRoaXMg ZHJhZnQgaGFzIGJlZW4gYWxsb3dlZCB0byBkaWUgb24gdGhlIHZpbmUsIGJ1dCBhcnRpZmFjdHMg Y2FuIGJlIHNlZW4gaW4gdGhlIGZvbGxvd2luZyB0ZXh0IGZyb20gUkZDMjQ2MGJpcy48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7i gJwgTk9URTogV2hpbGUgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMy NDYwIiB0aXRsZT0iJnF1b3Q7SW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24gNiAoSVB2NikgU3Bl Y2lmaWNhdGlvbiZxdW90OyI+UkZDMjQ2MDwvYT5dIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11 c3QgZXhhbWluZSBhbmQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcHJvY2VzcyB0aGUgSG9wLWJ5LUhvcCBPcHRpb25z IGhlYWRlciwgaXQgaXMgbm93IGV4cGVjdGVkIHRoYXQgbm9kZXM8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxvbmcg YSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoIG9ubHkgZXhhbWluZSBhbmQgcHJvY2VzcyB0aGUgSG9w LWJ5LTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBIb3AgT3B0aW9ucyBoZWFkZXIgaWYgZXhwbGljaXRseSBjb25maWd1 cmVkIHRvIGRvIHNvLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPllvdSBtaWdodCB3YW50IHRvIHVwZGF0 ZSB0aGUgZHJhZnQgd2l0aCB0aGlzIGNoYW5nZSB0byAyNDYwIGluIG1pbmQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS b248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2E+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IE9QU0VDIFttYWlsdG86b3BzZWMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3VudGVyIFZhbiBEZSBWZWxkZTxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDEyLCAyMDE3IDM6MzkgQU08YnI+DQo8 Yj5Ubzo8L2I+IG9wc2VjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPUFNFQ10gV0dM QyBmb3IgZHJhZnQtaWV0Zi1vcHNlYy12Njwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgaXMgdG8g b3BlbiBhIHR3byB3ZWVrIFdHTEMgZm9yJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtdjYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9wc2VjLXY2PC9hPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDs7Y29sb3I6YmxhY2siPklmIHlv dSBoYXZlIG5vdCByZWFkIGl0LCBwbGVhc2UgZG8gc28gbm93LiBZb3UgbWF5IHNlbmQgbml0cyB0 byB0aGUgYXV0aG9yLCBidXQgc3Vic3RhbnRpdmUgZGlzY3Vzc2lvbiBzaG91bGQgZ28gdG8gdGhl IGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMm cXVvdDs7Y29sb3I6YmxhY2siPkkgd2lsbCBjbG9zZSB0aGUgY2FsbCBvbiAyNiBBcHJpbCAyMDE3 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDs7 Y29sb3I6YmxhY2siPkcvJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOiBicmVhay13b3Jk Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDsiPlNlbnQgZnJvbSBpQ2xvdWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_14BBD89086C74366AEB9825DE9E44D68ciscocom_-- From nobody Tue Apr 18 00:19:14 2017 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 7A0721315D5; Tue, 18 Apr 2017 00:19:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, opsec@ietf.org, opsec-chairs@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149249995340.20134.16412479462118149409.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 00:19:13 -0700 Archived-At: Subject: [OPSEC] opsec - New Meeting Session Request for IETF 99 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: Tue, 18 Apr 2017 07:19:13 -0000 A new meeting session request has just been submitted by Eric Vyncke, a Chair of the opsec working group. --------------------------------------------------------- Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Eric Vyncke Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: 6man apparea grow opsarea opsawg v6ops Second Priority: acme dmarc dots oauth saag Third Priority: tls sunset4 sidr quic netconf intarea People who must be present: Eric Vyncke Gunter Van de Velde Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Apr 18 00:34:37 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 A45651317B5 for ; Tue, 18 Apr 2017 00:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 IbmCMGKjd6MF for ; Tue, 18 Apr 2017 00:34:33 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30132.outbound.protection.outlook.com [40.107.3.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B011317B2 for ; Tue, 18 Apr 2017 00:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aOpPbei7BPm3WaKP5NMFNWvvnuO/uL099MVi+PdHCSM=; b=FEWA2unWdV+PbHMmPR/3/R91VoV6L97X3U/w1lSD61y0DSvrCp2V+6QTYiqk4p3k3PGZweRnzj0KsiQ9QhgssISCpMFkAYOsVemKCK/TMP/qcawzyaDpYkhz4J7r2PWh2otRbGo+qlmVNmqcLwnpYBBkLUMK/PGlf5jqFL03C7I= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Tue, 18 Apr 2017 07:34:30 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::3975:2267:af91:d672]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::3975:2267:af91:d672%14]) with mapi id 15.01.1047.008; Tue, 18 Apr 2017 07:34:30 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "opsec@ietf.org" CC: "ek@google.com" Thread-Topic: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 Thread-Index: AQHSuBXtF4wmWF1J1EKa9BWgDTLasaHK3ckA Date: Tue, 18 Apr 2017 07:34:30 +0000 Message-ID: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [141.135.12.190] x-microsoft-exchange-diagnostics: 1; AM4PR07MB1715; 7:hkhgk8IsLlLgEZxiZdeyYkDfjbCG5EDNad1Q4bWf0ZI6QVCco688LtShTZ3/4WHGHcZD1f43PFVXiPUK/qD3PA8rKlZQB3LyETswIcBQwKSKvjmt9b5XBkURyhU6S8R8jo/kn1j8cuEy8X+7HZxvOOPJRHdePaL/STSrTeXwnrkiHG38kp2nK1/3ioD0MjWz5me17ZjkEFGAZBprH9LgCk/S48gX6/TgEbojn0YOgjUDwwwlFy3VaeHbpb2dtGM15ANdEaqX3qI7dSYpSBmjpqrcOenfqdewcDf73ZX3R5LNxqur6TrTlMYeFWAATK1oCh6N/V5kKyDkpvAyl54+JA== x-ms-office365-filtering-correlation-id: 0f24967e-b774-4cd7-af47-08d4862d59de x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM4PR07MB1715; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(84792000423722)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:AM4PR07MB1715; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1715; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(24454002)(50986999)(76176999)(7906003)(7736002)(66066001)(54356999)(2900100001)(99936001)(8936002)(3280700002)(82746002)(6506006)(606005)(189998001)(6486002)(83716003)(99286003)(54896002)(3660700001)(2473003)(6306002)(5640700003)(6436002)(33656002)(53936002)(3846002)(229853002)(110136004)(236005)(9686003)(102836003)(2501003)(38730400002)(5250100002)(6512007)(8676002)(6116002)(53546009)(230783001)(4326008)(25786009)(2351001)(36756003)(5660300001)(6916009)(81166006)(1730700003)(2950100002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1715; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_005_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 07:34:30.3097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1715 Archived-At: Subject: [OPSEC] FW: [ALU] Re: [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 07:34:35 -0000 --_005_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_" --_000_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVsYXlpbmcgbWVzc2FnZSB0byBXR0xDIGRpc2N1c3Npb24gYWxpYXMNCg0KRy8NCg0KRnJvbTog djZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBFcmlrIEtsaW5lIDxl a0Bnb29nbGUuY29tPg0KRGF0ZTogVHVlc2RheSwgMTggQXByaWwgMjAxNyBhdCAwOTozMA0KVG86 IEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPg0KQ2M6 ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPiwgNm1hbiA8Nm1hbkBpZXRmLm9yZz4N ClN1YmplY3Q6IFtBTFVdIFJlOiBbdjZvcHNdIEZ3ZDogW09QU0VDXSBXR0xDIGZvciBkcmFmdC1p ZXRmLW9wc2VjLXY2DQoNCjIuMS4yLiAgVXNlIG9mIFVMQXMNCg0KU3RpbGw/ICBSZWFsbHk/DQoN Ck9uIDE4IEFwcmlsIDIwMTcgYXQgMTY6MTgsIEd1bnRlciBWYW4gRGUgVmVsZGUgPGd1bnRlcnZh bmRldmVsZGVjY0BpY2xvdWQuY29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NAaWNsb3VkLmNv bT4+IHdyb3RlOg0KRGVhciA2bWFuLCB2Nm9wcywNCg0KRHVlIHRvIHRoZSBJUHY2IGZvY3VzIG9m ICJkcmFmdC1pZXRmLW9wc2VjLXY2IiB0aGUgT1BTRUMgV0dMQyBmb3IgdGhpcyBkb2N1bWVudCBt YXkgYmUgb2YgaW50ZXJlc3QgdG8gYm90aCA2bWFuIGFzIHY2b3BzLg0KDQpQbGVhc2Ugc2VuZCB5 b3VyIGZlZWRiYWNrIHRvIE9QU0VDIGVtYWlsIGxpc3QsIHdoZXJlIGRpc2N1c3Npb24gYXJvdW5k IHRoaXMgZG9jdW1lbnQgc2hvdWxkIHRha2UgcGxhY2UuDQoNCktpbmQgUmVnYXJkcywNCkcvDQoN Cg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IEd1bnRlciBWYW4gRGUgVmVsZGUg PGd1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tPG1haWx0bzpndW50ZXJ2YW5kZXZlbGRlY2NA aWNsb3VkLmNvbT4+DQpTdWJqZWN0OiBbT1BTRUNdIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzZWMt djYNCkRhdGU6IDEyIEFwcmlsIDIwMTcgYXQgMDk6Mzk6MjggR01UKzINClRvOiBvcHNlY0BpZXRm Lm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+DQoNClRoaXMgaXMgdG8gb3BlbiBhIHR3byB3ZWVr IFdHTEMgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2 Lg0KSWYgeW91IGhhdmUgbm90IHJlYWQgaXQsIHBsZWFzZSBkbyBzbyBub3cuIFlvdSBtYXkgc2Vu ZCBuaXRzIHRvIHRoZSBhdXRob3IsIGJ1dCBzdWJzdGFudGl2ZSBkaXNjdXNzaW9uIHNob3VsZCBn byB0byB0aGUgbGlzdC4NCg0KDQpJIHdpbGwgY2xvc2UgdGhlIGNhbGwgb24gMjYgQXByaWwgMjAx Nw0KDQoNCkcvDQoNClNlbnQgZnJvbSBpQ2xvdWQNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPUFNFQyBtYWlsaW5nIGxpc3QNCk9QU0VDQGlldGYub3Jn PG1haWx0bzpPUFNFQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb3BzZWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoN Cg== --_000_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E6B302EA3925D41A2172DB5076B7EC2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2UtMToyIDExIDYgMyAy IDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7 DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1 OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlbGF5aW5nIG1lc3NhZ2UgdG8gV0dMQyBkaXNjdXNz aW9uIGFsaWFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Ry88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj52Nm9wcyAmbHQ7djZvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IEVyaWsgS2xpbmUgJmx0O2VrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNk YXksIDE4IEFwcmlsIDIwMTcgYXQgMDk6MzA8YnI+DQo8Yj5UbzogPC9iPkd1bnRlciBWYW4gRGUg VmVsZGUgJmx0O2d1bnRlcnZhbmRldmVsZGVjY0BpY2xvdWQuY29tJmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7djZvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Y2b3BzQGlldGYub3JnJmd0OywgNm1h biAmbHQ7Nm1hbkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0FMVV0gUmU6IFt2 Nm9wc10gRndkOiBbT1BTRUNdIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzZWMtdjY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4yLjEuMi4mbmJzcDsgVXNlIG9mIFVMQXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RpbGw/Jm5ic3A7IFJlYWxseT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTggQXByaWwgMjAx NyBhdCAxNjoxOCwgR3VudGVyIFZhbiBEZSBWZWxkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmd1bnRl cnZhbmRldmVsZGVjY0BpY2xvdWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3VudGVydmFuZGV2ZWxk ZWNjQGljbG91ZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciA2bWFuLCB2Nm9wcywgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EdWUgdG8gdGhlIElQdjYgZm9j dXMgb2YgJnF1b3Q7ZHJhZnQtaWV0Zi1vcHNlYy12NiZxdW90OyB0aGUgT1BTRUMgV0dMQyBmb3Ig dGhpcyBkb2N1bWVudCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gYm90aCA2bWFuIGFzIHY2b3BzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNlbmQg eW91ciBmZWVkYmFjayB0byBPUFNFQyBlbWFpbCBsaXN0LCB3aGVyZSBkaXNjdXNzaW9uIGFyb3Vu ZCB0aGlzIGRvY3VtZW50IHNob3VsZCB0YWtlIHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HLzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3YXJkZWQg bWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Gcm9tOiA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 OyI+R3VudGVyIFZhbiBEZSBWZWxkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmd1bnRlcnZhbmRldmVs ZGVjY0BpY2xvdWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3VudGVydmFuZGV2ZWxkZWNjQGljbG91 ZC5jb208L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90OyI+U3ViamVjdDogW09QU0VDXSBXR0xDIGZvciBkcmFmdC1pZXRmLW9wc2Vj LXY2PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90OyI+RGF0ZTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjEyIEFwcmlsIDIwMTcgYXQgMDk6Mzk6MjggR01UJiM0Mzsy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 Ij5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm9wc2VjQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7Ij5UaGlzIGlzIHRvIG9wZW4gYSB0d28gd2VlayBXR0xDIGZvciZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2Vj LXY2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb3BzZWMtdjY8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDsiPklmIHlvdSBoYXZlIG5vdCByZWFkIGl0LCBwbGVhc2UgZG8gc28gbm93LiBZ b3UgbWF5IHNlbmQgbml0cyB0byB0aGUgYXV0aG9yLCBidXQgc3Vic3RhbnRpdmUgZGlzY3Vzc2lv biBzaG91bGQgZ28gdG8gdGhlIGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyI+SSB3aWxsIGNsb3NlIHRoZSBjYWxsIG9uIDI2 IEFwcmlsIDIwMTc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1T JnF1b3Q7Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7Ij5HLyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13 b3JkIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDsiPlNlbnQgZnJvbSBpQ2xvdWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT1BT RUMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0VDQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T1BTRUNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWM8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_-- --_005_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_ Content-Type: application/pkcs7-signature; name="SMIME Cryptographic Signature.p7s" Content-Description: SMIME Cryptographic Signature.p7s Content-Disposition: attachment; filename="SMIME Cryptographic Signature.p7s"; size=4835; creation-date="Tue, 18 Apr 2017 07:34:30 GMT"; modification-date="Tue, 18 Apr 2017 07:34:30 GMT" Content-ID: <935E66A6C8B18D40A640DE54175B773E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQggXY5kGM7X/stWUIIVZHczEc4XGATbRrh zmdvm0QabKswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE4 MDczMTA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABUI1HCQShBBUPzor9OwSljSG89rU5nMer93cI/OKXlrsYm3jpWQ ZZtEQzBhyxpEgFOqhI7nU6hd9JlSa9UtQULlJUdLNz0kaqE//A0rChfdhxtDwt7pXmtj8BGupQIi 4FP/w5XCUdPjYu/mM8LqNlIJXNKrki3udmV59xiZrmBGQMpCpez3UFz50nfqPoOE3z7XZ9X128Dw XSDG/70NiREf+BhYnl646lGCGTMWIXHkbYvOYA8HPVFFUWSSNmca93PZUTXBvp5Jzn6ZirWebIwK d/uAlSq5W74F0JOIbzzSqvZ1Nj5uP5jAktPMYet/u6lBF73e0jlD2MeemtjFEgI= --_005_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Tue, 18 Apr 2017 07:34:30 GMT"; modification-date="Tue, 18 Apr 2017 07:34:30 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1h aWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCg== --_005_D5DB835BD681472CA26EFE0380C1FFADalcatellucentcom_-- From nobody Tue Apr 18 00:35:49 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 06AA61317B5 for ; Tue, 18 Apr 2017 00:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 L-9hrPhe9bim for ; Tue, 18 Apr 2017 00:35:46 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538C21317B2 for ; Tue, 18 Apr 2017 00:35:46 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id j9so65651764ywj.3 for ; Tue, 18 Apr 2017 00:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6NIlP7JpiDaPcZms3Yprrkm2NLwdBMleOGA3BuSJfS4=; b=cPYcTUXzLLfLMqgtCSB5HcZgqqS0yHwYcH77r8UXFp6JCmDSuEysSJWxeU0yxfUe2d fWPpwvjGYUF53ZQ/JJ0Cj0ii88+6Zpo++r7vG1gLfqJ8vwV/SNXdt3D8k0xD+ygX7aRz d90fZ/2fdAr4k9/VRVdOthuu2UH3QAqk4mZ9tL98vvHH79rWhQ92MdWcozoSdpqlbEHZ KDLcc9IrQIrVrkvlNWo2KhUIkbXFJpzGaLlBe5BnI63CFUgg50aNm5E06wrEojxCb8LW jBI7xO+jV0JKFa9Fx7VpVc0DppQs1pbjXa7++iCeUIvKTdPTpZ0RZQf0TexhXR8a1yBd a5+w== 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=6NIlP7JpiDaPcZms3Yprrkm2NLwdBMleOGA3BuSJfS4=; b=g2ub/AGTYzKKy9faR946bSQTZVy3yp1dMAknG8ndLAn7Wu5B+wjvBwAnOCq0gIqO13 tCEs8K63zzGPOu3QpPedQp29ZMMRGzPJ/JNJJo1Cfwq908RdEjKkZyYJHgnth8Y8Jis8 jrIhJYL1mdqhe23w+dXqKdj+BRbX4zKft4VomCgf2BpJSD8cJgAXXvqBqtaETpc6+Q94 VXBM/WBuB5ZKmIv0vtlzppI1FhTaXUJd6FBASPsfYBgLbPlIENAowY2Wrvn/fgeXszLS dtAmYMcIEDfGO2zF97xoLoKn5LmQC7MQYLJxHmCbexwWHirz0LOHxHveCLAFvoftKIhJ Zv1w== X-Gm-Message-State: AN3rC/7dYq8FPH4TOYidhLWC6R+IDjdi3Ximlx98YbYPjvaYOLOJZPH9 7BSNKUDjRKk+M7tYuH/96aa59eAHElEL X-Received: by 10.129.115.212 with SMTP id o203mr20619079ywc.55.1492500945370; Tue, 18 Apr 2017 00:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Tue, 18 Apr 2017 00:35:24 -0700 (PDT) In-Reply-To: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Erik Kline Date: Tue, 18 Apr 2017 16:35:24 +0900 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "opsec@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11492530b3e803054d6bf44d" Archived-At: Subject: Re: [OPSEC] FW: [ALU] Re: [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 07:35:48 -0000 --001a11492530b3e803054d6bf44d Content-Type: multipart/alternative; boundary=001a11492530ad63c6054d6bf482 --001a11492530ad63c6054d6bf482 Content-Type: text/plain; charset=UTF-8 Didn't we already have a bunch of discussion about this in v6ops and work very carefully to come to text? On 18 April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > Relaying message to WGLC discussion alias > > > > G/ > > > > *From: *v6ops on behalf of Erik Kline < > ek@google.com> > *Date: *Tuesday, 18 April 2017 at 09:30 > *To: *Gunter Van De Velde > *Cc: *"v6ops@ietf.org" , 6man <6man@ietf.org> > *Subject: *[ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 > > > > 2.1.2. Use of ULAs > > > > Still? Really? > > > > On 18 April 2017 at 16:18, Gunter Van De Velde < > guntervandeveldecc@icloud.com> wrote: > > Dear 6man, v6ops, > > > > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > > > > Kind Regards, > > G/ > > > > Begin forwarded message: > > > > *From: *Gunter Van De Velde > > *Subject: [OPSEC] WGLC for draft-ietf-opsec-v6* > > *Date: *12 April 2017 at 09:39:28 GMT+2 > > *To: *opsec@ietf.org > > > > This is to open a two week WGLC for https://tools.ietf.org/ > html/draft-ietf-opsec-v6. > > If you have not read it, please do so now. You may send nits to the > author, but substantive discussion should go to the list. > > > > I will close the call on 26 April 2017 > > > > G/ > > Sent from iCloud > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > --001a11492530ad63c6054d6bf482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Didn't we already have a bunch of discussion about thi= s in v6ops and work very carefully to come to text?

On 18 April 2017 at 16:34, Van De V= elde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.c= om> wrote:

Relaying message to WGLC discussion alias

=C2=A0

G/

=C2=A0

F= rom: v6ops <v6ops-bounces@ietf.org&g= t; on behalf of Erik Kline <ek@google.com>
Date: Tuesday, 18 April 2017 at 09:30
To: Gunter Van De Velde <guntervandeveldecc@icloud.com>
Cc: "v6ops@= ietf.org" <= v6ops@ietf.org>, 6man <6man@ietf.org>
Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6=

=C2=A0

2.1.2.=C2=A0 Use of ULAs

=C2=A0

Still?=C2=A0 Really?

=C2=A0

On 18 April 2017 at 16:18, Gunter Van De Velde <<= a href=3D"mailto:guntervandeveldecc@icloud.com" target=3D"_blank">guntervan= develdecc@icloud.com> wrote:

Dear 6man, v6ops,

=C2=A0

Due to the IPv6 focus of "draft-ietf-opsec-v6&q= uot; the OPSEC WGLC for this document may be of interest to both 6man as v6= ops.

=C2=A0

Please send your feedback to OPSEC email list, where= discussion around this document should take place.

=C2=A0

Kind Regards,

G/



Begin forwarded message:

=C2=A0

From: Gunter Van De Velde <guntervandeveldecc@icloud.com>=

Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

Date: 12 April 2017 at 09:39:28 GMT+2

=C2=A0

This is to open a two week WGLC for=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-opsec-v6.

If you have not read it, please do so now. You may send nits to the author= , but substantive discussion should go to the list.



I will close the call on 26 April 2017



G/=C2=A0

Sent from iCloud=
=

_______________________________________________=
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

=C2=A0


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

=C2=A0


--001a11492530ad63c6054d6bf482-- --001a11492530b3e803054d6bf44d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg4iL010NH5LQ6yEnSdx515mphiCzn4zTo M5JVmZPRTdUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE4 MDczNTQ1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAFnCQNNvDCtnYsdfvKmw/QYDt6PtT6xPXSJV4jK6SqOuhUu+Ehuo UBGfGHNfwMTsDKG+7uYD8cfs84IQ/2OfYhSwFkZ1+9vBaaDsvCoZRBEpYfsdn1HUaWK/mWxepnHr 4n7aUAD/08+XH0zSfVOx9hG4Dqpabzab3jrtxjfOuEQv4ilnrSIjWZjHufOC5fJMMBmUosPRNQ9F wboQR/Ss2R1XbzSBpCaXIFJohW9VsL+/JkFs8OeZxazqBZSht1K6i3s/11ETNNXG0IN2Wq+iDtSG cyf9Ol7rRxWBvsMMan98EdHGK+zlKzW4dmKF4X/ykWM2S4mD1corPFhRu/HBbQs= --001a11492530b3e803054d6bf44d-- From nobody Tue Apr 18 00:51: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 AD3C41317EC for ; Tue, 18 Apr 2017 00:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QKa1hcMdU2xB for ; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 09F1B1317D6 for ; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r69so70978153vke.2 for ; Tue, 18 Apr 2017 00:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=o0Pazzmr3JUJJAueR9nW7PbqfH1OK0ptbJzpzSq4qYy0lbs0OmhUjxnNfxzSFi9M43 akEg8D0gF2uD0Dwy6gUPJBAtH8lgXHtKHw5xQ3+MBnpJiqBuEClh45PkZkGT6TNlnlut uMFS/dBlSYJ5Tub14TQ+Ve7QUFu9B2PBOr3IJrPUOE/qMEslAEFZumqZ/EtNcYYwRUqv Vp7sfyqcfCLKxyL4q4CAMmjhARAtwd9SYE8YRiS/njg438bqfgs/RttV3u4f5vXs0PEl L/HnG0sAPvoFIY/ItsoyGyXD4xTQERPsp3Z/yMwrhabuYxWMmm0rgFdSByJkRDbnDP5X H6Cw== 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=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=iVHVDZs7r2SW6/SAAUDPIdA/yBWgHR9nXJPZehg3hvjVZf+8rmokW2RvJgexsZrYxR RY7yeMpP1Z+R8/TMqMlYluje7xmDt51ab3Uwqnds9AlYV/Ar9Y5hBOuu+rIjG2sgHGBr eiH2mqDnUFUZ4Sisazu+JXVf1ZNqMLpogB/fsvtw+3uU5r9bbcs6r8FVyTQSptSfdVhb J7CbWiYB6rg/rcG0RQ9mcSzqdn7p/2EMa7D8uH9NMXIEkTSGbSLpS8z60yoRX2n35BY+ MOUo8DWGvanqm/LGEcOW6xzZfTAq7bzArLdnIgm+L7T5vBju1iBkvOH6OAALNsOcHRuD tx0Q== X-Gm-Message-State: AN3rC/7BkJQX2jrRbpzxLkLkdeme0aRKoJ2zx2dq+ptVChKiKPE6Aprc YcWtuXLMZqrSAkdA15AspJpsiksk+w1X X-Received: by 10.31.146.12 with SMTP id u12mr4233404vkd.102.1492501899987; Tue, 18 Apr 2017 00:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Tue, 18 Apr 2017 00:51:19 -0700 (PDT) In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Lorenzo Colitti Date: Tue, 18 Apr 2017 16:51:19 +0900 Message-ID: To: Gunter Van De Velde Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a1142f13093ca92054d6c2d3a Archived-At: Subject: Re: [OPSEC] [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 07:51:43 -0000 --001a1142f13093ca92054d6c2d3a Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > I share Erik's concern around the ULA section. The has been controversial for years. For example, see the thread starting at https://www.ietf.org/mail-archive/web/opsec/current/msg02012.html . The vast majority of the text in 2.1.2 has not changed in any substantial way since that heated debate, as shown by the diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-opsec- v6-08.txt&url2=draft-ietf-opsec-v6-11.txt . Do we really have to have that debate again? --001a1142f13093ca92054d6c2d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde <guntervandev= eldecc@icloud.com> wrote:
Due to the = IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this docum= ent may be of interest to both 6man as v6ops.

Please sen= d your feedback to OPSEC email list, where discussion around this document = should take place.

I shar= e Erik's concern around the ULA section. The has been controversial for= years. For example, see the thread starting at=C2=A0h= ttps://www.ietf.org/mail-archive/web/opsec/current/msg02012.html<= /a> .


Do we really have to have that debate again?
--001a1142f13093ca92054d6c2d3a-- From nobody Tue Apr 18 01:21:56 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 9245A126DEE for ; Tue, 18 Apr 2017 01:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 313gQhFCbhMN for ; Tue, 18 Apr 2017 01:21:53 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 29995128D2E for ; Tue, 18 Apr 2017 01:21:53 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 08:21:53 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D082AD788B for ; Tue, 18 Apr 2017 01:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:mime-version:subject:date:references:to :in-reply-to:message-id; s=selector1; bh=lli6D7nMX44LF/S55XEnM0h G11g=; b=NX8QXsV3QgY8nf1NeRGOA7M5ux5dSE8DmWg0vZg/FdeFGFGcHr7Xlu3 OdxeZLPp6rghHNErS0pp0NmY4MJsarNy663Wpw1VBVCfbQ9xs/1/wfRQrVrVO+59 3na8Y8Lbn/tal8ll/WDEJC5I/Z6SloWyYY0A0TxBfO4k2+4xIKg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:mime-version:subject:date:references:to :in-reply-to:message-id; q=dns; s=selector1; b=kTM0KaF4IrpZxnVzN O2hAuoOCNMCIjrouP24hqqy0R8XOtPzVkYqjBKtAX7hZALpSiBqDLKtgmcnEDpi1 UBwYx870HuE8hq3XT8ag09x6w6zKp4mjEPzdPFAHGZJBXV/c4Alc1mHt82LL7B7O rSpIp5v9wlvRBukiXrgYtMjB9s= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 73B51D788A for ; Tue, 18 Apr 2017 01:21:52 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E9764AA073ED for ; Tue, 18 Apr 2017 10:21:50 +0200 (CEST) From: otroan@employees.org Content-Type: multipart/signed; boundary="Apple-Mail=_A75483FE-CB0B-4FE2-8888-12608549CC3B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 10:21:50 +0200 References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> To: opsec@ietf.org In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 08:21:54 -0000 --Apple-Mail=_A75483FE-CB0B-4FE2-8888-12608549CC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few initial comments. Draft is not quite ready. Section 2.1.3: 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. The ping pong attack is mitigated in RFC4443. I am not convinced there is justification that this document should = recommend /127 for "security reasons". Section 2.1.4: The description of the IID needs to be updated with the latest = recommendations in 4291bis etc. The IID is no longer recommend to be created by MAC address for = example. It might also be worth clarifying that the operator can only control a = host's choice of IID / privacy by disabling SLAAC altogether. Section 2.1.6: "DNS is often used for malware activities"... That just doesn't read = well. I presume you aren't proposing to disable DNS? ;-) Section 2.2: I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... Section 2.2.2: This section should be updated to reflect the new text in 2460bis. The = reference to hbh-header-handling is no longer needed. Section 2.2.3 s/Fragment Extension Header/Fragment header Same for Hop by Hop options header. Please get the names of the headers = correct. Section 2.3.2: Consider Secure DHCPv6? Section 2.3.3: I don't think those individual drafts are "actively" discussing methods = to rate limit RA anymore. Wirth update / rewrite with summary from those = discussions. Section 2.7.2 Remove the historic tunnel mechanisms? ISATAP, Teredo, 6to4? Section 2.7.2.7: DS-lite is not a translation mechanism. Section 2.7.2.8 s/tunnel and encapsulation/encapsulation and translation/ Section 2.7.3.1: Why in an IPv6 document? Section 3.1: In general update references. e.g. ipv6-eh-filtering is outdated. I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. The advice in ipv6-eh-filtering is essentially to ossify the network. Section 5: Reference to balanced-ipv6-security... I don't think it is worth = referencing an expired draft. Why not summarise the points in a = paragraph? Ole > On 18 Apr 2017, at 09:18, Gunter Van De Velde = wrote: >=20 > Dear 6man, v6ops, >=20 > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. >=20 > Please send your feedback to OPSEC email list, where discussion around = this document should take place. >=20 > Kind Regards, > G/ >=20 >> Begin forwarded message: >>=20 >> From: Gunter Van De Velde >> Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 >> Date: 12 April 2017 at 09:39:28 GMT+2 >> To: opsec@ietf.org >>=20 >> This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6. >> If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >>=20 >> I will close the call on 26 April 2017 >>=20 >> G/ >> Sent from iCloud >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A75483FE-CB0B-4FE2-8888-12608549CC3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9cyeAAoJEL7aWKiYQt92G3cQAMJHuZYhbmFQrhzftBDBneYw OI+wlr0xtsxA9ZTHj6k6SRCoQZIf+vJ91cY7ZW+WzO/79/6mDi2XlCfN9TA7ttjN ohCpwxg7v7Fs/l3tLcrKWRmQsdMCOL+hYoAb/vFSyoz8vYgw0lfhUKixSyjQZHhM r34OEbEWnJNAITcK5494HfUhsRVTQsO/8OP65Ouk05zSf+0Q9pLZ02ELRNUw8HTO wtA+Mjp7xvl/vx8Gf5RXqg1J+BiD4dwZKEy79JHn2Le48o3VgASNoEY53K169F8w kK8+XiLOTnmMkmesrfE/ubpmHLdagFwu1DUR5tMs6c+5wP7/PkSL0jH1qvKOYL8S VaIpwjUSSWNDr7Az7kI6cnGofotkvfPXD88QaRTUAzLokprOaKPQ1aTUtVTX98T9 98tHMVIVmoN6kyy+JsmfZypaoED9ab107ikYbhXQ0vVbD3Zbsqg6RWSNvcIVLJCm k2DZFR2oWknwPbu7tANCX4RvOjdnl7JKuXsV0CU5czRX6/Vf3ppJVR1o5EXLoQF5 Y0lE9WUEGbrrt8s85XzkSoS/8yGI+XH6RwGrsc6PzJ3q+6tSm9PgteufuwlR7c+u ro27Z7EC2Vy6Sl3QtKXshEDuI+FsyivltQT0dyp4FtLi4ZWwFsYGHp6quuKyoY1N KU5nXbhOvJtZg2CmJqap =iAS/ -----END PGP SIGNATURE----- --Apple-Mail=_A75483FE-CB0B-4FE2-8888-12608549CC3B-- From nobody Tue Apr 18 04:16:44 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 F28ED129AC9; Tue, 18 Apr 2017 04:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 ddCUlZTc0RVJ; Tue, 18 Apr 2017 04:16:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAED129BEE; Tue, 18 Apr 2017 04:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14673; q=dns/txt; s=iport; t=1492514201; x=1493723801; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jxAPa7X47Bz/fcN/toV2OcTC64l3dlwyRDoSQ7xNT0M=; b=jSiXSwbbFRmqLz2MkYLH7PSu1Z9s4EQMdB28S1TpII3kFmIXE+JMXcKW w7/nyVBH6G8y9F9gobttmQ4w+eAOz+KjRtTzZ3cHV4pKQSJUok32cHzpq l0EWoEWAkLEuPdUkzfbGcEORw9LUbmbJ0KCHhAAMhs7wxLkrf9HfBlBL8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQAl9fVY/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm46K2GBCweNdJFgkC2FNIIPIQEKhXgCg2o/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBK0EbAgEIEQMBAQEoBycLFAkIAgQBEgiJeQMVDqwwhzYQg1oBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYgvgxiEKREBBjYWhS8FljSGbgGHA4tdggm?= =?us-ascii?q?FMYNdhjqUDQEfOH0IYxVEhGYcgWN1hl2BIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208,217";a="413793099" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 11:16:34 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3IBGY35007277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 11:16:34 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 06:16:33 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 06:16:33 -0500 From: "Bernie Volz (volz)" To: "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" Thread-Topic: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 Thread-Index: AQHSuBQD3Gqzthh24kWI/GnWLTvXrqHK+IUA Date: Tue, 18 Apr 2017 11:16:33 +0000 Message-ID: <3b8f18bb5b3a456798a7378afea2c27e@XCH-ALN-003.cisco.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_3b8f18bb5b3a456798a7378afea2c27eXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 11:16:43 -0000 --_000_3b8f18bb5b3a456798a7378afea2c27eXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: In 2.6.1.5. Stateful DHCPv6 Lease: In short, the DHCPv6 lease file is less interesting than in the IPv4 era. DHCPv6 servers that keeps the relayed data-link layer address in addition to the DUID in the lease file do not suffer from this limitation. You should add an informative reference to rfc6939, Client Link-Layer Addre= ss Option in DHCPv6. This is a way to obtain the data-link layer address of= the client (at least in relayed environments). I'm not really sure how DHC= Pv6 servers could do this without this option as without it there is no way= for the server to obtain the data-link layer address of the client otherwi= se. Also, it should be "DHCPv6 servers that keep ..."? - Bernie From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gunter Van De Veld= e Sent: Tuesday, April 18, 2017 3:18 AM To: 6man@ietf.org; v6ops@ietf.org Subject: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 Dear 6man, v6ops, Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this docu= ment may be of interest to both 6man as v6ops. Please send your feedback to OPSEC email list, where discussion around this= document should take place. Kind Regards, G/ Begin forwarded message: From: Gunter Van De Velde > Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 Date: 12 April 2017 at 09:39:28 GMT+2 To: opsec@ietf.org This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-= opsec-v6. If you have not read it, please do so now. You may send nits to the author,= but substantive discussion should go to the list. I will close the call on 26 April 2017 G/ Sent from iCloud _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_3b8f18bb5b3a456798a7378afea2c27eXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

In 2.6.1.5.  Stateful DHCPv6 Lea= se:

 

   In short, the DHCPv6 lease file i= s less interesting than in the IPv4

   era.  DHCPv6 servers that ke= eps the relayed data-link layer address

   in addition to the DUID in the le= ase file do not suffer from this

   limitation. 

 

You should add an informative referen= ce to rfc6939, Client Link-Layer Address Option in DHCPv6. This is a way to= obtain the data-link layer address of the client (at least in relayed environments). I’m not really sure how DHCPv6 s= ervers could do this without this option as without it there is no way for = the server to obtain the data-link layer address of the client otherwise.

 

Also, it should be “DHCPv6 serv= ers that keep …”?

 

-   =        Bernie

 

From: v6ops [mailto:v6ops-bounces@ie= tf.org] On Behalf Of Gunter Van De Velde
Sent: Tuesday, April 18, 2017 3:18 AM
To: 6man@ietf.org; v6ops@ietf.org
Subject: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6

 

Dear 6man, v6ops,

 

Due to the IPv6 focus of "draft-ietf-opsec-v6&q= uot; the OPSEC WGLC for this document may be of interest to both 6man as v6= ops.

 

Please send your feedback to OPSEC email list, where= discussion around this document should take place.

 

Kind Regards,

G/



Begin forwarded message:

 

From: Gunter Van= De Velde <guntervandev= eldecc@icloud.com>

Subject: [OPSEC] WGLC for draft-ietf-opsec-v6

Date: 12 April 2= 017 at 09:39:28 GMT+2

 

This is to open a two week WGLC for https://tools.ietf.org/html/draft-iet= f-opsec-v6.

If you have not read it, please do so now. You may send nits to= the author, but substantive discussion should go to the list.<= /o:p>



I will close the call on 26 April 2017



G/ 

Sent from i=
Cloud

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

 

--_000_3b8f18bb5b3a456798a7378afea2c27eXCHALN003ciscocom_-- From nobody Tue Apr 18 04:44:57 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 806F212EAF6; Tue, 18 Apr 2017 04:44:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 kip--Hzj8hW3; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A8129481; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 11:44:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1DBD9D788B; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=yhQgaSTwtKWUDSSleodGkfbxePY=; b= q13bhEs4npatv82KBDKrd+CmsB4qAm2xEDT/miLKv5zZPq+efZFWoSQE3LPUSZtm Kma76DIh95shECkDY+lDG5eKKCJWeqWnKTk2dwBVTOAjtAKAS/spy1pWVNaJbdAH TQJaT+Jvh/WM8MhbIBLxk8Yck5oUeQWkQdRCEoz3utg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=r6rflq/j3c7N1irgYXSwB8Q ZiMCn5IulXjW8OpwoIR2L6PkCXY8NjcbX5cs5mVoW/tFUr1gEyrpAo+PxAiQ1iC4 nu3NPqbLxiZLGPL0VC+W4s7hAgbEbvX7IFgPE5cxKK/yizpJNNvxwW3lTDB+shqW GvwmQTBcRs4HrKgm0JSQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 63663D788A; Tue, 18 Apr 2017 04:44:46 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DD2F8AA3FB43; Tue, 18 Apr 2017 13:44:44 +0200 (CEST) From: otroan@employees.org Message-Id: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 13:44:44 +0200 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 11:44:49 -0000 --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC Content-Type: multipart/alternative; boundary="Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C" --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > On 18 Apr 2017, at 13:10, Fernando Gont wrote: >=20 > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >>=20 >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. >=20 > Agreed on this. >=20 >=20 >> The ping pong attack is mitigated in RFC4443. >=20 > I must be missing something.. what does RFC4443 have to do with this? = A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... https://tools.ietf.org/html/rfc4443#section-3.1 = One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. Most implementations I'm aware of now implement this. >> I am not convinced there is justification that this document should = recommend /127 for "security reasons". >=20 > Besides ping-pong, there's NCE. While I do agree that the real = solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. Neighbour cache exhaustion has to be mitigated anyway. On router-router links that's a relatively simple problem compared to = links with hosts. I'm still not convinced that /127 should be recommended over any of the = other addressing models for router to router links. /64, link-local only, /128s. >> Section 2.2: >> I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... >=20 > The packet structure does make a big difference. For instance, it's > trivial to find (in IPv4-based packets) the upper layer protocol type > and protocol header, while in IPv6 it actually isn't. It isn't supposed to be. >> Section 2.3.2: >> Consider Secure DHCPv6? >=20 > Question: is that doable? (i.e., widely supported) You expect this document to have a short lifetime? (Which I guess is the exact problem of publishing this type of advice as = an IETF RFC). >> Section 3.1: >> In general update references. e.g. ipv6-eh-filtering is outdated. >> I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. >> The advice in ipv6-eh-filtering is essentially to ossify the network. >=20 > Have you read the I-D? Because the I-D boils down to: "pass all EHs > unless they are known to be very harmdful". Hmm, I see the latest opsec version has put this right, thanks. I must have read the earlier individual draft, cause that said "should = drop HBH". Best regards, Ole --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 18 Apr 2017, at 13:10, Fernando = Gont <fgont@si6networks.com> wrote:

On 04/18/2017 09:18 AM, otroan@employees.org wrote:
A few initial comments. Draft is not quite = ready.

Section 2.1.3:
6164 = does not _recommend_ /127 it _permits_ /127 on p2p links.

Agreed on this.


The ping = pong attack is mitigated in RFC4443.

I must be missing something.. what does RFC4443 have to do = with this? A
ping pong attack does not require the attack = packets to be ICMPv6 echo
requests...

https://tools.ietf.org/html/rfc4443#section-3.1
  One specific = case in which a Destination Unreachable message is sent
  with a code 3 is = in response to a packet received by a router from a
  point-to-point = link, destined to an address within a subnet assigned
  to that same = link (other than one of the receiving router's own
  addresses). =  In such a case, the packet MUST NOT be forwarded back
  onto the arrival = link.

Most implementations I'm aware of now implement = this.

I am not convinced there is justification that this document = should recommend /127 for "security reasons".

Besides ping-pong, there's NCE. = While I do agree that the real solution
to the above two = issues is *not* to use a /127, this document being an
operational one, I can see why the authors may want to = recommend /127.

Neighbour cache exhaustion has to be mitigated = anyway.
On router-router links = that's a relatively simple problem compared to links with = hosts.
I'm still not convinced that = /127 should be recommended over any of the other addressing models for = router to router links.
/64, link-local only, /128s.

Section 2.2:
I am not sure that extension headers are one of the most = critical differentiators between IPv4 and IPv6. IPv4 had variable length = options...

The packet = structure does make a big difference. For instance, it's
trivial to find (in IPv4-based packets) the upper layer = protocol type
and protocol header, while in IPv6 it = actually isn't.

It isn't supposed to be.

Section 2.3.2:
Consider Secure DHCPv6?

Question: is that doable? (i.e., widely supported)

You expect this document to = have a short lifetime?
(Which I guess is the exact problem of publishing this = type of advice as an IETF RFC).

Section 3.1:
In general update references. e.g. ipv6-eh-filtering is = outdated.
I question referencing opsec-ipv6-eh-filtering. = It has wrong and outdated advice. E.g. on section of HBH header.
The advice in ipv6-eh-filtering is essentially to ossify the = network.

Have you read the = I-D? Because the I-D boils down to: "pass all EHs
unless = they are known to be very harmdful".

Hmm, I see the latest opsec = version has put this right, thanks.
I must have read the earlier individual draft, cause = that said "should drop HBH".

Best regards,
Ole= --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C-- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9fwsAAoJEL7aWKiYQt925cQP/0VXnKmWVBwsBsv4TG6QeGWA Ro+pucXspLl6nwv5QZKYtuGOSe13QzrQFo/lBN7bh5MV6YCfTxdxTvSUFBfb3Cms 2xtye4MyZppKNXLwjnPd57kapsPLpm2YGPG545F6Ccmy88YcnySlMxlSSSwbmYt8 52fpfV+wPEjR9kCO65MzUAyv0yXBv6aG5O3n64PMuTVSzik8ZijwH8Vh2ZfixAEz 0W1bgqxTCtf3GU2Sxx+5cenhhxt9dTbyKgA8hiwbQjikW2zzKdFYHAwuBJbWT+sQ Omudl8eQm6zGJxx3OlxP2hCTDI1v8GFUBX0zyTNPPO/jUWqpmzTxSXcFd8lP10j+ lY5v0RmsdytE8FsPiDpMOorT2qsuz2nS3zyKGErwSBjodcmf27h2c9ZqGKxosqFM GG51DbR4cvuyV6WxoDtOALvpMEZutwiR0JdBSG22hCoJX8KDz0p9TddzEux8pc5l APwpEHa9uh1sZ9sgCdncYQrgQBJOpfoALJIGC2OcEQeMEH6UM8npLueppvB1J/ul F612k+xluMFHj6XrYMLhRfTEoo2Qi6w/R7nnIn7XNQf5qas89TzrCQivq0Tj0Ur5 MdzUo/IEqpvKNSIczJUmgp779bX6/xpljy1Td7GbBtwjusWcs3KxazmWJPFc4itH HTmkfsaUzZk/P0ed9b0F =1jo3 -----END PGP SIGNATURE----- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC-- From nobody Tue Apr 18 04:54:51 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 E3454129B84 for ; Tue, 18 Apr 2017 04:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfeLhO-Q9rLE for ; Tue, 18 Apr 2017 04:54:48 -0700 (PDT) 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 3BC67126DC2 for ; Tue, 18 Apr 2017 04:54:48 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 5EDC98094B; Tue, 18 Apr 2017 13:54:43 +0200 (CEST) References: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> To: "'opsec@ietf.org'" From: Fernando Gont X-Forwarded-Message-Id: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Message-ID: <225b3c0e-2e79-373a-0017-7dc410367d21@si6networks.com> Date: Tue, 18 Apr 2017 12:41:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSEC] Fwd: Re: [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 11:54:50 -0000 fwd'ing, since there was a typo in the original email... -------- Forwarded Message -------- Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 12:10:37 +0100 From: Fernando Gont To: otroan@employees.org, opsec@ietf.ortg CC: Gunter Van De Velde , v6ops@ietf.org Operations , 6man@ietf.org On 04/18/2017 09:18 AM, otroan@employees.org wrote: > A few initial comments. Draft is not quite ready. > > Section 2.1.3: > 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. Agreed on this. > The ping pong attack is mitigated in RFC4443. I must be missing something.. what does RFC4443 have to do with this? A ping pong attack does not require the attack packets to be ICMPv6 echo requests... > I am not convinced there is justification that this document should recommend /127 for "security reasons". Besides ping-pong, there's NCE. While I do agree that the real solution to the above two issues is *not* to use a /127, this document being an operational one, I can see why the authors may want to recommend /127. > Section 2.2: > I am not sure that extension headers are one of the most critical differentiators between IPv4 and IPv6. IPv4 had variable length options... The packet structure does make a big difference. For instance, it's trivial to find (in IPv4-based packets) the upper layer protocol type and protocol header, while in IPv6 it actually isn't. > Section 2.3.2: > Consider Secure DHCPv6? Question: is that doable? (i.e., widely supported) > Section 3.1: > In general update references. e.g. ipv6-eh-filtering is outdated. > I question referencing opsec-ipv6-eh-filtering. It has wrong and outdated advice. E.g. on section of HBH header. > The advice in ipv6-eh-filtering is essentially to ossify the network. Have you read the I-D? Because the I-D boils down to: "pass all EHs unless they are known to be very harmdful". Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 . From nobody Tue Apr 18 06:11: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 6CDAB12EBBB; Tue, 18 Apr 2017 06:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giy4j33YWZqD; Tue, 18 Apr 2017 06:11:33 -0700 (PDT) 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 DA0951274D0; Tue, 18 Apr 2017 06:11:32 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 D9ADB80D2A; Tue, 18 Apr 2017 15:11:30 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Date: Tue, 18 Apr 2017 13:12:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 13:11:35 -0000 Hi, Ole, On 04/18/2017 12:44 PM, otroan@employees.org wrote: >>> The ping pong attack is mitigated in RFC4443. >> >> I must be missing something.. what does RFC4443 have to do with this? A >> ping pong attack does not require the attack packets to be ICMPv6 echo >> requests... > > https://tools.ietf.org/html/rfc4443#section-3.1 > One specific case in which a Destination Unreachable message is sent > with a code 3 is in response to a packet received by a router from a > point-to-point link, destined to an address within a subnet assigned > to that same link (other than one of the receiving router's own > addresses). In such a case, the packet MUST NOT be forwarded back > onto the arrival link. > > Most implementations I'm aware of now implement this. Why wouldn't an attacker send *any* packet meant for the p2p link, but that not correspond to the address of any of the two endpoints? i.e., I don't see the need to focus on a specific kind of packet... I guess I'm missing something? >>> I am not convinced there is justification that this document should >>> recommend /127 for "security reasons". >> >> Besides ping-pong, there's NCE. While I do agree that the real solution >> to the above two issues is *not* to use a /127, this document being an >> operational one, I can see why the authors may want to recommend /127. > > Neighbour cache exhaustion has to be mitigated anyway. > On router-router links that's a relatively simple problem compared to > links with hosts. > I'm still not convinced that /127 should be recommended over any of the > other addressing models for router to router links. > /64, link-local only, /128s. How do you mitigate it when the implementation does not limit the number of NC entries? (i.e., operationally) >>> Section 2.2: >>> I am not sure that extension headers are one of the most critical >>> differentiators between IPv4 and IPv6. IPv4 had variable length >>> options... >> >> The packet structure does make a big difference. For instance, it's >> trivial to find (in IPv4-based packets) the upper layer protocol type >> and protocol header, while in IPv6 it actually isn't. > > It isn't supposed to be. Which for people running networks translates to "broken by design". >>> Section 2.3.2: >>> Consider Secure DHCPv6? >> >> Question: is that doable? (i.e., widely supported) > > You expect this document to have a short lifetime? > (Which I guess is the exact problem of publishing this type of advice as > an IETF RFC). I didn't even think about the lifetime. But I wouldn't suggest a mitigation that isn't doable at the time of publication. If Secure DHCPv6 is not widely implemented, this would be like saying "secure ND with SEND" ("yeah... in your dreams!"). FWIW, I do support this document. I think it contains valuable and much needed information. >>> Section 3.1: >>> In general update references. e.g. ipv6-eh-filtering is outdated. >>> I question referencing opsec-ipv6-eh-filtering. It has wrong and >>> outdated advice. E.g. on section of HBH header. >>> The advice in ipv6-eh-filtering is essentially to ossify the network. >> >> Have you read the I-D? Because the I-D boils down to: "pass all EHs >> unless they are known to be very harmdful". > > Hmm, I see the latest opsec version has put this right, thanks. > I must have read the earlier individual draft, cause that said "should > drop HBH". We've certainly been improving th document as part of the process. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 06:15:55 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 14D4512EBD5; Tue, 18 Apr 2017 06:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 6RIgZyp2WSJS; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A553412EB9C; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:15:38 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2D5EFD788D; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=VRRaZZt47pYL+C8HqUQlxUV+4A8=; b= qRofvgPqgmbdeHJuLshgb/LHYBH/DXLNyrnfWVC60DDcV27OzBZGGVqtBpxMuv+M GpXYLa9Cz/Cf78DRI+oG/DqvTaAkru9qtqIpb2/hvBPbN85mpPNhi5AThQQCvzbc KPt8yDDV317sZeQmhTObSZ7s2bYcP1VWe3mcIXxhdMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=GmL5CuWPXegXUNSl0kbxp7N 3xYNN5yOBZGJk7hS1gxapPYRbzisYF6K1k0ORqagxlroaIb6RSnAMiCOkIL0qxVJ qoaMWeRuYkux1rM3/b13aUO2yUgNPtJnD44d5KHJUgZQ8mLA6ugOpRLk3NxUWibE NL9f3xxlK2eQKFU4evI0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 0187DD788B; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7383CAA599EB; Tue, 18 Apr 2017 15:15:36 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 15:15:35 +0200 In-Reply-To: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 13:15:40 -0000 --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >>>> The ping pong attack is mitigated in RFC4443. >>>=20 >>> I must be missing something.. what does RFC4443 have to do with = this? A >>> ping pong attack does not require the attack packets to be ICMPv6 = echo >>> requests... >>=20 >> https://tools.ietf.org/html/rfc4443#section-3.1 >> One specific case in which a Destination Unreachable message is sent >> with a code 3 is in response to a packet received by a router from a >> point-to-point link, destined to an address within a subnet assigned >> to that same link (other than one of the receiving router's own >> addresses). In such a case, the packet MUST NOT be forwarded back >> onto the arrival link. >>=20 >> Most implementations I'm aware of now implement this. >=20 > Why wouldn't an attacker send *any* packet meant for the p2p link, but > that not correspond to the address of any of the two endpoints? >=20 > i.e., I don't see the need to focus on a specific kind of packet... I > guess I'm missing something? Yes, you are missing something. RFC4443 specifies what behaviour should be if a router receives a packet = on a point to point link that would end up being forwarded back out the = same link. The specified behaviour is drop and send destination = unreachable. That solves the problem for any packet obviously. And any prefix length = assigned to the link. Cheers, Ole --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hF3AAoJEL7aWKiYQt92qK0P/jzKw4Kw6gaw/J06uvjnuGLP yCa0NQOhIW92Txx4YXNkbP/6YpAdiPNkxfFoDva6FUmSkKPZ05EgQhKH/bdfo/2g BoQgs8WjDidVnk2YApf69UJ2gUD2VNVYai7eOIrVwdmdF9EXLadGKHXR5JTum9VT gSR8iuyhbtF2QqT2ZU14Yq1a05to61FmdPN0gX9knqCvsyag9phEQV8H2CUta/kn XrnqKHQM9KohvX3YhdmpsB95slFRePfDZfNobm2bPxGoWwAuqpP5Cr5GCQGBceYA OPRjFqkxb9fNYeDYKbRLJUWlcPfe3RMe63XVYryr2vMmFVrsgJCp/0k4mqPiHlwv dO2YLUwzelaiUDWWzDwKC11PK2fphIXmWuPe8KYqtcGMRrXwdQoDnDKw4TZydfqG cBKtxY9t2lQKOoPiGn888fPW24jPNiVk/ks9pf1alvfO99GnNWBjjWgYEljpy9dZ nPdwH1ZYOFaiJ86gK9f82QSz7/BWS/uWUIk66tRicQ9Z3YE5BcqtceyjxhPAegCu p+LaKbqAQWnKJGyXpSfCy7bJDSCCkFupu2std99JTPhqoquzvdG4VGiaBsr1LAVE zuSK3MJxeGuzoxqDGg3TT6Exj3Q+NWSOIAqO3Z3cxvUGc/0RygYcTJ/0Ljzdi8LL 9ZKMWpNJNryByg2WGPSC =w9er -----END PGP SIGNATURE----- --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4-- From nobody Tue Apr 18 06:27:41 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 07D2912EBFD; Tue, 18 Apr 2017 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6afuF0QdKh0; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) 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 2245D12EBFB; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 48AC68013E; Tue, 18 Apr 2017 15:27:32 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Date: Tue, 18 Apr 2017 14:27:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 13:27:40 -0000 On 04/18/2017 02:15 PM, otroan@employees.org wrote: > Fernando, > >>>>> The ping pong attack is mitigated in RFC4443. >>>> >>>> I must be missing something.. what does RFC4443 have to do with >>>> this? A ping pong attack does not require the attack packets to >>>> be ICMPv6 echo requests... >>> >>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>> in which a Destination Unreachable message is sent with a code 3 >>> is in response to a packet received by a router from a >>> point-to-point link, destined to an address within a subnet >>> assigned to that same link (other than one of the receiving >>> router's own addresses). In such a case, the packet MUST NOT be >>> forwarded back onto the arrival link. >>> >>> Most implementations I'm aware of now implement this. >> >> Why wouldn't an attacker send *any* packet meant for the p2p link, >> but that not correspond to the address of any of the two >> endpoints? >> >> i.e., I don't see the need to focus on a specific kind of packet... >> I guess I'm missing something? > > Yes, you are missing something. RFC4443 specifies what behaviour > should be if a router receives a packet on a point to point link that > would end up being forwarded back out the same link. The specified > behaviour is drop and send destination unreachable. That solves the > problem for any packet obviously. And any prefix length assigned to > the link. How could RFC4443 possibly address this for all packets without formally updating RFC2460? P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, as noted, no matter where this "patch" is specified, such doc should certainly update RFC2460. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 06:31:23 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 CD665129453; Tue, 18 Apr 2017 06:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 I6l-0-hm_RvI; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 448B4127866; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:31:19 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 05262D788D; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Y2KtCjM84UDsyN4JUvzhwk2HKyM=; b= THcf0psYM5eTzk/HoyHztlsP47niUb+KbWjaEmH7PvTm/HGvFpOKrTcMVdeBjFb+ d26UxTOjmcanUjZ3poqPXKAYHmcIPBuNvfF6ubS2H1HCXqCxgF3zWr+ipZP9EMBb Og3YMMcrva7L3oHdg1IS7i3LVD3Ui7CSulFlCNzpMss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=UFfxg+UuDTAwQCiFkQvrXkd hK2JJFvJrNHzw2wNtx7gKEz3bk1BPIkPEdQi63zNAMKR1RzVNBEdxPHMsjKfQ7JS 5t3k90VBZ8njWHQsZqTYQGIGJdN7R6o2zKN1dd7ktOjvdQKLKWL3zK42YBRr4vl0 lyE3wDazOiOPCS+tXSZ8= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8BE8ED788E; Tue, 18 Apr 2017 06:31:18 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0CF52AA5DDE1; Tue, 18 Apr 2017 15:31:17 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 15:31:16 +0200 In-Reply-To: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 13:31:21 -0000 --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>>>> The ping pong attack is mitigated in RFC4443. >>>>>=20 >>>>> I must be missing something.. what does RFC4443 have to do with >>>>> this? A ping pong attack does not require the attack packets to >>>>> be ICMPv6 echo requests... >>>>=20 >>>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>>> in which a Destination Unreachable message is sent with a code 3 >>>> is in response to a packet received by a router from a >>>> point-to-point link, destined to an address within a subnet >>>> assigned to that same link (other than one of the receiving >>>> router's own addresses). In such a case, the packet MUST NOT be >>>> forwarded back onto the arrival link. >>>>=20 >>>> Most implementations I'm aware of now implement this. >>>=20 >>> Why wouldn't an attacker send *any* packet meant for the p2p link, >>> but that not correspond to the address of any of the two >>> endpoints? >>>=20 >>> i.e., I don't see the need to focus on a specific kind of packet... >>> I guess I'm missing something? >>=20 >> Yes, you are missing something. RFC4443 specifies what behaviour >> should be if a router receives a packet on a point to point link that >> would end up being forwarded back out the same link. The specified >> behaviour is drop and send destination unreachable. That solves the >> problem for any packet obviously. And any prefix length assigned to >> the link. >=20 > How could RFC4443 possibly address this for all packets without = formally > updating RFC2460? >=20 > P.S.: For a specification pov, this shouldn't be buried in RFC4443, = and, > as noted, no matter where this "patch" is specified, such doc should > certainly update RFC2460. You will probably save everyone a lot of energy if you just admit you = had missed it, and moved on. Ole --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hUkAAoJEL7aWKiYQt92OZgP/i/uokmPW9y4T3dsmjjJkrpE sNjL2XvmUUnEFf9cULpgJMem0Xw6JmsLrehafvsfffAhLHZIYvL+qA8TIRdSFSJ3 TnSGyPIeIaTBNKAggQzCuqnfRsEuRZFxpB1zq878Q6RFwiwpOljxeOX4SdE8vI7r fbjxk94YigsO1fA7qMW69nsbZkZF7aAdnY7oP3+BF0aUZQEamxTshCb1DgpbfI62 KKSDqMHxmlBEvzCYBLohw8RdAkMjRUqnHaoPrpVV/fswwOLfGunGIP3O/LVZJWfX OJH6LNnBptqcwHpz6acxOnstgTR2+xqfpa+etviiQsZCjoW1jl8OlBmQvtqEwmb0 N2kT4N1ebyv4kLzVV239kbPJAHPRoTBs67eZ2AiXaDiFGsaDO4edpXJFc4+0b+Li PW9LZRQToYg5j6MVXhcakG8Ajt56rnWtE+AuWbgFzMru1wmc900jA7kXPMyYrq6l NRBJICP0FEkP1/emHuCUbZBEuPWMnu5rbqONWQswpweHnhS2HfFWtpqZaTOZzHdI Ff3oWteQjBXhlq1dY/Mqw6BQ4LTV6oxSQCFJrv5T8VyLNgWIc7MeSwlRiz5K26vw zmK1pT7Zk8CFfiKopmbrKk9naBAy14nN1XNZ5PavGegU0xEPW/dF/TVttUbG8oTu UKlfZ+XOoi8kGKTcxG1l =MlFa -----END PGP SIGNATURE----- --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2-- From nobody Tue Apr 18 07:25:33 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 140561318DB for ; Tue, 18 Apr 2017 07:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DkPhPy809SyE for ; Tue, 18 Apr 2017 07:25:29 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 8541C1318D6 for ; Tue, 18 Apr 2017 07:25:29 -0700 (PDT) Received: from dsn11.skype ([216.160.75.206]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3IEPP96020409 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 07:25:26 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_12F3D7C8-109D-4177-A2E8-A8E901B1A2A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Merike Kaeo In-Reply-To: Date: Tue, 18 Apr 2017 07:25:19 -0700 Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "opsec@ietf.org" Message-Id: <49F5F519-CF93-48AB-AB22-4CC60FF8D6FA@doubleshotsecurity.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> To: Erik Kline X-Mailer: Apple Mail (2.3124) X-Sonic-CAuth: UmFuZG9tSVYP+DQqXI7cdi4yZQvtGBMjvin8be+Xe+iuW+je3iTg/jl/kafMzETvk+uD0uEwjjO/GVDZ5zhPTjC/vgThOwS09S+Cy8u8s90= X-Sonic-ID: C;3Exy3UIk5xGCCSCc7bdh1w== M;2oe73UIk5xGCCSCc7bdh1w== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [OPSEC] [ALU] Re: [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 14:25:31 -0000 --Apple-Mail=_12F3D7C8-109D-4177-A2E8-A8E901B1A2A1 Content-Type: multipart/alternative; boundary="Apple-Mail=_F7B5F6EE-15B7-468F-834E-779F4462F85C" --Apple-Mail=_F7B5F6EE-15B7-468F-834E-779F4462F85C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am unclear as to what the comment and/or request for change of = language is. I will look at list archives from last year to determine = what the discussion may have been but it would be useful to have some = more context. I am aware of folks using ULAs (not something I = personally favor). In past versions, as the current language was = drafted, the authors were weighing heavily on appropriate language. Pointers appreciated to any past thread. - merike > On Apr 18, 2017, at 12:35 AM, Erik Kline wrote: >=20 > Didn't we already have a bunch of discussion about this in v6ops and = work very carefully to come to text? >=20 > On 18 April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) = > = wrote: > Relaying message to WGLC discussion alias >=20 >=20 >=20 > G/ >=20 >=20 >=20 > From: v6ops > = on behalf of Erik Kline > > Date: Tuesday, 18 April 2017 at 09:30 > To: Gunter Van De Velde > > Cc: "v6ops@ietf.org " >, 6man <6man@ietf.org > > Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 >=20 >=20 >=20 > 2.1.2. Use of ULAs >=20 >=20 >=20 > Still? Really? >=20 >=20 >=20 > On 18 April 2017 at 16:18, Gunter Van De Velde = > = wrote: >=20 > Dear 6man, v6ops, >=20 >=20 >=20 > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. >=20 >=20 >=20 > Please send your feedback to OPSEC email list, where discussion around = this document should take place. >=20 >=20 >=20 > Kind Regards, >=20 > G/ >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >=20 >=20 > From: Gunter Van De Velde > >=20 > Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 >=20 > Date: 12 April 2017 at 09:39:28 GMT+2 >=20 > To: opsec@ietf.org >=20 >=20 > This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6 = . >=20 > If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >=20 >=20 >=20 >=20 > I will close the call on 26 April 2017 >=20 >=20 >=20 >=20 > G/ >=20 > Sent from iCloud > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec = >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_F7B5F6EE-15B7-468F-834E-779F4462F85C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am unclear as to what the comment and/or request for change = of language is.  I will look at list archives from last year to = determine what the discussion may have been but it would be useful to = have some more context.  I am aware of folks using ULAs (not = something I personally favor).  In past versions, as the current = language was drafted, the authors were weighing heavily on appropriate = language.

Pointers = appreciated to any past thread.

- merike


On = Apr 18, 2017, at 12:35 AM, Erik Kline <ek@google.com> wrote:

Didn't we already have a bunch of discussion about this in = v6ops and work very carefully to come to text?

On 18 = April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

Relaying message to WGLC discussion alias

 

G/

 

From: v6ops <v6ops-bounces@ietf.org> on behalf of Erik Kline <ek@google.com>
Date: Tuesday, 18 April 2017 at 09:30
To: Gunter Van De Velde <guntervandeveldecc@icloud.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man <6man@ietf.org>
Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for = draft-ietf-opsec-v6

 

2.1.2.  Use of ULAs

 

Still?  Really?

 

On 18 April 2017 at 16:18, Gunter = Van De Velde <guntervandeveldecc@icloud.com> wrote:

Dear 6man, v6ops,

 

Due to the IPv6 focus of = "draft-ietf-opsec-v6" the OPSEC WGLC for this document may be of = interest to both 6man as v6ops.

 

Please send your feedback to = OPSEC email list, where discussion around this document should take = place.

 

Kind Regards,

G/



Begin forwarded message:

 

From: = Gunter Van De Velde <guntervandeveldecc@icloud.com>

Subject: = [OPSEC] WGLC for draft-ietf-opsec-v6

Date: = 12 April 2017 at 09:39:28 GMT+2

To: = opsec@ietf.org

 

This is to = open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.

If you have = not read it, please do so now. You may send nits to the author, but = substantive discussion should go to the list.



I will close = the call on 26 April 2017



G/ 

Sent from iCloud

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

 


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

 


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

= --Apple-Mail=_F7B5F6EE-15B7-468F-834E-779F4462F85C-- --Apple-Mail=_12F3D7C8-109D-4177-A2E8-A8E901B1A2A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY9iHVAAoJEA7gPO9LJuahsFoH/iStGTS8ZpQ5xaw5yCh448Aa 576Nd3femEU449C4qLE2PtHGaTuacbD31teA5UZ038tvnY5RlrXErrIAh4HJhsLL qCJzXMtRN5FDKvsUXNCkgFjeHh/pedS7z1jSrmwSlDWWWEYmGzCa2HYgofUknkdH Y8v+Sr313q2ubxaGYXp4XNnoFqJel+5T8EZNPuG+Ak9z0QncudTIM/zr9EKhpdkS CEy5gG/fSO7LZWpWuTfbf+jkHty2oH9B4MONYiQkar5ITgYy38p4wXg5DPn1FnP0 vDaCtkjHL2S+PNIyy2biI6ut+CdogEnF7YDvoDg8HWNdlaRtSC8RfEsyAO70r5w= =RcEu -----END PGP SIGNATURE----- --Apple-Mail=_12F3D7C8-109D-4177-A2E8-A8E901B1A2A1-- From nobody Tue Apr 18 07:39:24 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 A8EE5131883; Tue, 18 Apr 2017 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS2ToyMvilZO; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) 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 ABA881317D0; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (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 3EF9C80890; Tue, 18 Apr 2017 16:39:19 +0200 (CEST) To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 18 Apr 2017 15:15:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 14:39:23 -0000 On 04/18/2017 02:31 PM, otroan@employees.org wrote: >>> >>> Yes, you are missing something. RFC4443 specifies what behaviour >>> should be if a router receives a packet on a point to point link that >>> would end up being forwarded back out the same link. The specified >>> behaviour is drop and send destination unreachable. That solves the >>> problem for any packet obviously. And any prefix length assigned to >>> the link. >> >> How could RFC4443 possibly address this for all packets without formally >> updating RFC2460? >> >> P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, >> as noted, no matter where this "patch" is specified, such doc should >> certainly update RFC2460. > > You will probably save everyone a lot of energy if you just admit you had missed it, and moved on. Huh? I obviously missed it. But this should still be in RFC2460 (or rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding for IPv6 packets. Having important requirements spread into a number of documents where they don't belong doesn't help, and in the long run takes more energy (and creates more problems) than spending the energy in doing what is right. 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 Apr 18 07:44:58 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 8910F1318C4 for ; Tue, 18 Apr 2017 07:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 v1lHP0VAcjnr for ; Tue, 18 Apr 2017 07:44:54 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 D2BFF1317B4 for ; Tue, 18 Apr 2017 07:44:54 -0700 (PDT) Received: from dsn11.skype ([216.160.75.206]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3IEip8O008227 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 07:44:51 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BA261E35-2529-484D-8270-2844595D42E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Merike Kaeo In-Reply-To: <49F5F519-CF93-48AB-AB22-4CC60FF8D6FA@doubleshotsecurity.com> Date: Tue, 18 Apr 2017 07:44:50 -0700 Cc: "opsec@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Message-Id: <2F3F2792-3B92-4B25-BBFD-B1C72A88F2D1@doubleshotsecurity.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <49F5F519-CF93-48AB-AB22-4CC60FF8D6FA@doubleshotsecurity.com> To: Erik Kline X-Mailer: Apple Mail (2.3124) X-Sonic-CAuth: UmFuZG9tSVaL2U5xVts5tQ16Ux9uOuNzcXom0Fu15DhrFF0F1Z5a3DcCkFBW1ZlOMkqeh34gyfGScxiEvatKgacclVPnH9XE7u5OxtoTHYs= X-Sonic-ID: C;ypndk0Uk5xG1yyCc7bdh1w== M;mioilEUk5xG1yyCc7bdh1w== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [OPSEC] [ALU] Re: [v6ops] Fwd: WGLC for draft-ietf-opsec-v6 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, 18 Apr 2017 14:44:56 -0000 --Apple-Mail=_BA261E35-2529-484D-8270-2844595D42E0 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D2B9DD0-2BC2-47B5-87D3-EEC62892E8AE" --Apple-Mail=_8D2B9DD0-2BC2-47B5-87D3-EEC62892E8AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looking at archives was quicker than expected. Unless the subject got = changed, the only comments I see from last July are [adding folks who = replied in email snippet for clarification]: =E2=80=94 On 8 July 2016 at 18:36, Erik Kline > wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be = able >>> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >>=20 >> [Eric Vyncke] I changed the end of the section 2.1.2 to reflect this. = Albeit, I am >> unsure whether there is a clear statement by the IETF about not using = ULA >> + NPTv6 (and I would LOVE to see such a statement) >=20 > [EK] Then please go ahead and make that statement in your document. >=20 > I, for one, will help defend it. :-) [Lorenzo +1=E2=80=99d this] [Mark Smith] Depending on an experimental RFC for your security sounds like a really bad idea to me! =E2=80=94=E2=80=94 I=E2=80=99d love to have more folks weigh in on this topic so that = authors can get group consensus. - merike > On Apr 18, 2017, at 7:25 AM, Merike Kaeo = wrote: >=20 > I am unclear as to what the comment and/or request for change of = language is. I will look at list archives from last year to determine = what the discussion may have been but it would be useful to have some = more context. I am aware of folks using ULAs (not something I = personally favor). In past versions, as the current language was = drafted, the authors were weighing heavily on appropriate language. >=20 > Pointers appreciated to any past thread. >=20 > - merike >=20 >=20 >> On Apr 18, 2017, at 12:35 AM, Erik Kline > wrote: >>=20 >> Didn't we already have a bunch of discussion about this in v6ops and = work very carefully to come to text? >>=20 >> On 18 April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) = > = wrote: >> Relaying message to WGLC discussion alias >>=20 >>=20 >>=20 >> G/ >>=20 >>=20 >>=20 >> From: v6ops > = on behalf of Erik Kline > >> Date: Tuesday, 18 April 2017 at 09:30 >> To: Gunter Van De Velde > >> Cc: "v6ops@ietf.org " >, 6man <6man@ietf.org > >> Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 >>=20 >>=20 >>=20 >> 2.1.2. Use of ULAs >>=20 >>=20 >>=20 >> Still? Really? >>=20 >>=20 >>=20 >> On 18 April 2017 at 16:18, Gunter Van De Velde = > = wrote: >>=20 >> Dear 6man, v6ops, >>=20 >>=20 >>=20 >> Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for = this document may be of interest to both 6man as v6ops. >>=20 >>=20 >>=20 >> Please send your feedback to OPSEC email list, where discussion = around this document should take place. >>=20 >>=20 >>=20 >> Kind Regards, >>=20 >> G/ >>=20 >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>=20 >>=20 >> From: Gunter Van De Velde > >>=20 >> Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 >>=20 >> Date: 12 April 2017 at 09:39:28 GMT+2 >>=20 >> To: opsec@ietf.org >>=20 >>=20 >> This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6 = . >>=20 >> If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >>=20 >>=20 >>=20 >>=20 >> I will close the call on 26 April 2017 >>=20 >>=20 >>=20 >>=20 >> G/ >>=20 >> Sent from iCloud >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec = >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops = >>=20 >>=20 >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_8D2B9DD0-2BC2-47B5-87D3-EEC62892E8AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looking at archives was quicker than expected.  Unless = the subject got changed, the only comments I see from last July are = [adding folks who replied in email snippet for clarification]:

=E2=80=94

On 8 July 2016 at 18:36, = Erik Kline <ek@google.com> wrote:
Section 2.1.2 is far too permissive for my = tastes.  We need to be able
to say that ULA+IPv6 NAT = is NOT RECOMMENDED by the IETF.

[Eric Vyncke] I changed the end of the section 2.1.2 to = reflect this. Albeit, I am
unsure whether there is a clear = statement by the IETF about not using ULA
+ NPTv6 (and I = would LOVE to see such a statement)

[EK] Then please go ahead and make that statement in your = document.

I, for one, will help defend it. =  :-)

[Lorenzo +1=E2=80=99d this]

[Mark Smith]
Depending on an = experimental RFC for your security sounds like a
really = bad idea to me!
=E2=80=94=E2=80=94

I=E2=80=99d love to have = more folks weigh in on this topic so that authors can get group = consensus.  

- merike

On Apr 18, 2017, at 7:25 AM, = Merike Kaeo <merike@doubleshotsecurity.com> wrote:

I am unclear = as to what the comment and/or request for change of language is.  I = will look at list archives from last year to determine what the = discussion may have been but it would be useful to have some more = context.  I am aware of folks using ULAs (not something I = personally favor).  In past versions, as the current language was = drafted, the authors were weighing heavily on appropriate language.

Pointers appreciated to = any past thread.

- merike


On Apr = 18, 2017, at 12:35 AM, Erik Kline <ek@google.com> wrote:

Didn't we already have a bunch of discussion about this in = v6ops and work very carefully to come to text?

On 18 = April 2017 at 16:34, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

Relaying message to WGLC discussion alias

 

G/

 

From: v6ops <v6ops-bounces@ietf.org> on behalf of Erik Kline <ek@google.com>
Date: Tuesday, 18 April 2017 at 09:30
To: Gunter Van De Velde <guntervandeveldecc@icloud.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man <6man@ietf.org>
Subject: [ALU] Re: [v6ops] Fwd: [OPSEC] WGLC for = draft-ietf-opsec-v6

 

2.1.2.  Use of ULAs

 

Still?  Really?

 

On 18 April 2017 at 16:18, Gunter = Van De Velde <guntervandeveldecc@icloud.com> wrote:

Dear 6man, v6ops,

 

Due to the IPv6 focus of = "draft-ietf-opsec-v6" the OPSEC WGLC for this document may be of = interest to both 6man as v6ops.

 

Please send your feedback to = OPSEC email list, where discussion around this document should take = place.

 

Kind Regards,

G/



Begin forwarded message:

 

From: = Gunter Van De Velde <guntervandeveldecc@icloud.com>

Subject: = [OPSEC] WGLC for draft-ietf-opsec-v6

Date: = 12 April 2017 at 09:39:28 GMT+2

To: = opsec@ietf.org

 

This is to = open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.

If you have = not read it, please do so now. You may send nits to the author, but = substantive discussion should go to the list.



I will close = the call on 26 April 2017



G/ 

Sent from iCloud

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

 


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

 


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

_______________________________________= ________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

= --Apple-Mail=_8D2B9DD0-2BC2-47B5-87D3-EEC62892E8AE-- --Apple-Mail=_BA261E35-2529-484D-8270-2844595D42E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY9iZiAAoJEA7gPO9LJuahLXMH/3a1slH/1U9OKaeh/q5PopXI LY8OWwFPROCtJ9YVDnoahrrlReRh3hvmEqmPWqkFqQ73oLcWCsebOJr5cjsZsawb sP6Gs+pVXQDYOfcXnZjDjH/9fyqMzaHCBKqa8jAptZywJx6IeiyG4je4lr74+OKM /By/paZHmBPR47325b6VPurI3D1R3ZKNy0pXqerAgDlLfosDrMqqnl7C09d8affZ D9jNSfUV4/pZ6p8vaqrh7UZS4DVIe4IXM8iXbKujkEKJa5QZ0ccX/EzJt5/Vf+4r qQHYG8NBWuG1KHvwXThe/hHRM8FVhX1UVZfFbmhYrW8AffAPNuyhJn9Xd6Aisvk= =Rftz -----END PGP SIGNATURE----- --Apple-Mail=_BA261E35-2529-484D-8270-2844595D42E0-- From nobody Tue Apr 18 21:03:06 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 4F21D1200DF; Tue, 18 Apr 2017 21:02:58 -0700 (PDT) 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 dfC1IO2hCfgR; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 CE56D126CF6; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id a188so1855081pfa.2; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=mSVkhc1P+UMjd3DjE5jqKdcSammtpfVLakd3nXTMT540l58gVqvLKEexMgf36dGmMA hCuxoqkYKX3YnN10dVHa4Iqt+uyURq+5iylXoEz4F9wFPMJHUjqBxpUvzbQZYalvjDrc mWkTnNqy8Y/htKqRQ5A0/EmAbYj5taQFPt8tgxIOoWMvyfV2tJVhGAxTQLpdZsKH0nST R1N2CCbHXbOasN2gjt25KHQ9oY6/lCpxHu8usNE10WGsVdEeO9cDd8/zZUoVUO9aASpc WEq2STns6c8l9SKolxaAmFNjYr0uLfTtFNI0kOJYUXMML1hkOaLoXUZgFA1lg9KmrIwj QOvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=efjBoGMB5cSxJT76wPDUIw/OweQXNExN24rg06bwt9xfqd52eCSC+R4oF2+IjPRaYs t3a+0KXvIDGogI6qeb882Vm+00v9lzA5fjx/4sdH5AjN1o0k9wZk/rOkwAubgnWxpa+7 /6fA4MnO5EdNAsQVmJ2OAEouWCzxguNn2FB7PWLmhPvFz3onEdzICfQNSQw6SCaHav71 cIV5lTxbes5g9pZg3ahBpsy75lt6v9VcITCfo0P0qZy9qNqo/tQ2+fpb7MMEaLG7c5JM Xa0Sjfo+QpvcN45HzNGeDRJDCEiSn7UNEimMc02dd6ZrAJ89+jqE7QkwYD+SLV6AM1Pp BQzQ== X-Gm-Message-State: AN3rC/4urD4XNhjybd9dyP28dy+CXroVSTKqFPjkqyn55YFDLE5I/v2q W8qtNEMbwVlW8A== X-Received: by 10.98.71.202 with SMTP id p71mr899509pfi.39.1492574576291; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m4sm1152766pfi.74.2017.04.18.21.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:02:55 -0700 (PDT) To: Gunter Van De Velde , "opsec@ietf.org" References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 16:02:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSEC] ULAs [was WGLC for draft-ietf-opsec-v6] 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, 19 Apr 2017 04:02:58 -0000 There are several issues in this section, not just the NAT: > 2.1.2. Use of ULAs > > ULAs are intended for scenarios where IP addresses will not have > global scope so they should not appear in the global BGP routing > table. We need to align that with the clarification in draft-bchv-rfc6890bis: ULAs are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. > ULAs could be useful for infrastructure hiding as described in > RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 > [RFC7404] could also be used. LL addresses don't help if you have multiple LANs. I suggest simply deleting the second sentence; it will confuse people. > Although ULAs are supposed to be used > in conjunction with global addresses for hosts that desire external > connectivity Change that to ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Then I suggest deleting *all* the rest of the section, but add this at the end: Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Thus the whole section would read (with a little more editing): 2.1.2. Use of Unique Local Addresses Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. ULAs are assigned within pseudo-random /48 prefixes created as specified in [RFC4193]. They could be useful for infrastructure hiding as described in [RFC4864]. ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Brian From nobody Tue Apr 18 22:58:40 2017 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 E3CCC13151E; Tue, 18 Apr 2017 22:58:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: warren@kumari.net, opsec@ietf.org, opsec-chairs@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149258151988.29126.7778888015695856604.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 22:58:39 -0700 Archived-At: Subject: [OPSEC] opsec - Update to a Meeting Session Request for IETF 99 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: Wed, 19 Apr 2017 05:58:40 -0000 An update to a meeting session request has just been submitted by Eric Vyncke, a Chair of the opsec working group. --------------------------------------------------------- Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Eric Vyncke Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: 6man apparea grow opsarea opsawg v6ops Second Priority: acme dmarc dots oauth saag Third Priority: tls sunset4 sidrops quic netconf intarea People who must be present: Eric Vyncke Gunter Van de Velde Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Apr 19 06:27: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 E5B5A129504 for ; Wed, 19 Apr 2017 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 cQ7vJSjeBjn0 for ; Wed, 19 Apr 2017 06:27:15 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 2FA1212957F for ; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id h67so19713181qke.0 for ; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=M9zKJPhsqnK8XNWEIzvBfJUXP6S+47Nf6ziojRxNMLmY1v6NCvYNjkTdrAs14dGcT4 zyu7+CE/01crye0d2c3c13i36O5cKipw5pX+3mVvLBnDojIFLmX5q2mQ/6HJe36bB/eQ o/ZkGA+EZygwkT3v+7qGcGrwRuK6KyccAsTzBJ+kBwdMoQrF+yh3ik+QpEc0n+be7LWV zksTWd6V9f7+2iuKn2GRT1YWGOvvoy3et5w/Kt9f5BNe+7eLt4yJQK5d6wads0klVTQt W4+oRnx945PqEeL61VCuSsvaRw7BDkYu4O6IgRGAXSiVoA3J0obEIcm9R5GNhZZXEXiG EEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=uRWCQ6RXWnoN5wmwK/6+16v6vtzt0hAW9LyfGvrpif6LYaVMZO7JfkIIoZbPwq3twP lxLGMQyByqvA5n/HF0BCFtm2BEr3mnPvCz7eIhiAKxPI37lWgq4ywvtsnWAPEJogVefn HQL5thK1lGAfDZhxUr3n8u3BTTN5Aa2YmNLgK7EfjCqzF7ojEXBWVhAJsxeLKklqh9GS B2YFR6mgsLDzfeb5a9tZaMe4kUgmdL2FYRTGjFEq1TpKOziNt1Y3JZFKTiobg9OXdRDO yMWwnMOVNKJD2i3Z2yQNbMlqYB36abjAXNXKIEArdZtWEz2jif03UI7ZefghygpX+wet aDog== X-Gm-Message-State: AN3rC/6MP1TrPQd0g6g2BgCMph1QHPjkK+kmknJYVnaQfCb4pDwyIyI+ ZU73M8VoV3Ajpw== X-Received: by 10.55.115.67 with SMTP id o64mr2349407qkc.216.1492608427286; Wed, 19 Apr 2017 06:27:07 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t45sm236437qtt.9.2017.04.19.06.27.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 06:27:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 09:27:04 -0400 Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] ULAs [was WGLC for draft-ietf-opsec-v6] 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, 19 Apr 2017 13:27:18 -0000 This would be a huge improvement on the existing text=E2=80=94thanks for = writing it! > On Apr 19, 2017, at 12:02 AM, Brian E Carpenter = wrote: >=20 > There are several issues in this section, not just the NAT: >=20 >> 2.1.2. Use of ULAs >>=20 >> ULAs are intended for scenarios where IP addresses will not have >> global scope so they should not appear in the global BGP routing >> table.=20 >=20 > We need to align that with the clarification in draft-bchv-rfc6890bis: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. >=20 >> ULAs could be useful for infrastructure hiding as described in >> RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 >> [RFC7404] could also be used. >=20 > LL addresses don't help if you have multiple LANs. I suggest simply > deleting the second sentence; it will confuse people. >=20 >> Although ULAs are supposed to be used >> in conjunction with global addresses for hosts that desire external >> connectivity >=20 > Change that to >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Then I suggest deleting *all* the rest of the section, but add this > at the end: >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Thus the whole section would read (with a little more editing): >=20 > 2.1.2. Use of Unique Local Addresses >=20 > Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios > where IP addresses are not globally reachable, despite formally > having global scope. They must not appear in the routing system > outside the administrative domain where they are considered valid. > Therefore, packets with ULA source and/or destination addresses > MUST be filtered at the domain boundary. >=20 > ULAs are assigned within pseudo-random /48 prefixes created as > specified in [RFC4193]. They could be useful for infrastructure > hiding as described in [RFC4864]. >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Brian >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 19 08:26:49 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 0FA3C129AE5 for ; Wed, 19 Apr 2017 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 DdyCRMWr7GKp for ; Wed, 19 Apr 2017 08:26:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 4549D129A8F for ; Wed, 19 Apr 2017 08:26:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 26498AB; Wed, 19 Apr 2017 17:26:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492615603; bh=CZmhpaF8A0u8A/NFUyuzx/KyOc2J0BvfRSZt5g/YAtA=; h=Date:From:To:Subject:In-Reply-To:References:From; b=l5va8EaBUgEKzuAPnyd3woqxa2rRQ2/xSA3yCj278i8uw4YSPjBAOe8fv+xingeAi vfQneCCP/PaChUEyjs+vtcmSgtx/xWZXb8WnIAXYCis83jIoO5h+f6zEqedxFm5dA6 PsX1C3xjCa4vHhy5nHUtzGjhqrFRgEgMATmn1EsQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 23863A9 for ; Wed, 19 Apr 2017 17:26:43 +0200 (CEST) Date: Wed, 19 Apr 2017 17:26:43 +0200 (CEST) From: Mikael Abrahamsson To: opsec@ietf.org In-Reply-To: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> Message-ID: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-12598372-1492615603=:5591" Archived-At: Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 19 Apr 2017 15:26:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-12598372-1492615603=:5591 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 12 Apr 2017, Gunter Van De Velde wrote: > This is to open a two week WGLC > for https://tools.ietf.org/html/draft-ietf-opsec-v6. > If you have not read it, please do so now. You may send nits to the author, > but substantive discussion should go to the list. > > I will close the call on 26 April 2017 Hi, I went through -11. Reading it and commenting as if I never read it before (which I don't remember doing, but since I am mentioned in the acknowledgement section I must have :) ) 2.1.2. I would like to see the last paragraph moved to first in this section, ie have the IETF recommendation start this off, not finish it. Somewhere in 2.1.x, can we have a note about the /64 per host as a means of tracking devices instead of having to track individual addresses? 2.3.1. I keep hearing people talk about SeND. The paragraph rightly ends with with "SeND isn't widely available in implementations". Can we start off with that? Also potentially move the whole SeND section to later in 2.3.x so that the actually useful protocols come first? 2.4.x. Should this document have all this text on router security? Does this text say anything in opposition to RFC6192 that it starts off with a reference to? 2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I think it should contain more such references. For instance, 2.6.1.4 mentions using CLI tools to dump ND table. There is a YANG model for that. 2.6.1.4. Here is one example where /64 per host and only tracking that, would be useful approach. 2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and where they are. I don't think if that's implied in the 6221 5.3.2 reference? 2.6.2.3 This is one of a few "..." in there. Is that really what we want in a finished RFC? 2.7. "Some text"? 2.7.2. Blocking all tunnels? What's the recommendation here? "...it could be helpful to block all default configuration tunnels"? 2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and TEREDO on all your enterprise machines (where you can, this was specifically for enterprise Windows deployments). Shouldn't we mention this here? Unless you know that you need it, turn it off? Or if there is a document somewhere talking about this, reference it? 2.7.2.4. I'd like to start this with the fact that anycast 6to4 has been deprecated. This document is a nice overview of a lot of topics, it contains lots of good links to documents that are good for reader to know. I actually think this is the best feature of this document, ie that it overviews a lot of different topics and gives the reader ideas for further reading. However, reading the document it felt a bit like there was a bit more work needed. It's 95% there, but I think there are more things that needs discussion. I also think this document needs wider review. Notifying 6man and v6ops was a good thing. It seems there have been more discussion there than here in OPSEC, but I think the authors follow those groups as well. So my comment for this in WGLC is that I would like to have more people look at the document and I think we need a few more revisions before it's ready for publication. Overall, I think this document contains valuable information and after some more review and discussion I definitely would like to see it published. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-12598372-1492615603=:5591-- From nobody Wed Apr 19 14:16:02 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 877EA129B0D for ; Wed, 19 Apr 2017 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 iaX6YHkw3Fzi for ; Wed, 19 Apr 2017 14:15:56 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 E2A801293D9 for ; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 81so16907221ybp.0 for ; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=slbvLTa8uctCuoLTjuo/yEW+kIUhpNPv4C6ajdUhqsTlUMbAnVv4IqtAtsyLujVne6 uUwMsko8eoPReIhecGdtJb+usV57i7/bn6UTCOrswaI6vtWqoasXICRoKjBm+KrlnsDq Zmx5QOCf2WEV97JBsEcJkPf/wrAHs/4OuOl+/6Lq0YgyOWGLD01TqFaOEVmJ9Awed0N9 W6/gGvOgyVk/P4cqWlWdCakvSzjZcr5WvdDd853Tj0uEeSHsnDYeeT7ihAr1wcA/Ye2D YKrbnPbCn1xBZKm7gQrR2E25XZyH+xHGM1wATIfrs3NFz+ZoBYJ5IkbiqCUD4htH08sz IR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=qCTnuNZ79GsecoSngmSEHhaehiIwd/sH/xcTf9OA6mUNb/eTEX1pLyo1X+ZA3Wpnm6 6iNQbco1jrIxgUy7nkRMoNg+WArFJsw2Vgl3LRXSrU/cs6TCT6j1ImxxsHbGxBUI47/n F1F5IRwvFx24L3SZv3rcPQw8PAhMr2zSkcq3ymwAzLuqfqmZhAsQasC5VpwFeqUW26um PcWwRe3oMuC+X7MOZJURJjvauka3byNd9hg7ze1ncXBq8NY8rHHpyVx/XRcRBnN7kwwv hC88DroVorjpxGtCGZ4jAAXGpJl5vyNlCl9upM5D0rAuzrgIPYOWUghTLzlmPzY3yt7H a45A== X-Gm-Message-State: AN3rC/7sB3C/dEC1R1vdWGaxfe+55l1LWM0ABE1slwCTvXnMsJYWe60y NP8hX+fE0+4aCc0B X-Received: by 10.84.213.8 with SMTP id f8mr6368822pli.156.1492636555084; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2dd0:a83f:1f58:e25? ([2620:0:10e7:10:2dd0:a83f:1f58:e25]) by smtp.gmail.com with ESMTPSA id z123sm6223509pfz.56.2017.04.19.14.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:15:54 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 14:15:53 -0700 References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Message-Id: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] ULAs [was WGLC for draft-ietf-opsec-v6] 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, 19 Apr 2017 21:15:58 -0000 --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter = wrote: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. I don=E2=80=99t think it's quite right yet. It=E2=80=99s greatly = improved, but I have a quibble. ULA are intended for scenarios where IP addresses are not *publicly* = reachable. Nothing about them constrains their private routing or usage = over any geographic area. They may appear as source or destination in = packets in transit across any private routing system, including any = system organized in a private multilateral agreement between domain = administrators. Therefore, packets with ULA source and/or destination addresses MUST be = filtered at the public boundary of a routing domain, and SHOULD be = filtered at private boundaries to limit their reachability according to = local policy. I would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of = Unique Local Addresses like so: >> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. >>=20 >> Routing prefixes for ULA are /48 prefixes, and contain 40-bit = pseudo-random global identifiers. which are generated according to = [RFC4193]. They could be useful for infrastructure hiding as described = in [RFC4864]. They could also be useful for communication between hosts = in private routing domains, and private groups of autonomous routing = systems organized by multilateral agreement. Hosts that require = connectivity to the public Internet SHOULD communicate using publicly = routed general-unicast (GUA) addresses. No form of address translation = is required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public connectivity. >>=20 >> The usage of ULA as described here could simplify the filtering rules = needed at domain boundaries, by allowing a regime in which only hosts = that require communication with the public are assigned general-unicast = addresses (GUA). However, this does not remove the need for careful = design of filtering rules at domain boundaries. --james woodyatt > --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

ULAs are intended = for scenarios where IP addresses are not globally
reachable, despite formally having global scope. = They must not appear
in the routing = system outside the administrative domain where they
are considered valid. Therefore, packets with = ULA source and/or
destination = addresses MUST be filtered at the domain = boundary.

I don=E2=80=99t think it's quite right = yet. It=E2=80=99s greatly improved, but I have a quibble.

ULA are intended for = scenarios where IP addresses are not *publicly* reachable. Nothing about = them constrains their private routing or usage over any geographic area. = They may appear as source or destination in packets in transit across = any private routing system, including any system organized in a private = multilateral agreement between domain administrators.

Therefore, packets with = ULA source and/or destination addresses MUST be filtered at the public = boundary of a routing domain, and SHOULD be filtered at private = boundaries to limit their reachability according to local = policy.

I = would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of Unique = Local Addresses like so:

Unique = Local Addresses (ULA) [RFC4193] are intended for scenarios where IP = addresses are not publicly reachable, despite their global address = scope. They MUST NOT appear in the default-free routing domain of the = public Internet, and gateways at the boundaries of private routing = domains SHOULD NOT forward packets from or to ULA addresses where = multilateral transit agreements do not explicitly recognize = them.

Routing = prefixes for ULA are /48 prefixes, and contain 40-bit pseudo-random = global identifiers. which are generated according to [RFC4193]. They = could be useful for infrastructure hiding as described in [RFC4864]. = They could also be useful for communication between hosts in private = routing domains, and private groups of autonomous routing systems = organized by multilateral agreement. Hosts that require connectivity to = the public Internet SHOULD communicate using publicly routed = general-unicast (GUA) addresses. No form of address translation is = required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public = connectivity.

The usage of ULA as = described here could simplify the filtering rules needed at domain = boundaries, by allowing a regime in which only hosts that require = communication with the public are assigned general-unicast addresses = (GUA). However, this does not remove the need for careful design of = filtering rules at domain boundaries.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4-- From nobody Wed Apr 19 15:15:26 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 18DAC129BBF; Wed, 19 Apr 2017 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 D-v_44RrDoqq; Wed, 19 Apr 2017 15:15:18 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 F283F12950A; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m36so31724130qtb.0; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=aAa/7HvZwtIO9iDkj9n8Wq/j6Z6d5qW/K1YhlFReMa5spVSM5Lo3a4Q/X/paYd+Nuv Np39u+hbcNpiaWwdoNzzefWslfbi6IZ6ToPpKoIp/36NQVLnWt6mS0rf+GCimKhS3Cen 8fF9sIibJZBxAx0h4hqPArvDKgXHbdmCvYMAbwq8FvJ9A8eHKdJgPObKwa3HaLqmzcnt xhwMegIcF9aKcMlEZYFRVzrrPTu2TeAfaGQRyRwHYfMldADWIA3Lx5Vkslkz5JFrnQSt QTRO51uS/COia7D1XcpThiQuOCqk8rKjPkIlayCIhLiLHXmxWtsz+r6PU0AuyGYbJ0Z6 5uLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=jspemVwp2VO3vuwU+SNgPdvphkDuVh6XSLFG5LFqU4Vky8Lm8tGOyBvVcKvJwKrEuR fKTekgg3b92fY7dE1QERLXZSB86zvu/ghOV2XLauFg6aL32+5gD4ZxZhcm+sFV4fg+o1 e9D/f4Pam0j6KQeLiVE+5G2KUF6+3IucVJxXAbvgEui75rkfK9GOCyKAgwKXUvc9Z50P J1BwjjiFtvc3FFDSkt+ae48nBDj10sSTPu6/YZ42EIdmN9Cr54tlz4+hrEk1dqHkMj68 DgSMJqhPUD7U9ephnpTEIY9uAHsxGZr3Zsr/BxUZHRR6oPxN1G4V67CrUKGdeUiDc4xR sHSQ== X-Gm-Message-State: AN3rC/4gahTRUbkhUCg27n5tMwpz7X306HebERuhpVEUdT0k9c953aRP UE+RsFpFtIMiG+BQtpvBPtFWaeHwWA== X-Received: by 10.237.57.170 with SMTP id m39mr4733481qte.163.1492640117020; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Wed, 19 Apr 2017 15:15:16 -0700 (PDT) In-Reply-To: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 19 Apr 2017 15:15:16 -0700 X-Google-Sender-Auth: pgHIftga7RlC6QZJwc-R8_B9WTQ Message-ID: To: Fernando Gont Cc: Ole Troan , Gunter Van De Velde , "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org Operations" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-v6 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, 19 Apr 2017 22:15:19 -0000 At Tue, 18 Apr 2017 15:15:37 +0100, Fernando Gont wrote: > > You will probably save everyone a lot of energy if you just admit > > you had missed it, and moved on. > > Huh? > > I obviously missed it. But this should still be in RFC2460 (or > rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding > for IPv6 packets. > > Having important requirements spread into a number of documents where > they don't belong doesn't help, and in the long run takes more energy > (and creates more problems) than spending the energy in doing what is right. I see your point, but this is not the only case where a description in RFC4443 could also be in RFC2460 but isn't. Destination unreachable code 2 (Beyond scope of source address) is also related to forwarding, but it's not documented in RFC2460. Code 4 (Port unreachable) is a matter of upper layer consideration, but it's not documented in Section 8 of RFC2460. I'm sure there are more. In the ideal world we could make all these points perfect: everything is documented everywhere consistently with minimal redundancy or scattering but still avoiding to push everything in a single monster document. Obviously it's an impossible goal in the real world, and we should accept some level of redundancy or scattering (or even inconsistency as a matter of fact). In this particular case I personally think it's acceptable: the ICMPv6 specification is so fundamental, so I'd say it's reasonable to say that any serious implementer should read it carefully. There should always be someone who overlooks some particular point (like you missed this specific one), but that doesn't necessarily mean we should update the documentation so that that particular person would not have missed it. There would still be someone who miss it no matter redundantly we describe it. In that sense, I tend to agree with Ole. (But I wouldn't be opposed to making this in rfc2460bis either if that's the wg consensus, although at this moment no one else seems to think this is an issue to be fixed). -- JINMEI, Tatuya From nobody Wed Apr 19 15:47:40 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 BC474129B63 for ; Wed, 19 Apr 2017 15:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 bE4f-RO1zUBr for ; Wed, 19 Apr 2017 15:47:24 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681F9127337 for ; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id g60so32203354qtd.3 for ; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=LWo5QvaqyWu9LCNeu0Zx9M0gJTBuszzn38sRM82eo8brayV3j9xSpaoOeRF7fgZrtK hDU/miiOTrleinmc/Gj3SLGWO1tRwmx/a/bd6AO7TlsFhr/gYr3yCxs3188DBDhvkwU4 UOkB/D1mz3cALI88oGesjbRrrRaCMX+h/5wtcAUa6zu32Df/0Duysb/NGJ8yf8LEfxvx m334B/u89yFyfrhF2KCftQCfctNQw38kt5Noixc5pH8KJVyrBXLYTKm/tlQMdantmMPh 7PNYkL7nADOm46vCxQvpbV4G3s+4h47hw+eHLWl8jbCxaA1jJtaeErgm60XZUj1IOHZB NGLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=eGJ3/jPb59RE8AWUoVcLlecpuEXB9n5jm2xoSzqDy+HICux8M3keOgw11kEmTBlXvK +rXHXIk+9WJGaY9Cnq56eGCmSryyLa6CEghPNVvXx19H/hxZPXvoT15me+vFAYSlkHLP 5EkxsEcOH83YgTJRyrn4BSmIfPaRAfXGglHt/8oyNr+D9+iSMhQl90umI3VtWI6KR7DE yF9irfK5hYmUZ/iLFnPbJCss/cp2Z0k5NfOmi/CDS5RvUNC8odcm2UKlwz2nWHlyXXwY H3X9bjP6k8AM8wswUgHWIKrKidQ4jpH911XF2hlwh8lPjyWWFZgWXjMT7A4SCcf5klxA yRLw== X-Gm-Message-State: AN3rC/6GEOdJqg6lNmy1iXUiYnCcMjF9pFrKCEaPq4fhr1rCizW+VuEb YJJaYeYkrH6N5Q== X-Received: by 10.200.37.136 with SMTP id e8mr5154297qte.30.1492642041608; Wed, 19 Apr 2017 15:47:21 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 144sm2900007qkj.35.2017.04.19.15.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 15:47:20 -0700 (PDT) From: Ted Lemon Message-Id: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Apr 2017 18:47:19 -0400 In-Reply-To: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> To: james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSEC] [v6ops] ULAs [was WGLC for draft-ietf-opsec-v6] 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, 19 Apr 2017 22:47:26 -0000 --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. Changing the first "globally" to "publicly" isn't necessary. Actually, = I think this whole change just makes things less clear. Publicly and = globally mean the same thing. ULAs are never globally reachable. If = you have more than one site, and route ULAs between them, the ULAs have = to be routed over your private links, not over the public internet. I = get that in principle it may be possible to route your ULAs over a link = that also carries global traffic and that is not "your link," but it = would be better to clarify this in an additional paragraph; by adding = the text where you have, you are going to confuse the heck out of any = reader who doesn't know what a "multilateral link" is. --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt <jhw@google.com> = wrote:
Unique Local Addresses (ULA) [RFC4193] are intended for = scenarios where IP addresses are not publicly reachable, despite their = global address scope. They MUST NOT appear in the default-free routing = domain of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize = them.

Changing the first "globally" to "publicly" isn't = necessary.  Actually, I think this whole change just makes things = less clear.   Publicly and globally mean the same thing.   = ULAs are never globally reachable.   If you have more than one = site, and route ULAs between them, the ULAs have to be routed over your = private links, not over the public internet.   I get that in = principle it may be possible to route your ULAs over a link that also = carries global traffic and that is not "your link," but it would be = better to clarify this in an additional paragraph; by adding the text = where you have, you are going to confuse the heck out of any reader who = doesn't know what a "multilateral link" is.

= --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045-- From nobody Wed Apr 19 17:10:49 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 B271E12EAC7; Wed, 19 Apr 2017 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-l0QNLey6Bu; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6F112EAC9; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k87so44229524ioi.0; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=nD0YNrldyPrnH/7BO20sXQedBRpcCcukGgrN6pdwFvhfjnvSISucqEw9rFPl7Nx+Ri S7ltn7yyM/Rjx/gXNDNXKF1XHomGbKEw3BCVI/SI0agPml4eaUYSDMPT52WoCx5864kw ruCpNwb7cemvkssacRV9bZbepPZDg0ofWJhj5x7vEbMql6FE7LBFvoYwRpoaGuJsKW8x TdiykNNUoOEw9OUfAuOb4kGVbijewsK+ove8giVrjrqJ02aEFsvyUIjaxSMSSjh8oWE7 n9+QkNsEF01lnbC3UXSS4oDgdgiIhq6mGwtYXBVHSFXxj2ibehs6szGHS01ByuGKWJQk HSvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=EZereMZ+3DtC0j1KgjsMwtYtGpHxg9KlzrNDzflpIMJRnxZZGWduIfEFFHmBThrJqk 7Fu+Jo0c2PM2KumrVydEbD+4pUTQVLKv+MIVfQyn2YGTT7NT1euezTRN8iNee9nppVmq 3xfN9tMz5pjHMiz8SPVjGjbIyWvaQoE532zcK1lESak3MCbaIv1bv7DI1vZn92U6Avb9 mkYuRwBTeKXCtmz/EfqlRGrM4EG1nyflLk039u759HOxmNcncM/YSmD9eF2SzU8phSiA n0ouG5IE0t88cAWdhYcNeMn6FvD3VzKPAFT0OeW2N3qCArZBNVQRy4OvpdMswCI/t3Ro A/Ig== X-Gm-Message-State: AN3rC/7OGAkJB1NSr1jJjvYoA7y0TGJv0AeklWeJWgTis9sYfBqT3m1T Ey+fb21VIaBBxg== X-Received: by 10.99.9.66 with SMTP id 63mr5519822pgj.22.1492647040098; Wed, 19 Apr 2017 17:10:40 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id j73sm6499308pfe.108.2017.04.19.17.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 17:10:39 -0700 (PDT) To: Ted Lemon , james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Cc: "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Apr 2017 12:10:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [v6ops] ULAs [was WGLC for draft-ietf-opsec-v6] 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, 20 Apr 2017 00:10:43 -0000 On 20/04/2017 10:47, Ted Lemon wrote: > On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios where IP addresses are not publicly reachable, despite their global address scope. They MUST NOT appear in the default-free routing domain of the public Internet, and gateways at the boundaries of private routing domains SHOULD NOT forward packets from or to ULA addresses where multilateral transit agreements do not explicitly recognize them. > > Changing the first "globally" to "publicly" isn't necessary. Actually, I think this whole change just makes things less clear. Publicly and globally mean the same thing. ULAs are never globally reachable. If you have more than one site, and route ULAs between them, the ULAs have to be routed over your private links, not over the public internet. I get that in principle it may be possible to route your ULAs over a link that also carries global traffic and that is not "your link," but it would be better to clarify this in an additional paragraph; by adding the text where you have, you are going to confuse the heck out of any reader who doesn't know what a "multilateral link" is. Also, "globally reachable" is a term of art in draft-bchv-rfc6890bis and in the new form of the IANA registry that it defines. Once that's final, there is work to do elsewhere (for example, the de facto meaning of "global" in the Python ipaddress module is plain wrong). So this is important terminology. I have no problem mentioning transit agreements, but I think James' SHOULD NOT should also be a MUST NOT. My routing friends tell me that there's no such thing as a true DFZ any more, too. Brian From nobody Wed Apr 19 21:55:40 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 DD910126DDF for ; Wed, 19 Apr 2017 21:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 PNloNHngtaYq for ; Wed, 19 Apr 2017 21:55:37 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 60E61126CF6 for ; Wed, 19 Apr 2017 21:55:37 -0700 (PDT) Received: from [10.178.3.115] (4.239.214.82.in-addr.arpa [82.214.239.4] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3K4tQRU022571 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 21:55:31 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3560835E-A906-4B31-A819-E4FB2FEC06F6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Merike Kaeo In-Reply-To: Date: Wed, 19 Apr 2017 21:55:19 -0700 Cc: opsec@ietf.org Message-Id: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3124) X-Sonic-CAuth: UmFuZG9tSVZ8RkbHH4y7b8UU7/L+M374EixRY1GZdhzT9wBgiBeyNGkDRwSR8ULDNxxXtdWOrWTATk7WOB1ji8qVnT6709lH X-Sonic-ID: C;LEyZkYUl5xGxbSzL7bdh1w== M;wLwFlIUl5xGxbSzL7bdh1w== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6 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, 20 Apr 2017 04:55:39 -0000 --Apple-Mail=_3560835E-A906-4B31-A819-E4FB2FEC06F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you (!) Mikael for the thorough review. The intent is to have it = be as complete a document with =E2=80=98rough concensus=E2=80=99 to = overall security considerations so your comments below are exactly what = we are looking for. Even during a last call. For group overall - I have privately sent the last call info to 6 = operational folks I know who don=E2=80=99t typically follow IETF lists = and asked for a thorough review. I know, shocking :) I had sent the = list to co-authors so they were aware. I=E2=80=99ll work with co-authors to also see how best to capture all = comments and get them resolved with =E2=80=98group concensus=E2=80=99. - merike > On Apr 19, 2017, at 8:26 AM, Mikael Abrahamsson = wrote: >=20 > On Wed, 12 Apr 2017, Gunter Van De Velde wrote: >=20 >> This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6. >> If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >>=20 >> I will close the call on 26 April 2017 >=20 > Hi, >=20 > I went through -11. Reading it and commenting as if I never read it = before (which I don't remember doing, but since I am mentioned in the = acknowledgement section I must have :) ) >=20 > 2.1.2. I would like to see the last paragraph moved to first in this = section, ie have the IETF recommendation start this off, not finish it. >=20 > Somewhere in 2.1.x, can we have a note about the /64 per host as a = means of tracking devices instead of having to track individual = addresses? >=20 > 2.3.1. I keep hearing people talk about SeND. The paragraph rightly = ends with with "SeND isn't widely available in implementations". Can we = start off with that? Also potentially move the whole SeND section to = later in 2.3.x so that the actually useful protocols come first? >=20 > 2.4.x. Should this document have all this text on router security? = Does this text say anything in opposition to RFC6192 that it starts off = with a reference to? >=20 > 2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I = think it should contain more such references. For instance, 2.6.1.4 = mentions using CLI tools to dump ND table. There is a YANG model for = that. >=20 > 2.6.1.4. Here is one example where /64 per host and only tracking = that, would be useful approach. >=20 > 2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and = where they are. I don't think if that's implied in the 6221 5.3.2 = reference? >=20 > 2.6.2.3 This is one of a few "..." in there. Is that really what we = want in a finished RFC? >=20 > 2.7. "Some text"? >=20 > 2.7.2. Blocking all tunnels? What's the recommendation here? "...it = could be helpful to block all default configuration tunnels"? >=20 > 2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and = TEREDO on all your enterprise machines (where you can, this was = specifically for enterprise Windows deployments). Shouldn't we mention = this here? Unless you know that you need it, turn it off? Or if there is = a document somewhere talking about this, reference it? >=20 > 2.7.2.4. I'd like to start this with the fact that anycast 6to4 has = been deprecated. >=20 >=20 > This document is a nice overview of a lot of topics, it contains lots = of good links to documents that are good for reader to know. I actually = think this is the best feature of this document, ie that it overviews a = lot of different topics and gives the reader ideas for further reading. = However, reading the document it felt a bit like there was a bit more = work needed. It's 95% there, but I think there are more things that = needs discussion. I also think this document needs wider review. = Notifying 6man and v6ops was a good thing. It seems there have been more = discussion there than here in OPSEC, but I think the authors follow = those groups as well. >=20 > So my comment for this in WGLC is that I would like to have more = people look at the document and I think we need a few more revisions = before it's ready for publication. Overall, I think this document = contains valuable information and after some more review and discussion = I definitely would like to see it published. >=20 >=20 >=20 > -- > Mikael Abrahamsson email: = swmike@swm.pp.se_______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_3560835E-A906-4B31-A819-E4FB2FEC06F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+D89AAoJEA7gPO9LJuahPBcIAIRnsDu87wwFiL/BuHr8iPfq b/Hb5BVdc5Uc2C3eTEZKIclZue/2Q1HbSZf5Ns2q8zbO9hSQWctvBwcfbqCrWDP0 4o84XoMur+CXWWJNQB5m7nujmnwjqcz9/eh3Ru4bDVQ0n9muFmoAYwVjdq85D3s4 gTA0m8ryUZleavRB5RLQrq4eyVQBzsIyyylCbOlbeSaaX2Dy0AhC9Oov4Dy9IZdT oPmPffm9GdX39gRg214YypA9E3YCg6Irqa/7ovHtgtVaRYURHJHAanDxl1EmmKt/ 8E27+CTi8A9KrLEPWxKgnS6zJOd/xphwLM2t4nEgtRkUe6veE/8u+PA/2bneTQ0= =8+5O -----END PGP SIGNATURE----- --Apple-Mail=_3560835E-A906-4B31-A819-E4FB2FEC06F6--