From nobody Tue Jun 7 01:56:14 2016 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 B694512B02F for ; Tue, 7 Jun 2016 01:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.348 X-Spam-Level: X-Spam-Status: No, score=-108.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 m4lnHT4GP2r1 for ; Tue, 7 Jun 2016 01:56:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B1212B024 for ; Tue, 7 Jun 2016 01:56:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 502DFB80F07; Tue, 7 Jun 2016 01:56:12 -0700 (PDT) To: dave@juniper.net, cpignata@cisco.com, rodunn@cisco.com, bclaise@cisco.com, joelja@bogus.com, gunter@vandevelde.cc, evyncke@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160607085612.502DFB80F07@rfc-editor.org> Date: Tue, 7 Jun 2016 01:56:12 -0700 (PDT) Archived-At: Cc: trond.endrestol@ximalas.info, opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] [Technical Errata Reported] RFC6192 (4705) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:56:13 -0000 The following errata report has been submitted for RFC6192, "Protecting the Router Control Plane". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6192&eid=4705 -------------------------------------- Type: Technical Reported by: Trond Endrestøl Section: A.1 Original Text ------------- ipv6 access-list EBGPv6 permit tcp host 2001:DB8:100::25 eq bgp any permit tcp host 2001:DB8:100::25 any eq bgp permit tcp host 2001:DB8:100::27 eq bgp any permit tcp host 2001:DB8:100::27 any eq bgp permit tcp host 2001:DB8:100::29 eq bgp any permit tcp host 2001:DB8:100::29 any eq bgp permit tcp host 2001:DB8:100::31 eq bgp any permit tcp host 2001:DB8:100::31 any eq bgp ip access-list extended DNS permit udp 198.51.100.0 0.0.0.252 eq domain any ipv6 access-list DNSv6 permit udp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any ip access-list extended NTP Corrected Text -------------- ipv6 access-list EBGPv6 permit tcp host 2001:DB8:100::25 eq bgp any permit tcp host 2001:DB8:100::25 any eq bgp permit tcp host 2001:DB8:100::27 eq bgp any permit tcp host 2001:DB8:100::27 any eq bgp permit tcp host 2001:DB8:100::29 eq bgp any permit tcp host 2001:DB8:100::29 any eq bgp permit tcp host 2001:DB8:100::31 eq bgp any permit tcp host 2001:DB8:100::31 any eq bgp ip access-list extended DNS permit udp 198.51.100.0 0.0.0.252 eq domain any permit tcp 198.51.100.0 0.0.0.252 eq domain any ipv6 access-list DNSv6 permit udp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any ip access-list extended NTP Notes ----- DNS is transported sometimes over UDP and sometimes over TCP. The Cisco example fails to demonstrate this behaviour in the case of IPv4. The Cisco example clearly shows this behaviour in the case of IPv6. The Juniper example in Section A.2 should be amended in the same fashion, however I'm unfamiliar with the proper JunOS syntax. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6192 (draft-ietf-opsec-protect-control-plane-06) -------------------------------------- Title : Protecting the Router Control Plane Publication Date : March 2011 Author(s) : D. Dugal, C. Pignataro, R. Dunn Category : INFORMATIONAL Source : Operational Security Capabilities for IP Network Infrastructure Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Jun 15 03:42:33 2016 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 62248127058; Wed, 15 Jun 2016 03:42:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615104232.20232.14466.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 03:42:32 -0700 Archived-At: Cc: opsec@ietf.org, opsec-chairs@ietf.org Subject: [OPSEC] opsec - Update to a Meeting Session Request for IETF 96 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 10:42:32 -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.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: 6man v6ops sidr homenet opsawg Special Requests: --------------------------------------------------------- From nobody Wed Jun 15 03:50:37 2016 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 5936112B064; Wed, 15 Jun 2016 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 KXWDHtHxagaR; Wed, 15 Jun 2016 03:50:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2123127058; Wed, 15 Jun 2016 03:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2894; q=dns/txt; s=iport; t=1465987830; x=1467197430; h=from:to:cc:subject:date:message-id:mime-version; bh=X4DVmmnfDqmSDA3KsHWR6/1nOYIzHGCyEqoWDqhEd7E=; b=RiKpSVOORtZYaSps/IJBST+Bx4H4ApUb7ydIytqEiMZbmLa6JoSbVim+ PNMiARXf5Gy+DetCYAHl+MvSDwwLXTXHmsDGn11SsY1E5DhL3sTyYrBos 1scwGUz3rGAeq2uKGRBQfZ1nyUpjhiZVfwZ0pYdv8bhr4txbqYhMPkUVB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgDBMWFX/49dJa1dgnBOVn0GtgiFA?= =?us-ascii?q?YF5IoV1HoEXOBQBAQEBAQEBZSeEUiNWEgEMAT0CBDAnBAENBYgwDq0FkQgBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYYnjA6CWgWYaQGBMIRUiCSPIo9zAR42g29ui?= =?us-ascii?q?Ql/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,475,1459814400"; d="scan'208,217";a="115417710" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 10:50:29 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5FAoTjw016409 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 10:50:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 06:50:29 -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.1104.009; Wed, 15 Jun 2016 06:50:29 -0400 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKA== Date: Wed, 15 Jun 2016 10:50:29 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.109.75] Content-Type: multipart/alternative; boundary="_000_D386FF9375916evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Howard, Lee" , "fgont@si6networks.com" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 10:50:32 -0000 --_000_D386FF9375916evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGF1dGhvcnMgKGFuZCBPUFNFQyBXRyBjaGFpcnMpIHdvdWxkIHJlYWxseSBhcHByZWNpYXRl IGlmIGEgcmV2aWV3IG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9w c2VjLXY2LTA4IGlzIGRvbmUgaW4gdGhlIGNvbWluZyBkYXlzL3dlZWtzIChpbiB0aW1lIHRvIHN1 Ym1pdCBhIC0wOSBpbiBjYXNlIGl0IG5lZWRzIHRvIGJlIGFtZW5kZWQpLg0KDQpUaGlzIEktRCBp cyBhYm91dCB0aGUgb3BlcmF0aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gb3BlcmF0 aW5nIGFuIElQdjYgbmV0d29yayAoYm90aCBhcyBTZXJ2aWNlIFByb3ZpZGVyIGFuZCBlbnRlcnBy aXNlL3N1YnNjcmliZXIpLg0KDQpUaGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3IgeW91ciByZXZp ZXcgYW5kIGJlIHN1cmUgdG8gaW5jbHVkZSBvcHNlY0BpZXRmLm9yZyBpbiB5b3VyIHJlcGx5Lg0K DQotIHRoZSBhdXRob3JzIChNZXJpa2UsIEtLIGFuZCBFcmljKQ0KLSB0aGUgY2hhaXJtZW4gKEd1 bnRlciBhbmQgRXJpYykNCg0KUFM6IE1hcmt1cywgRnJlZCwgRmVybmFuZG8gYW5kIExlZSwgYXMg eW91IGtpbmRseSB2b2x1bnRlZXJlZCB0byByZXZpZXcgaXQgZHVyaW5nIElFVEYtOTUsIEkgYWxz byBwdXQgeW91ciBuYW1lcyA7LSkNCg0KDQoNCg== --_000_D386FF9375916evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGUgYXV0aG9y cyAoYW5kIE9QU0VDIFdHIGNoYWlycykgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgaWYgYSByZXZp ZXcgb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vcHNlYy12Ni0wOCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3Bz ZWMtdjYtMDg8L2E+Jm5ic3A7aXMgZG9uZSBpbiB0aGUgY29taW5nIGRheXMvd2Vla3MgKGluIHRp bWUgdG8gc3VibWl0IGEgLTA5IGluIGNhc2UNCiBpdCBuZWVkcyB0byBiZSBhbWVuZGVkKS48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgSS1EIGlzIGFib3V0IHRoZSBvcGVyYXRp b24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hlbiBvcGVyYXRpbmcgYW4gSVB2NiBuZXR3b3Jr IChib3RoIGFzIFNlcnZpY2UgUHJvdmlkZXIgYW5kIGVudGVycHJpc2Uvc3Vic2NyaWJlcikuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3Ig eW91ciByZXZpZXcgYW5kIGJlIHN1cmUgdG8gaW5jbHVkZSBvcHNlY0BpZXRmLm9yZyBpbiB5b3Vy IHJlcGx5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSB0aGUgYXV0aG9ycyAoTWVy aWtlLCBLSyBhbmQgRXJpYyk8L2Rpdj4NCjxkaXY+LSB0aGUgY2hhaXJtZW4gKEd1bnRlciBhbmQg RXJpYyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBTOiBNYXJrdXMsIEZyZWQsIEZl cm5hbmRvIGFuZCBMZWUsIGFzIHlvdSBraW5kbHkgdm9sdW50ZWVyZWQgdG8gcmV2aWV3IGl0IGR1 cmluZyBJRVRGLTk1LCBJIGFsc28gcHV0IHlvdXIgbmFtZXMgOy0pPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D386FF9375916evynckeciscocom_-- From nobody Wed Jun 15 04:34:04 2016 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 EA68312D59F; Wed, 15 Jun 2016 04:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN2co57I4XN4; Wed, 15 Jun 2016 04:34:00 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) (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 10FF312D091; Wed, 15 Jun 2016 04:33:56 -0700 (PDT) Received: from [194.106.220.35] by server-4.bemta-14.messagelabs.com id 9F/F9-02097-32D31675; Wed, 15 Jun 2016 11:33:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRWlGSWpSXmKPExsUy9d9HH10l28R wgy0LtC2e7rzCYvFl/wJGiyer3rBZzNj2n83iw995LBYftt5lszh9bC+zA7vHlN8bWT2WLPnJ 5PHhUA+7x+o1r1g8rj7bwxzAGsWamZeUX5HAmnFzw132gn7BiiWNbewNjKv5uhi5OIQENjFKn O37zgzhHGCUeND7jgnCOcUo8WzvJ7YuRk4ONgF9iWWHjrCD2CICZRITn/5gBCliFrjGKDF10g 5GkISwgJXEwnVr2CCKrCU2T/nIAmEbSVz6vpkZxGYRUJXY+HAFUD0HB69AqMTSY6EgYSEBPYm mpgOsIDYn0K5vzb/AbEYBWYkvjavBWpkFxCVuPZnPBGJLCAhILNlznhnCFpV4+fgfK4StIHFp URcrRL2exI2pU9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg1ilOLy lKLdA0t9JKKMtMzSnITM3N0DQ1N9HJTi4sT01NzEpOK9ZLzczcxAuOynoGBcQfjke2ehxglOZ iURHk95BLDhfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwTrEGygkWpaanVqRl5gATBExagoNHSYS 3HSTNW1yQmFucmQ6ROsVoz3Fn8Y21TBw/Ou4DyVvPHgDJTxMOHGMSYsnLz0uVEuedBNImANKW UZoHNxSW0C4xykoJ8zIyMDAI8RSkFuVmlqDKv2IU52BUEuZ9ADKFJzOvBG73K6CzmIDOspkeD 3JWSSJCSqqB0e30zrP80pq3Fu9dMe0Pj7/pdXveRzPfnJ8j+ao+h+eIHOdR9gndhWb5+3dZnv 0+bVvkldnhDzJNX636fqj4ZbAAN+PXg7Mn8PhUbDx6xm367C4W+4frmboXPP57PtC1K0U//k/ hzufLXf+udDjnfJw19ZLIqkmxqZE5++tspm7MqFjQr/Voo6sSS3FGoqEWc1FxIgB36RPbYwMA AA== X-Env-Sender: robert.sleigh@ee.co.uk X-Msg-Ref: server-6.tower-91.messagelabs.com!1465990434!37011938!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19803 invoked from network); 15 Jun 2016 11:33:54 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-6.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2016 11:33:54 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 15 Jun 2016 12:33:42 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Wed, 15 Jun 2016 12:33:53 +0100 Received: from UK30S005EXS05.EEAD.EEINT.CO.UK ([fe80::8c76:d4fb:393f:9994]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0279.002; Wed, 15 Jun 2016 12:33:53 +0100 From: "Sleigh, Robert" To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qXYkg Date: Wed, 15 Jun 2016 11:33:53 +0000 Message-ID: <679694A32AB94046931C676BEF4BA8B85123EA84@UK30S005EXS05.EEAD.EEINT.CO.UK> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Howard, Lee" , "fgont@si6networks.com" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 11:34:03 -0000 Hi Eric et al. Great doc, thanks. Just a couple of typos I spotted. 2.1.2 "This means that using ULA does not prevent route and packet filters to b= e implemented and monitored." Should this read:=20 "This means that using ULA does not prevent route and packet filters havi= ng to be implemented and monitored." 2.7.2.8 "the audit log are easier to manager" Should this read: "the audit logs are easier to manage" Hope this helps Regards Bob 07958 318592 From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evy= ncke) Sent: 15 June 2016 11:50 To: opsec@ietf.org; v6ops@ietf.org Cc: Howard, Lee; fgont@si6networks.com; draft-ietf-opsec-v6@ietf.org; lin= kedin@xn--debrn-nva.de Subject: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 The authors (and OPSEC WG chairs) would really appreciate if a review of=A0= https://tools.ietf.org/html/draft-ietf-opsec-v6-08=A0is done in the comin= g days/weeks (in time to submit a -09 in case it needs to be amended). This I-D is about the operation security considerations when operating an= =20IPv6 network (both as Service Provider and enterprise/subscriber). Thanks a lot in advance for your review and be sure to include opsec@ietf= .org in your reply. - the authors (Merike, KK and Eric) - the chairmen (Gunter and Eric) PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review i= t during IETF-95, I also put your names ;-) NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, dist= ributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately on= =20the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, A= L10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From linkedin@xn--debrn-nva.de Wed Jun 15 06:05:31 2016 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 1365A12D677; Wed, 15 Jun 2016 06:05:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 4P3EJKojH9Ed; Wed, 15 Jun 2016 06:05:28 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB2312D60D; Wed, 15 Jun 2016 06:05:02 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1465995895129657.7123757883129; Wed, 15 Jun 2016 06:04:55 -0700 (PDT) Date: Wed, 15 Jun 2016 15:04:54 +0200 From: Markus deBruen To: "Eric Vyncke (evyncke)" Message-ID: <155542a20aa.f178b1d213436.8516278435436621650@xn--debrn-nva.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_31302_6541596.1465995894976" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: X-Mailman-Approved-At: Wed, 15 Jun 2016 09:41:40 -0700 Cc: "Howard, Lee" , "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "fgont@si6networks.com" Subject: Re: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 13:19:13 -0000 ------=_Part_31302_6541596.1465995894976 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi Eric, the draft is very well written and contains useful guidance/recommendations. Sections 2.4 and 2.5 do not contain much IPv6-specific information and sections 2.7.2.* do not give much guidance. However, these three sections together amount to ~11 pages (1/3 of the document). If you could shorten these sections, the document would become more manageable. Some minor comments and nits: 2.1.2 "... The latter would be problematic." I suspect by "latter" you mean NPTv6. Better make that explicit. "A typical argument is that there are too many mistakes made with filters and ULAs make things easier to hide machines." Why "to hide machienes"? I would suggest "to set filters". 2.1.4 "... privacy extension addresses should be used" Punctuation mark is missing. 2.2 still TBD 2.3.2 "... for protecting hosts connected against..." "Connected hosts" maybe!? 2.3.4 "RFC6980 [RFC6980] aims to update RFC4861 [RFC4861]" "[RFC6980] updates [RFC4861]" 2.7.2 "embeb" -> embed 2.7.2.4 "... operational problems" Punctuation mark is missing. 2.7.2.8 The second "MAP-E" should be "MAP-T". 2.8 "device to authenticated" -> "device authenticated" 3.1 "bogon and reserved space" Some links might be helpful (e.g. to IANA). 5 "[RFC7084] (which obsoletes [RFC6204]" Missing ")" "[RFC7084] states that a clear choice must be given to the user to select one of those two policies." Does it? I did not find the corresponding passage. Throughout the document there are some "IPV6", "DOS" and " ", which should be replaced with "IPv6", "DoS" and " ". I hope these comments are helpful. Cheers, Markus ---- Ein Mi, 15 Jun 2016 12:50:29 +0200 Eric Vyncke (evyncke)<evyncke@cisco.com> hat geschrieben ---- The authors (and OPSEC WG chairs) would really appreciate if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-08 is done in the coming days/weeks (in time to submit a -09 in case it needs to be amended). This I-D is about the operation security considerations when operating an IPv6 network (both as Service Provider and enterprise/subscriber). Thanks a lot in advance for your review and be sure to include opsec@ietf.org in your reply. - the authors (Merike, KK and Eric) - the chairmen (Gunter and Eric) PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review it during IETF-95, I also put your names ;-) ------=_Part_31302_6541596.1465995894976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Eric, = ;

th= e draft is very well written and contains useful guidance/recommendations. Sections 2.4 and 2.5 do not contain= much IPv6-specific information and sections 2.7.2.* do not give much guidance. However, t= hese three sect= ions together amount to ~11 pages (1/3 of the document). If you could shorten these sectio= ns, the document would become more manageable. 

Some minor comments and nits: 
2.1.= 2 
"... The latter would be problematic."&nbs= p;
I suspect by "latter" you mean NPTv6. Better ma= ke that explicit. 

"A typical argument is that there are too many mistakes= made with filters and 
ULAs make things easi= er to hide machines." 
Why "to hide machienes= "? I would suggest "to set filters". 

2.1.4 
"... privacy extension addresses should be used" 
Punctuation mark is missing. 

2.2 
sti= ll TBD 

2.3.2 
<= span style=3D"font-family: Verdana, arial, Helvetica, sans-serif; font-size= : 12px; background-color: rgb(255, 255, 255);">"... for protecting hosts co= nnected against..." 
"Connected hosts" maybe!= ? 

2.3.4 
"RFC6980 [RFC6980] aims to update = RFC4861 [RFC4861]" 
"[RFC6980] updates [RFC48= 61]" 

2.7.2 
"embeb" -> embed 

2.7.2.4&n= bsp;
"... operational problems" 
Punctuation mark is missing. 

2.7.2.8 
The second "MAP-E" should be "MAP-T". 

2.8 
"device to authenticated" -> "device authenticated" 

3.1 = ;
"bogon and reserved space" 
Some links might be helpful (e.g. to IANA). 

5 
"[RFC7084] (which obsoletes [RFC6204]" 
Missing ")" 

"[RFC7084] states that a clear choice must be given= to the user to select one 
of those two poli= cies." 
Does it? I did not find the correspon= ding passage. 
Throughout the document there are some "IPV6", "DOS" and " = ", which should be 
replaced with "IPv6", "Do= S" and " ". 

I hope these comments are helpful. 

Cheers, 
Markus 

<= div>
<= br>---- Ein Mi, 15 Jun 2016 12:50:29 +0200 Eric Vyncke (evyncke)<evyn= cke@cisco.com> hat geschrieben ----
=
The authors (and OPSEC WG chairs) would really appreciate= if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-= 08 is done in the coming days/weeks (in time to submit a -09 in ca= se it needs to be amended).

This I-D is about = the operation security considerations when operating an IPv6 network (both = as Service Provider and enterprise/subscriber).

Thanks a lot in advance for your review and be sure to include opsec@ietf.org in your reply.

- the a= uthors (Merike, KK and Eric)
- the chairmen (Gunter and Eric)

PS: Markus, Fred, Fernando and Lee, as you kindly= volunteered to review it during IETF-95, I also put your names ;-)
<= div>



=

------=_Part_31302_6541596.1465995894976-- From nobody Wed Jun 15 12:46:12 2016 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 DB17412B061 for ; Wed, 15 Jun 2016 12:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, 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 V24HzO-aqafH for ; Wed, 15 Jun 2016 12:45:52 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 A0A1112DB5F for ; Wed, 15 Jun 2016 12:45:51 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z189so117459743itg.0 for ; Wed, 15 Jun 2016 12:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=omBwBiGMd45HWvOrFNbCn7Hf7SriMU3CNzSeCp5Cr8o=; b=M/f8nbf0jhQgOSSWoisDWB5QO5SDfunxrYPnhw7g8XGgX7lvDGvFGE1MKMHw2L9I5K hqkTYs3GGLN0MWXNXv6Bw9PzwIvwetCDeNMgc6vixGHCQx2Xx34cXaOL+6Q/oK05fWJC lqLjj9tlmBrZALhfdyrAyxO9iDBRhdkvKhjBNUAEKaBB+NeRU31ummZdAhfwalnQDeXG 2pta7ssVF5VpGE1Kh6laX0x5f2LeKXiaUNAS0RFAQMI5HcTTiwXmXLpISG7xGAu+j9pS OXTUgWcMKGkPUjKGBTLDhxQ6OeflTJuESMN7hYXMu++rS7zE059MgoqQyWe/o57iJ6Is i4vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=omBwBiGMd45HWvOrFNbCn7Hf7SriMU3CNzSeCp5Cr8o=; b=eMt5tPpKTh3RJcO7/yPwvCTC/lBUQxHsBVAAS5SYJ8Kbd4ShMSbSIixk9up8P5SCk0 fSMpVcZrF7eUMldyeXNYyE8aintoZrtejwPQD6K3eiIkW6jiOwv9dJ87KupPmYAG11HV qaDCg52c8eX7hbF6kJNBTw7/pBe1SUhZSW0CIY46tWQJM+//dwpZ3AEWvkafavxvOher 4R0TQLu359aYgAtDt8pptN+LI0uoNg0BYPhGA4CiPCpHa+EL23JjNTlGFxMjfPNVORWZ l8cRvygw+VveDtvBItqezexJoJJK53I6H/f5L/JRbQlb87CwgJzBute+7pGolJjYH8E6 N6IA== X-Gm-Message-State: ALyK8tLBUre64EzS3XHtehmymvShUZ7f8nviHFGA8wtb8Y69Ac6OibrlvQBG+f4SU/Yt2hUq+6Hy7V7G7xXy+LB6 X-Received: by 10.36.249.137 with SMTP id l131mr3929866ith.21.1466019950823; Wed, 15 Jun 2016 12:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.74 with HTTP; Wed, 15 Jun 2016 12:45:31 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Wed, 15 Jun 2016 12:45:31 -0700 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "v6ops@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:45:54 -0000 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. Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We should, in my opinion, make it painfully clear that DHCP (of any protocol) in the absence of link-layer security/auditability features does not provide any satisfactory way "to ensure audibility and traceability" [Section 2.1.6]. From nobody Wed Jun 15 13:05:18 2016 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 07D9D12DB3C; Wed, 15 Jun 2016 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 nsjwlYn4ldi2; Wed, 15 Jun 2016 13:05:15 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EAF12D922; Wed, 15 Jun 2016 13:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15152; q=dns/txt; s=iport; t=1466021115; x=1467230715; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y7RmyWGMb23pXL0RVueLuX8bN+IZNhguOk3MQaCHJDs=; b=gIyNjnrHe4vi6WuPmXsOGq8AwToo8IEDQS0EYcmAFReJ/oVAMyPBE73a i19ps8hTbTYu9FLyo/luSzEsiYWyxENYHmJGhq/9vedly+W2x8GGetnWb M42L+T1GAPyuZlHDvIpyjq3BhmhqkEtMWz2oit+SZXvBMCCFDFpaQrWE7 M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAMtGFX/4cNJK1TCoM+Vm4PBrpmg?= =?us-ascii?q?XkegkKDNwKBNDgUAQEBAQEBAWUnhEwBAQMBeQULAgEIEjQyFwENAgQOE4gaCL8?= =?us-ascii?q?4AQEBAQEBAQEBAQEBAQEBAQEBARAOiB6BU4EDhBIGCwFagm6CLwWNcYp4AYMtg?= =?us-ascii?q?WmJEo8ij3MBHjaCBxyBTG6IRA8XBBt/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,477,1459814400"; d="asc'?scan'208";a="284222330" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2016 20:05:14 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5FK5Equ024447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 20:05:14 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 15:05:13 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Wed, 15 Jun 2016 15:05:13 -0500 From: "Fred Baker (fred)" To: "Eric Vyncke (evyncke)" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx0E6+A92vAUQaEOO/MuVxVmKUg== Date: Wed, 15 Jun 2016 20:05:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.125] Content-Type: multipart/signed; boundary="Apple-Mail=_9FE73915-5E47-47FC-8171-36F0DAC137C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "Howard, Lee" , "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:05:17 -0000 --Apple-Mail=_9FE73915-5E47-47FC-8171-36F0DAC137C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One thing I wondered about as reading this - many and perhaps most = sections gave a fairly informative comment, and then made one or two = recommendations. I wonder (this is a question) whether it would be = worthwhile capitalizing "RECOMMEND", both in the sense of defining the = term (RFC 2119) and highlighting it in the text. I also wonder if it = would make sense to pull together a list of recommendations made in a = table somewhere, perhaps in an appendix. I could imagine someone wanting = a list of them without wading through the text. > 1. Introduction >=20 > Running an IPv6 network is new for most operators not only because > they are not yet used to large scale IPv6 networks but also because > there are subtle differences between IPv4 and IPv6 especially with > respect to security. For example, all layer-2 interactions are now > done by Neighbor Discovery Protocol [RFC4861] rather than by = Address s/by/using/, twice. As worded, it sounds like NDP and ARP doing this by = themselves, as *actors*; no, the *system* does them using NDP and ARP as = its *language*. > Resolution Protocol [RFC0826]. Also, there are subtle differences > between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out = in > the latter's security considerations section. For NAT44, I might also point to RFC 2993 and maybe 4864. > IPv6 networks are deployed using a variety of techniques, each of > which have their own specific security concerns. > 2. Generic Security Considerations >=20 > 2.1. Addressing Architecture >=20 > IPv6 address allocations and overall architecture are an important > part of securing IPv6. Typically what you initially design for = will > be what you use for a very long time. This sentence is in the second person ("you"), and most of the document = is third person ("it"). Reword as "Initial designs, even if intended to = be temporary, tend to last much longer than expected"? > Although initially IPv6 was > thought to make renumbering easy, in practice, it would be = extremely > difficult to renumber. I would temper the statement. As we said in RFC 4192, the problems with = renumbering tends to be the places where a number is written into a = static configuration rather than managed using a database or whatever, = and the places where people cut corners ("its address will never change, = so I don't need to worry about its name and DNS"). I would find myself = saying that good OSS trumps static configurations, and in IPv6, systems = change at least their IIDs from time to time (RFC 7721). It's not that = IPv6 (or IPv4) is hard to renumber, it's that the required operational = support is often not there or not workable due to poor practice. > Once an address allocation has been assigned, there should be some > thought given to an overall address allocation plan. With the > abundance of address space available, an address allocation may be > structured around services along with geographic locations, which "topology"? Topology is often structured geographically, yes, but if A = provides services to B and C and is a logical gateway to them, A, B, and = C can be grouped for management purposes even if they are not in the = same geographic location. > then can be a basis for more structured security policies to permit > or deny services between geographic regions. >=20 > A common question is whether companies should use PI vs PA space > [RFC7381] but from a security perspective there is little = difference. comma after "[RFC7381]". > However, one aspect to keep in mind is who has ownership of the > address space and who is responsible if/when Law Enforcement may = need > to enforce restrictions on routability of the space due to = malicious > criminal activity. Pregnant statement. I find myself wondering about the implications of = "ownership" and "law enforcement restrictions on routability". In = "ownership", are you pointing to issues when you change providers and = therefore need to change PA addresses? If not, something else? In "LEA = issues", are you talking about law enforcement blocking the address = space, turning BGP announcements off, etc? > 2.1.1. Statically Configured Addresses >=20 > When considering how to assign statically configured addresses it = is > necessary to take into consideration the effectiveness of perimeter > security in a given environment. There is a trade-off between ease > of operational deployment where some portions of the IPv6 address > could be easily recognizable for operational debugging and > troubleshooting versus the risk of scanning; [SCANNING] shows that > there are scientifically based mechanisms that make scanning for = IPv6 > reachable nodes more realizable than expected. The use of common > multicast groups which are defined for important networked devices > and the use of commonly repeated addresses could make it easy to > figure out which devices are name servers, routers or other = critical > devices. >=20 > While in some environments the perimeter security is so poor that > obfuscating addresses is considered a benefit; it is a better > practice to ensure that perimeter rules are actively checked and > enforced and that statically configured addresses follow some = logical > allocation scheme for ease of operation. I find myself on both sides of the prophylactic security discussion. I = compare and network and its defenses to the human immune system, and = perimeter security to the skin. I favor having a working perimeter = security system much like I favor a functional skin, and for the same = immunologic reasons. That said, the body provides the defense, reducing = the rate at which it needs to bring other systems into play, and then = assumes it has been breached; a person whose only immunologic defense is = their skin is an AIDS patient, and doesn't have a good prognosis. My = fundamental problem with most network security systems is that they = over-emphasize perimeter security. I say that because this paragraph seems to over-emphasize perimeter = security - "in some environments the perimeter security is so poor...". = I think I would say that "security is so poor". I would be tempted to go = beyond to talk about the ways a remote network can be mapped, such as by = observing email envelopes and addresses found in WWW logs etc, and the = value of temporary random addresses (as opposed to permanent addresses, = whether DHCP -assigned or MAC/SLAAC). But I agree with the recommendation. > 2.1.2. Use of ULAs >=20 > ULAs are intended for scenarios where IP addresses will not have > global scope. The implicit expectation from the RFC is that all = ULAs > will be randomly created as /48s. Any use of ULAs that are not > created as a /48 violates RFC4193 [RFC4193]. Mention also that they are expected to not be announced, and if = announced not accepted, in BGP? > ULAs could be useful for infrastructure hiding as described in > RFC4864 [RFC4864]; I believe that at least one cable operator uses them for cable modem = addresses, which need no GUA and want to be hidden. Personally, I think = that's a better use of a ULA - for something does doesn't actually need = a global address. The paragraph here seems to assume that the only valid = use of a ULA is as a counterpart to RFC 1918, and with NAT. I'd really wish that we could talk about infrastructure (count the = addresses in the envelope of this email; they are mostly infrastructure = addresses) and internal-only services (wwwin-SERVICE.cisco.com names = being a classic Cisco example, to my mind) when we start a paragraph = with a comment on "infrastructure hiding", rather than proceeding = directly to NAT. > 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC > ... > As privacy extension addresses could also be used to obfuscate some > malevolent activities (whether on purpose or not), it is advised in > scenarios where user attribution is important to disable SLAAC and > rely only on DHCPv6. However, in scenarios where anonymity is a > strong desire since protecting user privacy is more important than > user attribution, privacy extension addresses should be used No mention of IEEE 802.1X? > Using privacy extension addresses prevents the operator from = building > a priori host specific access control lists (ACLs). It must be = noted > that recent versions of Windows do not use the MAC address anymore = to > build the stable address but use a mechanism similar to the one > described in [RFC7217], this also means that such an ACL cannot be > configured based solely on the MAC address of the nodes, = diminishing > the value of such ACL. On the other hand, different VLANs are = often > used to segregate users, then ACL can rely on a /64 prefix per VLAN > rather than a per host ACL entry. "then ACL"? Either I don't understand the sentence, or you meant "the". > 2.1.6. DHCP/DNS Considerations >=20 > Many environments use DHCPv6 to allocate addresses to ensure > audibility and traceability (but see Section 2.6.1.5). A main audit-ability > security concern is the ability to detect and mitigate against = rogue > DHCP servers (Section 2.3.2). I think you want to say "counteract" rather than "mitigate against". > 2.3.5. 3GPP Link-Layer Security >=20 > The 3GPP link is a point-to-point like link that has no link-layer > address. This implies there can only be an end host (the mobile > hand-set) and the first-hop router (i.e., a GPRS Gatewat Support = Node Gateway > 2.4. Control Plane Security >=20 > RFC6192 [RFC6192] defines the router control plane and this > definition is repeated here for the reader's convenience. Run-on sentence. Replace "and" with a period and capitalize the next = word. > Modern router architecture design maintains a strict separation of > forwarding and router control plane hardware and software. The > router control plane supports routing and management functions. It > is generally described as the router architecture hardware and > software components for handling packets destined to the device > itself as well as building and sending packets originated locally = on > the device. I'm having trouble parsing the above sentence... > The forwarding plane is typically described as the > router architecture hardware and software components responsible = for >=20 >=20 >=20 > Chittimaneni, et al. Expires September 22, 2016 [Page = 11] > Internet-Draft OPsec IPV6 March = 2016 >=20 >=20 > receiving a packet on an incoming interface, performing a lookup to > identify the packet's IP next hop and determine the best outgoing > interface towards the destination, and forwarding the packet out > through the appropriate outgoing interface. I'm having trouble parsing the above as well. I'd suggest breaking it = into 2-3 sentences. > 2.4.3. Packet Exceptions >=20 > This class covers multiple cases where a data plane packet is = punted > to the route processor because it requires specific processing: > ... > o processing of the hop-by-hop extension header; May I suggest the authors comment on draft-ietf-6man-hbh-header-handling = as it progresses? Let's not let that and this conflict. > 2.6.1.1. Logs of Applications > ... > #!/usr/bin/perl ?w Should that be "-w"? > use strict ; > use warnings ; > use Socket ; > use Socket6 ; >=20 > my (@words, $word, $binary_address) ; >=20 > ## go through the file one line at a time > while (my $line =3D ) { > chomp $line; > foreach my $word (split /[ \n]/, $line) { replace "[ \n]" with "\s+". \s includes any white space character, = including a space, a tab, \n, \r, and a couple of others. The "+" = specifies strings of one or more in length. > $binary_address =3D inet_pton AF_INET6, $word ; > if ($binary_address) { > print inet_ntop AF_INET6, $binary_address ; > } else { > print $word ; > } > print " " ; > } > print "\n" ; > } > 2.7.1. Dual Stack >=20 > Dual stack has established itself as the preferred deployment = choice > for most network operators without a MPLS core where 6PE RFC4798 without *an* MPLS core... > 2.7.3.2. NAT64/DNS64 >=20 > Stateful NAT64 translation [RFC6146] allows IPv6-only clients to > contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be = used > in conjunction with DNS64 [RFC6147], a mechanism which synthesizes > AAAA records from existing A records. >=20 > The Security Consideration sections of [RFC6146] and [RFC6147] list > the comprehensive issues. A specific issue with the use of NAT64 = is > that it will interfere with most IPsec deployments unless UDP > encapsulation is used. DNS64 has an incidence on DNSSEC see = section > 3.1 of [RFC7050]. You might want to mention 6145, draft-bao-v6ops-rfc6145bis, and SIIT-DC. > 3.1. External Security Considerations: You mention having a firewall that only permits inbound traffic that = corresponds to an active session. Would RFC 6092 be worth mentioning in = that context? > 5. Residential Users Security Considerations Would RFC 6092 be worth mentioning in this context? --Apple-Mail=_9FE73915-5E47-47FC-8171-36F0DAC137C2 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 iQIVAwUBV2G0+EayAOS/EQ8MAQKmeQ//S/gznyWWipmCR5zaSh+eHGdsdBiFlSCI hWDt0vaeA0gdY4AWRL3takWBtkzCQgFd9N4tgGgWx8CK1FHTQNrJ4BwNmdxdUO2S L4rSop3Kg5xJJ2esZ0ULXT+a3D0lqplrHh6erNvwhjWO2zvhuWDKQWvNXfnTwbfI 5FmBBcnFkM6zBZkfR9gBLWP2mZrxJ32dnc2+1h2l7aCr30TPQVDRMJQVZDjc9hse pLEXMRZYPXPbGT1J/sriVB1Kmx/FivnctPZupiIWbdn5IXnzFnnNSyrGoiHz9N+Z PvAHQLCnW5W4b8hfJujaqKPe+q7mg7rar1GJ+xY3loR9XO3FkXpspxZvBZ0pIeH9 W87m+Jh9Y/Kq5STPusF+9QASpht4VFG2pNdwQOj7eEQVQgcBe672ryBMWAZ4S/j2 jWmjFoikZhHoJQIrKQGtg4uWBgCskj5lgjEd77MNU6VMTwtlhJinNvmG4DU86fDn XHL+PlJiJYBvGnRipu5vjf0+eGsiop/1PaS23c8EOctGvqx5eXhlgTVYz2ZpHMWx GkmPYkGPYwRRTq4M1Y8BB6GdpnNE8X6dW3yFLBte3NZH3Kux46byUWvlStOIisWy oDjUJuLWhW+3/fyaP5LmJZElyMQZO3ljKt4oJzwUGKPuh37qCqTBQjL1uNqDt8lv WDuwljIuVFo= =Skto -----END PGP SIGNATURE----- --Apple-Mail=_9FE73915-5E47-47FC-8171-36F0DAC137C2-- From nobody Wed Jun 15 16:44:48 2016 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 9617D12D8E3; Wed, 15 Jun 2016 16:44:46 -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 dnH0L8oJUF0M; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 BC31712D82E; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id b13so11913579pat.0; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5B2GvNITSKw42f1FqlRcZGu+CcHDeUTeY0tQKUgJxSo=; b=Gi3F2T92tylZBgY5MEKVTGXqOxHmwLLU0ZNmyh0NtdkdmibURU1glMPAdV5edi5RjV 1mR9jthpRMPH/GHRuDIBIHL6GK8RmqrPZsbC+4pj0wa3PWghILbR1JcOkVsrIWs7LmDR rrG/o8VEINg6X6KeiWizl/ej73QPn7teEoVjom1bMQnVP2kEC8xlCcdrUgzKXggIZ0Dp 2964MUqDU80oai56FUUtyIPTrGaHdGLYvD89FHCQoXVFLOKIg4UmG0xfBBLehVJ5Hsuz yqeLnPiuFGH9/SkeTyrQ6EOU5MCmUg2QINTbsG4qTeJvWCXMrskNcvczTIaah6MCQsgS qmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=5B2GvNITSKw42f1FqlRcZGu+CcHDeUTeY0tQKUgJxSo=; b=aIlQJtQkww2Dmd/k3WjlQjvYAuL779w923IBbtol4n8m4xyB0ur/VHy+vhx/g6RO39 2uz2apgcnM8HRWaDwdqeEN2WdygKBXEyoKaQ4+y9ZgUgQ+QkRHLU3d1h1ou4srx8FoVb 6Ogh25Jjoyde3axv52tWxxjDPaOhaZJ1QS2BjDc8hXYhMr4wSghc23GEGEvvwAMyGkyI bOy7s7eUWUpBK+2wZypoHfxcsjYdcai6v9ZrvxkzmvF3TA/zPsrE3sdljL3yjsaJeLyG pItXUjCw/NJ2Gr3nycehuFu9BIhV4ybFolKHGNGtoWfOj+KvpiPdnvfAJIgQ9FkgSknf /ztQ== X-Gm-Message-State: ALyK8tL+0CkOOzdEb3ky3+SZiEZkbfohOvQMgk9dQNMecjeEGhOssq4lhPFfTPigKgLQdg== X-Received: by 10.66.135.40 with SMTP id pp8mr1448239pab.113.1466034284288; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ih15sm55526875pab.38.2016.06.15.16.44.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 16:44:43 -0700 (PDT) To: Erik Kline , "Eric Vyncke (evyncke)" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> Date: Thu, 16 Jun 2016 11:44:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "draft-ietf-opsec-v6@ietf.org" , "v6ops@ietf.org" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:44:46 -0000 On 16/06/2016 07:45, 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. I have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT != security. While I'm here, some other points: "2.2. Extension Headers TBD, a short section referring to all Fernando's I-D & RFC." That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance to security aspects. Second, there is no reason to refer to most of the material (Fernando's or not) unless it's directly relevant to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering, but only if that document is going anywhere. "2.3.3. ND/RA Rate Limiting ... The following drafts are actively discussing methods to rate limit RAs and other ND messages on wifi networks in order to address this issue: o [I-D.thubert-savi-ra-throttler] o [I-D.chakrabarti-nordmark-6man-efficient-nd]" Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. "4.2. Transition Mechanism SP will typically use transition mechanisms such as 6rd, 6PE, MAP, DS-Lite which have been analyzed in the transition Section 2.7.2 section." Shouldn't you add RFC6877 464XLAT now? Finally, I think there should be a Privacy Considerations section. Rgds Brian > > Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > should, in my opinion, make it painfully clear that DHCP (of any > protocol) in the absence of link-layer security/auditability features > does not provide any satisfactory way "to ensure audibility and > traceability" [Section 2.1.6]. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jun 16 02:15:24 2016 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 9AFED12D0BA; Thu, 16 Jun 2016 02:15:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0bjFTu-mqwM; Thu, 16 Jun 2016 02:15:21 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05212D0A4; Thu, 16 Jun 2016 02:15:20 -0700 (PDT) Received: from [85.158.143.99] by server-1.bemta-6.messagelabs.com id 03/3D-09256-72E62675; Thu, 16 Jun 2016 09:15:19 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRWlGSWpSXmKPExsVy+JUil656XlK 4webPbBZPd15hsfiw9S6bxelje5kdmD2WLPnJFMAYxZqZl5RfkcCaMWHNPcaC6woVsw+vY25g XKDQxcjJISSwnlHi8xGfLkYuIHsPo8Sf6f+ZQRJsAjoS/5fvYgexRQRqJaYc/8MMUsQs8IVR4 ticVUxdjBwcwgJeEhc7vSFqvCUa3v5mhbCdJFrnnWABsVkEVCXWdb8Gi/MKOEt8njqfBWLxMk aJWWuKQGxOAVuJjz+fgNUwCshKfGlcDXYDs4C4xK0n85lAbAkBAYkle84zQ9iiEi8f/2OFsBU kVlyaAHYOs4CmxPpd+hCtihJTuh+yQ6wVlDg58wnUWhWJ9gXLoFqDJU6c3M8ygVFsFpJtsxAm zUIyaRaSSQsYWVYxqhenFpWlFuka6iUVZaZnlOQmZuboGhqY6eWmFhcnpqfmJCYV6yXn525iB EYVAxDsYNz53OkQoyQHk5Ior6NGUrgQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCV7RXKCcYFFqem pFWmYOML5h0hIcPEoivO9ygNK8xQWJucWZ6RCpU4yWHHcW31jLxHHr2QMg+WnCgWNMQix5+Xm pUuK8/CDzBEAaMkrz4MbBUtAlRlkpYV5GoAOFeApSi3IzS1DlXzGKczAqCfM+AVnLk5lXArf1 FdBBTEAH2UyPBzmoJBEhJdXAaK87sedEw0/zFz6bnrdd360cuH55okFE1qRntacfWKyc1rdU6 9n0x16vNUW2rzP3+Wt862bG9ruyBtfzOC/rb5zMsMvEfMnz46dfZDSZbFi8Y8c+tQXRU9ICtu hFHGa8td1swiWu2JnijL1mS+bskHG+JHxNtbvhjsenoxJ8h4tqi0U/cnjeslRiKc5INNRiLip OBAC4Ac88PAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1466068518!11174090!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 35496 invoked from network); 16 Jun 2016 09:15:19 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-13.tower-216.messagelabs.com with SMTP; 16 Jun 2016 09:15:19 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 11:15:18 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 11:15:18 +0200 From: Marco Ermini To: Brian E Carpenter , Erik Kline , "Eric Vyncke (evyncke)" Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qzYSAgABC14CAAMBooA== Date: Thu, 16 Jun 2016 09:15:17 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> In-Reply-To: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.15.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 09:15:18.0659 (UTC) FILETIME=[99F46530:01D1C7AF] Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:15:22 -0000 V2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNlY3VyaXR5 LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3QgdG8gc2F5 IHRoYXQgaXQgaXMgbm90Lg0KDQpJIHBlcnNvbmFsbHkgZG9uJ3Qgc3ltcGF0aGl6ZSBvbiBOQVQt aGF0ZXJzLiAgTkFUIGhhcyBpdHMgcmVhc29ucywgZXNwZWNpYWxseSBmb3IgY2Fycmllci1ncmFk ZSBOQVQgYW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5hcmlvLCBhbmQgeWVzLCBpdCBk b2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFnYWluLCBub3QgdGhlIGNvbXBs ZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLg0KDQoNClJlZ2FyZHMsDQrigIvigIvigIvigIvigIsN Ck1hcmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRA0K U2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1MjMgwqBNwqAr NDkgKDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KU2VudDogVGh1cnNkYXksIEp1bmUg MTYsIDIwMTYgMTo0NSBBTQ0KVG86IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKQ0K Q2M6IGZnb250QHNpNm5ldHdvcmtzLmNvbTsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1k ZWJybi1udmEuZGU7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW09QU0VDXSBbdjZvcHNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1vcHNlYy12Ni0wOA0KDQpPbiAxNi8wNi8yMDE2IDA3OjQ1LCBFcmlrIEtsaW5lIHdy b3RlOg0KPiBTZWN0aW9uIDIuMS4yIGlzIGZhciB0b28gcGVybWlzc2l2ZSBmb3IgbXkgdGFzdGVz LiAgV2UgbmVlZCB0byBiZSBhYmxlIA0KPiB0byBzYXkgdGhhdCBVTEErSVB2NiBOQVQgaXMgTk9U IFJFQ09NTUVOREVEIGJ5IHRoZSBJRVRGLg0KDQpJIGhhdmUgc3Ryb25nIHN5bXBhdGh5IHdpdGgg dGhhdCBzdGF0ZW1lbnQsIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIGRvY3VtZW50IHRv IGRvIGl0OyB0aGUgcG9pbnQgaXMgbWFkZSBpbiBSRkM0ODY0IHRvby4gV2hhdCB3ZSBzaG91bGQg ZG8gaGVyZSBpcyB1bmRlcmxpbmUgdGhhdCBOQVQgIT0gc2VjdXJpdHkuDQoNCldoaWxlIEknbSBo ZXJlLCBzb21lIG90aGVyIHBvaW50czoNCg0KIjIuMi4gIEV4dGVuc2lvbiBIZWFkZXJzDQoNCiAg IFRCRCwgYSBzaG9ydCBzZWN0aW9uIHJlZmVycmluZyB0byBhbGwgRmVybmFuZG8ncyBJLUQgJiBS RkMuIg0KDQpUaGF0J3Mgbm90IHRoZSB3aG9sZSBzdG9yeSA7LSkuIEZpcnN0bHksIFJGQyA3MDQ1 IGhhcyBhIGxvdCBvZiByZWxldmFuY2UgdG8gc2VjdXJpdHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVy ZSBpcyBubyByZWFzb24gdG8gcmVmZXIgdG8gbW9zdCBvZiB0aGUgbWF0ZXJpYWwgKEZlcm5hbmRv J3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSByZWxldmFudCB0byBvcHNlYy4gSSB0aGlu ayB0aGUgcmVmZXJlbmNlIGlzIGRyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmcsDQpi dXQgb25seSBpZiB0aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLg0KDQoiMi4zLjMuICBO RC9SQSBSYXRlIExpbWl0aW5nDQouLi4NCiAgIFRoZSBmb2xsb3dpbmcgZHJhZnRzIGFyZSBhY3Rp dmVseSBkaXNjdXNzaW5nIG1ldGhvZHMgdG8NCiAgIHJhdGUgbGltaXQgUkFzIGFuZCBvdGhlciBO RCBtZXNzYWdlcyBvbiB3aWZpIG5ldHdvcmtzIGluIG9yZGVyIHRvDQogICBhZGRyZXNzIHRoaXMg aXNzdWU6DQoNCiAgIG8gIFtJLUQudGh1YmVydC1zYXZpLXJhLXRocm90dGxlcl0NCg0KICAgbyAg W0ktRC5jaGFrcmFiYXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQoNCk5laXRoZXIg b2YgdGhvc2UgZHJhZnRzIGlzIGluIHRoZSBsZWFzdCBhY3RpdmUgKGZyb20gMjAxMiBhbmQgMjAx NSByZXNwZWN0aXZlbHkpLiBEZWFkIGRyYWZ0cyBhcmUgb2Ygbm8gaGVscCB0byB0aGUgcmVhZGVy LCBJTUhPLg0KDQoiNC4yLiAgVHJhbnNpdGlvbiBNZWNoYW5pc20NCg0KICAgU1Agd2lsbCB0eXBp Y2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBFLCBNQVAsDQog ICBEUy1MaXRlIHdoaWNoIGhhdmUgYmVlbiBhbmFseXplZCBpbiB0aGUgdHJhbnNpdGlvbiBTZWN0 aW9uIDIuNy4yDQogICBzZWN0aW9uLiINCg0KU2hvdWxkbid0IHlvdSBhZGQgUkZDNjg3NyA0NjRY TEFUIG5vdz8NCg0KRmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQcml2YWN5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClJnZHMNCiAgICBCcmlhbg0KDQo+IA0KPiBTZWN0aW9u IDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhlIFNBVkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxs LiAgV2UgDQo+IHNob3VsZCwgaW4gbXkgb3BpbmlvbiwgbWFrZSBpdCBwYWluZnVsbHkgY2xlYXIg dGhhdCBESENQIChvZiBhbnkNCj4gcHJvdG9jb2wpIGluIHRoZSBhYnNlbmNlIG9mIGxpbmstbGF5 ZXIgc2VjdXJpdHkvYXVkaXRhYmlsaXR5IGZlYXR1cmVzIA0KPiBkb2VzIG5vdCBwcm92aWRlIGFu eSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0eSBhbmQgDQo+IHRyYWNlYWJp bGl0eSIgW1NlY3Rpb24gMi4xLjZdLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNFQyBt YWlsaW5nIGxpc3QNCk9QU0VDQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29wc2VjDQo= From nobody Thu Jun 16 02:43:43 2016 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 AB16512B058; Thu, 16 Jun 2016 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-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 QmueOSfHfKhO; Thu, 16 Jun 2016 02:43:40 -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 E21DF12D096; Thu, 16 Jun 2016 02:43:39 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id u64so65747038vkf.3; Thu, 16 Jun 2016 02:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2iI5UQF8KkiTKd/02IhQimbzT+gCNR7EtiEVZkZZ2Zc=; b=xr6uq3d4z0D2HiC4qbNINMWNv9HgUY0O7fAPdnaJN6w81jelvUO20uVWMWUEOtBz6M WBQUUJu35H4x4UTq3gmvNOHNXp7HGgjQT2129EkV4+voCMMsR19UnRx7U7NTj04l7QJr x2fxV+ln9CCZP3dc65uun6PkOCof7u2IxXULKpEApAQ3PVCijQwTMwz5KxouKi85gUzk kmjdmBxG15IIvEnIvWmNOIj5FOz/YczTWA6Qc0RkYyT+8yy0dTn4EE/6SSQ+UGoduMLy p0PDIIyiRu30aSwC86ibwx9S/0RuB7YjzABKKXYJLLV4QxhjH/kQyREwHZqDRckcX84y VsLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2iI5UQF8KkiTKd/02IhQimbzT+gCNR7EtiEVZkZZ2Zc=; b=Nf3RlGxO7tReAWEsQGjDaLcb2jH2agYgRAXMYbVBcFDuAXbLTuuqCeoFCNLW4rW1o5 B3XVo51O+G/+zpmfI4CTJ4rISeppIVro0qamAucapeDOni4gQX6XxHIkJgfqVFlxiIqT PtVXW0rBloR7BWEMs3CYJU5LBcPmShvCYiTYRCEgqaJ2YIFgfcuLMMWwdd1T8KQLh0fL 9OuKz2WH5Ss9/FlAMLSvxy0GGEdyAdI38yuRw8gGI+2+Cn3DALAxEtXWeBe638skuUOj 7/J65xmp//azhpfYhyp3ZPYEoCidFrWfzwOK27NGEeIz4k3fgh/+1+1SMzpKohd/XHuK LklQ== X-Gm-Message-State: ALyK8tJ/CI3P1yweIZOtHcD/pdN12/2WCfeXmpM3a4VK0xLkdl97oPJyAFH7NR+kIkTvu/JIh+CMj3aW8vm1dQ== X-Received: by 10.31.8.77 with SMTP id 74mr1574627vki.150.1466070218954; Thu, 16 Jun 2016 02:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.168 with HTTP; Thu, 16 Jun 2016 02:43:09 -0700 (PDT) In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> From: Mark Smith Date: Thu, 16 Jun 2016 19:43:09 +1000 Message-ID: To: Marco Ermini Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:43:42 -0000 On 16 June 2016 at 19:15, Marco Ermini wrote: > Well, actually, infrastructure hiding IS part of security. It is not the= full picture, but it is incorrect to say that it is not. > > I personally don't sympathize on NAT-haters. NAT has its reasons, especi= ally for carrier-grade NAT CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. Regards, Mark. > > Regards, > > Marco Ermini > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > ResMed Germany Inc > > > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Thursday, June 16, 2016 1:45 AM > To: Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; dra= ft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-0= 8 > > On 16/06/2016 07:45, 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. > > I have strong sympathy with that statement, but I don't think this is the= document to do it; the point is made in RFC4864 too. What we should do her= e is underline that NAT !=3D security. > > While I'm here, some other points: > > "2.2. Extension Headers > > TBD, a short section referring to all Fernando's I-D & RFC." > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance = to security aspects. Second, there is no reason to refer to most of the mat= erial (Fernando's or not) unless it's directly relevant to opsec. I think t= he reference is draft-ietf-opsec-ipv6-eh-filtering, > but only if that document is going anywhere. > > "2.3.3. ND/RA Rate Limiting > ... > The following drafts are actively discussing methods to > rate limit RAs and other ND messages on wifi networks in order to > address this issue: > > o [I-D.thubert-savi-ra-throttler] > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > Neither of those drafts is in the least active (from 2012 and 2015 respec= tively). Dead drafts are of no help to the reader, IMHO. > > "4.2. Transition Mechanism > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > DS-Lite which have been analyzed in the transition Section 2.7.2 > section." > > Shouldn't you add RFC6877 464XLAT now? > > Finally, I think there should be a Privacy Considerations section. > > Rgds > Brian > >> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We >> should, in my opinion, make it painfully clear that DHCP (of any >> protocol) in the absence of link-layer security/auditability features >> does not provide any satisfactory way "to ensure audibility and >> traceability" [Section 2.1.6]. >> >> _______________________________________________ >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 16 03:03:39 2016 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 51CC112D096; Thu, 16 Jun 2016 03:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 I34svSTeb4fn; Thu, 16 Jun 2016 03:03:29 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) by ietfa.amsl.com (Postfix) with ESMTP id 92D0412B05D; Thu, 16 Jun 2016 03:03:28 -0700 (PDT) Received: from [193.109.254.67] by server-11.bemta-14.messagelabs.com id B3/CD-01707-F6972675; Thu, 16 Jun 2016 10:03:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRWlGSWpSXmKPExsVy+JUil25+ZVK 4wdfNIhZPd15hsfiw9S6bxelje5kdmD2WLPnJFMAYxZqZl5RfkcCaMX3dBOaC9U4VWxbvZ2lg PODYxcjFISSwnlHixLKF7BDOHkaJ7asPAzmcHGwCOhL/l+8Csjk4RATUJT72MYLUMAt8YJI40 PiPCaRGWMBLYv/eVmYQW0TAW2Lrjc2MEPVGEps3i4GEWQRUJZ7fvcwMEuYVcJa406ENsWopk8 SaqbvBxnAKBEpc3zKFDcRmFJCV+NK4Gmwks4C4xK0n88FqJAQEJJbsOc8MYYtKvHz8jxXCVpS 4/HsKC8h8ZgFNifW79CFaFSWmdD8E+4RXQFDi5MwnLCC2kICKRPuCZVCtwRL3+t4zTWAUm4Vk 2yyESbOQTJqFZNICRpZVjBrFqUVlqUW6hkZ6SUWZ6RkluYmZObqGhiZ6uanFxYnpqTmJScV6y fm5mxiBccUABDsYz05zPsQoycGkJMrrqJEULsSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mCN6YCKC dYlJqeWpGWmQOMcJi0BAePkghvPkiat7ggMbc4Mx0idYrRkuPO4htrmThuPXsAJD9NOHCMSYg lLz8vVUqcNwqkQQCkIaM0D24cLAldYpSVEuZlBDpQiKcgtSg3swRV/hWjOAejkjBvOsgUnsy8 Eritr4AOYgI6yGZ6PMhBJYkIKakGxirFjxPizq1e0TrdvOqm/oZTSaVfffre3My+skOR9UK50 9ddT6JXhvrxSe4MXv1yzUe/ao3l8/J/X2XeJbkuzPnFjw+L6/2PfnG9pcC6rs7PQsvo37b1G6 VzGNrNVePPHzA7u/GR+SfPzjSOJx/bJPN3ZPJl886sMNGTMLvOuav9WfmZF/frnZRYijMSDbW Yi4oTAZiJ5Io9AwAA X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-5.tower-56.messagelabs.com!1466071406!23003325!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6573 invoked from network); 16 Jun 2016 10:03:27 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-5.tower-56.messagelabs.com with SMTP; 16 Jun 2016 10:03:27 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 12:03:26 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 12:03:26 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx7OSZDWt19w1D06Dzoga8sHTvZ/r20RA Date: Thu, 16 Jun 2016 10:03:25 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 10:03:26.0620 (UTC) FILETIME=[535045C0:01D1C7B6] Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 10:03:33 -0000 SGksDQoNCk5BVCBjYW4gYmUgc3RpbGwgbmVjZXNzYXJ5IGluIElQdjYgaW4gZHVhbC1zdGFjayBz Y2VuYXJpbywgZm9yIGluc3RhbmNlLCB3aGVyZSBldmVyeSBob3N0IGlzIGFzc2lnbmVkIGJvdGgg YSBJUHY0IGFuZCBJUHY2IGFkZHJlc3NlcyBhbmQgdGhlIENHTiBlcXVpcG1lbnQgY2FuJ3QgaGFu ZGxlIHRoZW0gZGlmZmVyZW50bHkuICBVbmZvcnR1bmF0ZWx5IFJGQyA0ODY0IGRvZXMgbm90IG1l bnRpb24gc3VjaCBjYXNlLCBBRkFJSy4NCg0KSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29u Y2VkZSBpdCBjb3VsZCBiZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vz c2FyeSBhbnltb3JlIGluIElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UgY2FzZXMu DQoNCkkgd2FzIG5vdCByZWFsbHkgbWFraW5nIGEgc3BlY2lmaWMgY2FzZSBmb3IgSVB2NiAtIG15 IG9wcG9zaXRpb24gd2FzIHRvIHRoZSBjb25jZXB0IHRoYXQgTkFUIGlzIG5vdCBzZWN1cml0eSwg YW5kIHRvIHRoZSBmYWN0IHRoYXQgaXQgc2hvdWxkIGJlIHdyaXR0ZW4gYXMgc3VjaCBpbiB0aGUg UkZDLiAgTkFUICpkb2VzKiBwcm92aWRlIGEgZm9ybSBvZiBzZWN1cml0eSAtIHRoZSBmYWN0IHRo YXQgaXQgaXMgbm90IGRlc2lyYWJsZSBvciBpdCBpcyB1bm5lY2Vzc2FyeSB0byB1c2UgaXMgYW5v dGhlciB0b3BpYywgaW4gd2hpY2ggSSBiZWxpZXZlIHdlIGFsbCBhZ3JlZSAoYXQgbGVhc3QgZm9y IDk5JSBvZiB1c2UgY2FzZXMgOy0pKQ0KDQoNClJlZ2FyZHMsDQrigIvigIvigIvigIvigIsNCk1h cmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRA0KU2Vu aW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1MjMgwqBNwqArNDkg KDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21h aWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDExOjQzIEFNDQpUbzogTWFy Y28gRXJtaW5pDQpDYzogQnJpYW4gRSBDYXJwZW50ZXI7IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tl IChldnluY2tlKTsgZmdvbnRAc2k2bmV0d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgdjZvcHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmll dyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTA4DQoNCk9uIDE2IEp1bmUgMjAxNiBhdCAxOToxNSwg TWFyY28gRXJtaW5pIDxNYXJjby5Fcm1pbmlAcmVzbWVkLmNvbT4gd3JvdGU6DQo+IFdlbGwsIGFj dHVhbGx5LCBpbmZyYXN0cnVjdHVyZSBoaWRpbmcgSVMgcGFydCBvZiBzZWN1cml0eS4gIEl0IGlz IG5vdCB0aGUgZnVsbCBwaWN0dXJlLCBidXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSB0aGF0IGl0 IGlzIG5vdC4NCj4NCj4gSSBwZXJzb25hbGx5IGRvbid0IHN5bXBhdGhpemUgb24gTkFULWhhdGVy cy4gIE5BVCBoYXMgaXRzIHJlYXNvbnMsIA0KPiBlc3BlY2lhbGx5IGZvciBjYXJyaWVyLWdyYWRl IE5BVA0KDQpDR04gaXNuJ3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHBy b2JsZW0gb2YgSVNQcyBydW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy4NCg0KIGFuZCBlc3Bl Y2lhbGx5IGluIHRoZSB0ZWxjbyBzY2VuYXJpbywgYW5kIHllcywgaXQgZG9lcyBwcm92aWRlIHNv bWUgbGV2ZWwgb2Ygc2VjdXJpdHkgLSBhZ2Fpbiwgbm90IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCBi dXQgaXQgZG9lcy4NCj4NCg0KTkFUIGlzIG5vdCBuZWNlc3NhcnkgaW4gSVB2Ni4gVGhlIGVxdWl2 YWxlbnQgb2YgTkFUJ3MgcGVyY2VpdmVkIHNlY3VyaXR5IGNhbiBiZSBwcm92aWRlZCB2aWEgYWx0 ZXJuYXRpdmUgbWV0aG9kcywgYXMgZGVzY3JpYmVkIGluIFJGQzQ4NjQuDQoNCkEgZnVydGhlciB0 ZWNobmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0 IGlzIHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEg c2luZ2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4g RXh0ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJ UHY2IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCg0KSWYgeW91IHRydWx5 IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNuJ3QgZG8gZW5v dWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFzIHRoZXJlIGFy ZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNlbGYgc3VwcGxp ZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkgaG9zdHMgZS5n LiBIVFRQIGNvb2tpZXMuICJBIFRlY2huaXF1ZSBmb3IgQ291bnRpbmcgTkFUdGVkIEhvc3RzIg0K KGh0dHBzOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+c21iL3BhcGVycy9mbmF0LnBkZikgc2hvd2Vk IGhvdyBhIGZpZWxkIHdpdGhpbiB0aGUgSVB2NCBoZWFkZXIgdGhhdCBsZWFrZWQgYWNyb3NzIGEg TkFUIHdhcyBhYmxlIHRvIGJlIHVzZWQgdG8gaWRlbnRpZnkgaG9zdHMuDQoNCklmIHlvdSB0cnVs eSB3YW50IHRvIGhpZGUgYSBob3N0IGZyb20gdGhlIEludGVybmV0LCB5ZXQgc3RpbGwgYWxsb3cg aXQgdG8gYWNjZXNzIHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQsIHVuZGVyIElQdjYgeW91ciBuZXR3 b3JrIHdvdWxkIHVzZSBVTEEgYWRkcmVzc2luZywgYW5kIGhhdmUgYSBwZXItYXBwbGljYXRpb24g cHJvdG9jb2wgcHJveHkgc2VydmVyIHRoYXQgbWFrZXMgYWxsIHJlcXVlc3RzIGxvb2sgbGlrZSB0 aGV5J3ZlIGVudGlyZWx5IG9yaWdpbmF0ZWQgZnJvbSB0aGUgYXBwbGljYXRpb24gcHJveHkgc2Vy dmVyIGl0c2VsZi4gVG8gdGhlIEludGVybmV0IHNlcnZlciwgdGhlIGFwcGxpY2F0aW9uIHByb3h5 IHNlcnZlciB3b3VsZCBhcHBlYXIgdG8gYmUgdGhlIGFwcGxpY2F0aW9uIGVuZCBob3N0IG1ha2lu ZyB0aGUgcmVxdWVzdHMsIHByZXZlbnRpbmcgYW55IGludGVybmFsIGhvc3QgaWRlbnRpZmllcnMg b3Igb3RoZXIgYXR0cmlidXRlcyBmcm9tIGxlYWtpbmcuDQoNCg0KUmVnYXJkcywNCk1hcmsuDQoN Cg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBNYXJjbyBFcm1pbmkNCj4NCj4gQ0lTU1AsIENJU0EsIENJ U00sIENFSCwgSVRJTCwgTUNQLCBQaEQgU2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QgRCANCj4g KzQ5ICgwKTg5OSA5MDEgMTUyMyAgTSArNDkgKDApMTc1IDQzOSA1NjQyDQo+DQo+IFJlc01lZCBH ZXJtYW55IEluYw0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBP UFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBF IA0KPiBDYXJwZW50ZXINCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMTo0NSBBTQ0K PiBUbzogRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQo+IENjOiBmZ29udEBzaTZu ZXR3b3Jrcy5jb207IG9wc2VjQGlldGYub3JnOyBsaW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlOyAN Cj4gZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtPUFNFQ10gW3Y2b3BzXSBBc2tpbmcgZm9yIGEgcmV2aWV3IG9mIA0KPiBkcmFmdC1p ZXRmLW9wc2VjLXY2LTA4DQo+DQo+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3Jv dGU6DQo+PiBTZWN0aW9uIDIuMS4yIGlzIGZhciB0b28gcGVybWlzc2l2ZSBmb3IgbXkgdGFzdGVz LiAgV2UgbmVlZCB0byBiZSANCj4+IGFibGUgdG8gc2F5IHRoYXQgVUxBK0lQdjYgTkFUIGlzIE5P VCBSRUNPTU1FTkRFRCBieSB0aGUgSUVURi4NCj4NCj4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3 aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVu dCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUgaW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hv dWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQgTkFUICE9IHNlY3VyaXR5Lg0KPg0KPiBXaGls ZSBJJ20gaGVyZSwgc29tZSBvdGhlciBwb2ludHM6DQo+DQo+ICIyLjIuICBFeHRlbnNpb24gSGVh ZGVycw0KPg0KPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5h bmRvJ3MgSS1EICYgUkZDLiINCj4NCj4gVGhhdCdzIG5vdCB0aGUgd2hvbGUgc3RvcnkgOy0pLiBG aXJzdGx5LCBSRkMgNzA0NSBoYXMgYSBsb3Qgb2YgDQo+IHJlbGV2YW5jZSB0byBzZWN1cml0eSBh c3BlY3RzLiBTZWNvbmQsIHRoZXJlIGlzIG5vIHJlYXNvbiB0byByZWZlciB0byANCj4gbW9zdCBv ZiB0aGUgbWF0ZXJpYWwgKEZlcm5hbmRvJ3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSBy ZWxldmFudCANCj4gdG8gb3BzZWMuIEkgdGhpbmsgdGhlIHJlZmVyZW5jZSBpcyBkcmFmdC1pZXRm LW9wc2VjLWlwdjYtZWgtZmlsdGVyaW5nLA0KPiBidXQgb25seSBpZiB0aGF0IGRvY3VtZW50IGlz IGdvaW5nIGFueXdoZXJlLg0KPg0KPiAiMi4zLjMuICBORC9SQSBSYXRlIExpbWl0aW5nDQo+IC4u Lg0KPiAgICBUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgYWN0aXZlbHkgZGlzY3Vzc2luZyBtZXRo b2RzIHRvDQo+ICAgIHJhdGUgbGltaXQgUkFzIGFuZCBvdGhlciBORCBtZXNzYWdlcyBvbiB3aWZp IG5ldHdvcmtzIGluIG9yZGVyIHRvDQo+ICAgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4NCj4gICAg byAgW0ktRC50aHViZXJ0LXNhdmktcmEtdGhyb3R0bGVyXQ0KPg0KPiAgICBvICBbSS1ELmNoYWty YWJhcnRpLW5vcmRtYXJrLTZtYW4tZWZmaWNpZW50LW5kXSINCj4NCj4gTmVpdGhlciBvZiB0aG9z ZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAyMDE1IHJlc3Bl Y3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFkZXIsIElNSE8u DQo+DQo+ICI0LjIuICBUcmFuc2l0aW9uIE1lY2hhbmlzbQ0KPg0KPiAgICBTUCB3aWxsIHR5cGlj YWxseSB1c2UgdHJhbnNpdGlvbiBtZWNoYW5pc21zIHN1Y2ggYXMgNnJkLCA2UEUsIE1BUCwNCj4g ICAgRFMtTGl0ZSB3aGljaCBoYXZlIGJlZW4gYW5hbHl6ZWQgaW4gdGhlIHRyYW5zaXRpb24gU2Vj dGlvbiAyLjcuMg0KPiAgICBzZWN0aW9uLiINCj4NCj4gU2hvdWxkbid0IHlvdSBhZGQgUkZDNjg3 NyA0NjRYTEFUIG5vdz8NCj4NCj4gRmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQ cml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+DQo+IFJnZHMNCj4gICAgIEJyaWFuDQo+ DQo+Pg0KPj4gU2VjdGlvbiAyLjYuMS41IGNvdWxkIHB1bmNoIHVwIHRoZSBTQVZJIHN0dWZmIGEg Yml0IG1vcmUgYXMgd2VsbC4gIFdlIA0KPj4gc2hvdWxkLCBpbiBteSBvcGluaW9uLCBtYWtlIGl0 IHBhaW5mdWxseSBjbGVhciB0aGF0IERIQ1AgKG9mIGFueQ0KPj4gcHJvdG9jb2wpIGluIHRoZSBh YnNlbmNlIG9mIGxpbmstbGF5ZXIgc2VjdXJpdHkvYXVkaXRhYmlsaXR5IGZlYXR1cmVzIA0KPj4g ZG9lcyBub3QgcHJvdmlkZSBhbnkgc2F0aXNmYWN0b3J5IHdheSAidG8gZW5zdXJlIGF1ZGliaWxp dHkgYW5kIA0KPj4gdHJhY2VhYmlsaXR5IiBbU2VjdGlvbiAyLjEuNl0uDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1haWxp bmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE9QU0VDIG1haWxpbmcgbGlzdA0KPiBPUFNFQ0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jun 16 05:17:18 2016 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 1C10112D548; Thu, 16 Jun 2016 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d_DqhM6zb_k; Thu, 16 Jun 2016 05:17:15 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 B97A312D531; Thu, 16 Jun 2016 05:17:14 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so70462874vka.1; Thu, 16 Jun 2016 05:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xZS+hGdxvpzHlQnPCCLqNskU6BuvGXtijoyNDQ0+L88=; b=boQ9IHQ5JFCMSHczZUqmGXQCmIjGd8fk5Y3JyU/6aBM/tQ0CAcl99O5T/P4OjHxX05 WzBSctO7o9LV/suP/f64QnoBRuyMof7QJwQuEtiW0d+eMYYC4VBPZBn60NwCY9VAZZxC Hm4ouDxTmHoZZ6+d969E7pI9vr1srEx9PbSKh4TNt3v1RjplZNtMcfmNltN3JBOY1XN9 IIaIolunaNCqJ0O/wUFWXch/VSWeus+IlCkSKeCMXSMHDc4uSz2AXqRKPsvfDd8ExO9W a32u4YTZSXaRD5scRHWhc3r2suBVw7tLzwxVYZgE0rx8AUURzk734y87XM7xfzpVWuXM GOtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xZS+hGdxvpzHlQnPCCLqNskU6BuvGXtijoyNDQ0+L88=; b=ha1e5b3y+gLwlsYMCHhYFE+uU020yfuoIYu74Pc9h06EJ6AGqMRxqQIyJUJxyIqPgn 8QVYVUikTPbsTqZq5YdHfFIJMeWB1yOJTff6RmEdtpe7g+ADbvwT2Gpu1zo2Xplg697k 0KuDRiT7+la4AZLIe+BDGxi1z4lrcwH+chZH9WXjnrMOJpCzFJlWeKEStKWS4a0TyxcH WK3TbFJdlNhLOq92KHqj1HQArU5Ut6LiYgtpQig3vc8B//RiiU2Y0Om3mY3wTI+Utxj9 7mK6xFk+iSPERt43l3zysAw2A3cdYALsTtQii1kB9Q2Y9W3F7SSreXoiztmdacok+iiA P1Kw== X-Gm-Message-State: ALyK8tKCU2DY2ywN6k2m2EDfNvWeW+RjPYRFD/V3+SVJ9+7xd3C6YmIFv7XnJ0fPRoXxavQjFoS/1CIZZy77lQ== MIME-Version: 1.0 X-Received: by 10.176.69.141 with SMTP id u13mr2029550uau.133.1466079433559; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) In-Reply-To: References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> Date: Thu, 16 Jun 2016 22:17:13 +1000 Message-ID: From: Mark Smith To: Marco Ermini Content-Type: multipart/alternative; boundary=94eb2c0cbf7ad9947e0535643725 Archived-At: Cc: "v6ops@ietf.org" , draft-ietf-opsec-v6@ietf.org, "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:17:17 -0000 --94eb2c0cbf7ad9947e0535643725 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 Jun 2016 20:03, "Marco Ermini" wrote: > > Hi, > > NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently. Can you provide an example of this sort of CGN device. IPv4 and IPv6 have to be handled differently because they're different protocols, requiring different code. A single device might be performing NAT on IPv4 traffic it receives and doing standard stateless forwarding of IPv6 traffic. Is that the scenario you're describing? I'd struggle to believe that there are CGN devices where performing NAT on IPv6 traffic is mandatory if IPv4 NAT is being performed. Unfortunately RFC 4864 does not mention such case, AFAIK. > > In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use cases. > > I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be written as such in the RFC. So this draft is purely about IPv6. There will be a lot of IPv4 security measures that can be applied to IPv6, however there will also be others that shouldn't, and opportunities where IPv6 can provide better security that IPv4 (e.g. sparse host addressing in a /64 makes address probing to discover hosts impossible within a useful and practical timeframe.). > NAT *does* provide a form of security What specific security does it provide that is due to the address translation function? If you're thinking about the protection provided due to the state being created during the address translation process, that state can be created without performing address translation, which is what a stateful firewall does and did in IPv4 before NAT became widely deployed. > - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-)) > I don't see a need to deploy NAT with IPv6 as what has been achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT. Regards, Mark. > > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > ResMed Germany Inc > > > > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com] > Sent: Thursday, June 16, 2016 11:43 AM > To: Marco Ermini > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-0= 8 > > On 16 June 2016 at 19:15, Marco Ermini wrote: > > Well, actually, infrastructure hiding IS part of security. It is not the full picture, but it is incorrect to say that it is not. > > > > I personally don't sympathize on NAT-haters. NAT has its reasons, > > especially for carrier-grade NAT > > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. > > and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > > > > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. > > A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. > > If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. > > If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. > > > Regards, > Mark. > > > > > > Regards, > > > > Marco Ermini > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D > > +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > ResMed Germany Inc > > > > > > -----Original Message----- > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: Thursday, June 16, 2016 1:45 AM > > To: Erik Kline; Eric Vyncke (evyncke) > > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; > > draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > > Subject: Re: [OPSEC] [v6ops] Asking for a review of > > draft-ietf-opsec-v6-08 > > > > On 16/06/2016 07:45, 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. > > > > I have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT !=3D security. > > > > While I'm here, some other points: > > > > "2.2. Extension Headers > > > > TBD, a short section referring to all Fernando's I-D & RFC." > > > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of > > relevance to security aspects. Second, there is no reason to refer to > > most of the material (Fernando's or not) unless it's directly relevant > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering, > > but only if that document is going anywhere. > > > > "2.3.3. ND/RA Rate Limiting > > ... > > The following drafts are actively discussing methods to > > rate limit RAs and other ND messages on wifi networks in order to > > address this issue: > > > > o [I-D.thubert-savi-ra-throttler] > > > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > > > Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. > > > > "4.2. Transition Mechanism > > > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > > DS-Lite which have been analyzed in the transition Section 2.7.2 > > section." > > > > Shouldn't you add RFC6877 464XLAT now? > > > > Finally, I think there should be a Privacy Considerations section. > > > > Rgds > > Brian > > > >> > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > >> should, in my opinion, make it painfully clear that DHCP (of any > >> protocol) in the absence of link-layer security/auditability features > >> does not provide any satisfactory way "to ensure audibility and > >> traceability" [Section 2.1.6]. > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --94eb2c0cbf7ad9947e0535643725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Jun 2016 20:03, "Marco Ermini" <Marco.Ermini@resmed.com> wrote:
>
> Hi,
>
> NAT can be still necessary in IPv6 in dual-stack scenario, for instanc= e, where every host is assigned both a IPv4 and IPv6 addresses and the CGN = equipment can't handle them differently.=C2=A0

Can you provide an example of this sort of CGN device.

IPv4 and IPv6 have to be handled differently because they= 9;re different protocols, requiring different code. A single device might b= e performing NAT on IPv4 traffic it receives and doing standard stateless f= orwarding of IPv6 traffic. Is that the scenario you're describing?

I'd struggle to believe that there are CGN devices where= performing NAT on IPv6 traffic is mandatory if IPv4 NAT is being performed= .

Unfortunately RFC 4864 does not mention such case, AFAIK. >
> In any case, I am happy to concede it could be an extreme case and tha= t it is not necessary anymore in IPv6 for the great majority of use cases.<= br> >
> I was not really making a specific case for IPv6 - my opposition was t= o the concept that NAT is not security, and to the fact that it should be w= ritten as such in the RFC.

So this draft is purely about IPv6. There will be a lot of I= Pv4 security measures that can be applied to IPv6, however there will also = be others that shouldn't, and opportunities where IPv6 can provide bett= er security that IPv4 (e.g. sparse host addressing in a /64 makes address p= robing to discover hosts impossible within a useful and practical timeframe= .).

=C2=A0> NAT *does* provide a form of security

What specific security does it provide that is due to the ad= dress translation function?

If you're thinking about the protection provided due to = the state being created during the address translation process, that state = can be created without performing address translation, which is what a stat= eful firewall does and did in IPv4 before NAT became widely deployed.

> - the fact that it is not desirable or it is unnecessar= y to use is another topic, in which I believe we all agree (at least for 99= % of use cases ;-))
>

I don't see a need to deploy NAT with IPv6 as what has b= een achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of= NAT.

Regards,
Mark.

>
> Regards,
> =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B
> Marco Ermini
>
> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> Senior IT Security Analyst
> D=C2=A0+49 (0)899 901 1523 =C2=A0M=C2=A0+49 (0)175 439 5642
>
> ResMed Germany Inc
>
>
>
> -----Original Message-----
> From: Mark Smith [mailto:mar= kzzzsmith@gmail.com]
> Sent: Thursday, June 16, 2016 11:43 AM
> To: Marco Ermini
> Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org
> Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v= 6-08
>
> On 16 June 2016 at 19:15, Marco Ermini <Marco.Ermini@resmed.com> wrote:
> > Well, actually, infrastructure hiding IS part of security.=C2=A0 = It is not the full picture, but it is incorrect to say that it is not.
> >
> > I personally don't sympathize on NAT-haters.=C2=A0 NAT has it= s reasons,
> > especially for carrier-grade NAT
>
> CGN isn't necessary in IPv6, it's to solve the problem of ISPs= running out of IPv4 addresses.
>
> =C2=A0and especially in the telco scenario, and yes, it does provide s= ome level of security - again, not the complete picture, but it does.
> >
>
> NAT is not necessary in IPv6. The equivalent of NAT's perceived se= curity can be provided via alternative methods, as described in RFC4864. >
> A further technique to hide topology that isn't mentioned in RFC48= 64 is to use something like ISATAP or similar, to create a single /64 subne= t over the top of multiple IPv4 subnets. Externally, all hosts will appear = to belong to a single IPv6 subnet, hiding the internal topology.
>
> If you truly want to hide the identities of hosts, NAT doesn't do = enough - it is only translating addresses, where as there are many other ho= st identifiers that the host itself supplies or will receive and supply tha= t can identify hosts e.g. HTTP cookies. "A Technique for Counting NATt= ed Hosts"
> (https://= www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the= IPv4 header that leaked across a NAT was able to be used to identify hosts= .
>
> If you truly want to hide a host from the Internet, yet still allow it= to access things on the Internet, under IPv6 your network would use ULA ad= dressing, and have a per-application protocol proxy server that makes all r= equests look like they've entirely originated from the application prox= y server itself. To the Internet server, the application proxy server would= appear to be the application end host making the requests, preventing any = internal host identifiers or other attributes from leaking.
>
>
> Regards,
> Mark.
>
>
> >
> > Regards,
> >
> > Marco Ermini
> >
> > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst= D
> > +49 (0)899 901 1523=C2=A0 M +49 (0)175 439 5642
> >
> > ResMed Germany Inc
> >
> >
> > -----Original Message-----
> > From: OPSEC [mailto:ops= ec-bounces@ietf.org] On Behalf Of Brian E
> > Carpenter
> > Sent: Thursday, June 16, 2016 1:45 AM
> > To: Erik Kline; Eric Vyncke (evyncke)
> > Cc: fgont@si6networks.co= m; opsec@ietf.org; linkedin@xn--debrn-nva.de;
> > draft-ietf-opsec-= v6@ietf.org; v6ops@ietf.org
> > Subject: Re: [OPSEC] [v6ops] Asking for a review of
> > draft-ietf-opsec-v6-08
> >
> > On 16/06/2016 07:45, Erik Kline wrote:
> >> Section 2.1.2 is far too permissive for my tastes.=C2=A0 We n= eed to be
> >> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.=
> >
> > I have strong sympathy with that statement, but I don't think= this is the document to do it; the point is made in RFC4864 too. What we s= hould do here is underline that NAT !=3D security.
> >
> > While I'm here, some other points:
> >
> > "2.2.=C2=A0 Extension Headers
> >
> >=C2=A0 =C2=A0 TBD, a short section referring to all Fernando's= I-D & RFC."
> >
> > That's not the whole story ;-). Firstly, RFC 7045 has a lot o= f
> > relevance to security aspects. Second, there is no reason to refe= r to
> > most of the material (Fernando's or not) unless it's dire= ctly relevant
> > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filte= ring,
> > but only if that document is going anywhere.
> >
> > "2.3.3.=C2=A0 ND/RA Rate Limiting
> > ...
> >=C2=A0 =C2=A0 The following drafts are actively discussing methods= to
> >=C2=A0 =C2=A0 rate limit RAs and other ND messages on wifi network= s in order to
> >=C2=A0 =C2=A0 address this issue:
> >
> >=C2=A0 =C2=A0 o=C2=A0 [I-D.thubert-savi-ra-throttler]
> >
> >=C2=A0 =C2=A0 o=C2=A0 [I-D.chakrabarti-nordmark-6man-efficient-nd]= "
> >
> > Neither of those drafts is in the least active (from 2012 and 201= 5 respectively). Dead drafts are of no help to the reader, IMHO.
> >
> > "4.2.=C2=A0 Transition Mechanism
> >
> >=C2=A0 =C2=A0 SP will typically use transition mechanisms such as = 6rd, 6PE, MAP,
> >=C2=A0 =C2=A0 DS-Lite which have been analyzed in the transition S= ection 2.7.2
> >=C2=A0 =C2=A0 section."
> >
> > Shouldn't you add RFC6877 464XLAT now?
> >
> > Finally, I think there should be a Privacy Considerations section= .
> >
> > Rgds
> >=C2=A0 =C2=A0 =C2=A0Brian
> >
> >>
> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as w= ell.=C2=A0 We
> >> should, in my opinion, make it painfully clear that DHCP (of = any
> >> protocol) in the absence of link-layer security/auditability = features
> >> does not provide any satisfactory way "to ensure audibil= ity and
> >> traceability" [Section 2.1.6].
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> > _______________________________________________
> > OPSEC mailing list
> > OPSEC@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/opsec
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops

--94eb2c0cbf7ad9947e0535643725-- From nobody Thu Jun 16 07:15:15 2016 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 3882312D6B5; Thu, 16 Jun 2016 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 gZ3dnzQbHZdg; Thu, 16 Jun 2016 07:15:09 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.249]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8D12D6AE; Thu, 16 Jun 2016 07:15:08 -0700 (PDT) Received: from [85.158.143.99] by server-2.bemta-6.messagelabs.com id 0D/E1-11548-B64B2675; Thu, 16 Jun 2016 14:15:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRWlGSWpSXmKPExsVy+JUil272lqR wg+/3xSye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y/GsLpaCF6UVc/qOsDQw LinpYuTiEBJYzyixb0oTG4Szh1Hi2MOT7F2MnBxsAjoS/5fvArI5OEQE1CU+9jGChJkFPjFJ3 J6SCGILC3hJ7N/bygxiiwh4S2y9sZkRotxI4t82HZAwi4CqxJf7O8Am8go4S6y89I4VYtUrZo ln06aygSQ4BQIlls6cyARiMwrISnxpXM0MsUtc4taT+WBxCQEBiSV7zjND2KISLx//Y4WwFSR WXJrABLKXWUBTYv0ufYhWRYkp3Q+h9gpKnJz5hAXEFhJQkWhfsAyqNVhi4aJdzBMYxWYh2TYL YdIsJJNmIZm0gJFlFaN6cWpRWWqRrrFeUlFmekZJbmJmjq6hgZlebmpxcWJ6ak5iUrFecn7uJ kZgVDEAwQ7Gjn9OhxglOZiURHnr65PChfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwPtoElBMsSk 1PrUjLzAHGN0xagoNHSYT3FUiat7ggMbc4Mx0idYrRkuPO4htrmThuPXsAJD9NOHCMSYglLz8 vVUqc9wlIgwBIQ0ZpHtw4WAq6xCgrJczLCHSgEE9BalFuZgmq/CtGcQ5GJWGIKTyZeSVwW18B HcQEdJDN9HiQg0oSEVJSDYzpETeT95x4fqOw8ey5P261K3fnHYh05Hdc3J2iV1TRduiymd1eL seXWSyi4da6MvOMzvkta23jclGb1a2RIOSxb8c6U365yCk7r3PV+Yqv8Qu/vGXWofsl7f+/Na x2W3DTYvu7M/Ku0Z7+fy9dP8zgwZWvtiTgYKHGzQN/s8Rf7U/aP/Wr4WwlluKMREMt5qLiRAB 2lIoPPAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1466086507!11202740!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7009 invoked from network); 16 Jun 2016 14:15:07 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-8.tower-216.messagelabs.com with SMTP; 16 Jun 2016 14:15:07 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 16:15:06 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 16:15:06 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx8kDZDWt19w1D06Dzoga8sHTvZ/sGD1g Date: Thu, 16 Jun 2016 14:15:05 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.15.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 14:15:06.0985 (UTC) FILETIME=[7BD51D90:01D1C7D9] Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:15:14 -0000 SSdsbCB0cnkgdGhlIGhvcnJpYmxlIE91dGxvb2sgdG8gcmVwbHkgdXNpbmcgdGV4dCwgcGxlYXNl IGJlZyBteSBwYXJkb24gaWYgdGhpcyBpcyBub3QgZm9ybWF0dGVkIHByb3Blcmx5Lg0KDQpPbiBU aHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBNLCBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6 enNtaXRoQGdtYWlsLmNvbV0gd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBOQVQgY2FuIGJlIHN0aWxs IG5lY2Vzc2FyeSBpbiBJUHY2IGluIGR1YWwtc3RhY2sgc2NlbmFyaW8sIGZvciBpbnN0YW5jZSwg d2hlcmUgZXZlcnkgaG9zdCBpcyBhc3NpZ25lZCBib3RoIGEgSVB2NCBhbmQgSVB2NiBhZGRyZXNz ZXMgYW5kIHRoZQ0KPj4gQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUgdGhlbSBkaWZmZXJlbnRs eS7CoA0KPkNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2 aWNlLg0KDQpJIHdvdWxkIHByZWZlciBub3QgdG8gbWFrZSBuYW1lcywgYnV0IHlvdSB3b3VsZCBi ZSB1bnBsZWFzYW50bHkgc3VycHJpc2VkLiAgQW55d2F5LCBpdCBpcyBhbHNvIG5vdCBqdXN0IGEg bWF0dGVyIG9mIG5vdCBiZWluZyBhYmxlIHRvIGNvbmZpZ3VyZSB0aGVtIGluIGEgY2VydGFpbiB3 YXkgKHdoaWNoIGlzIHBvc3NpYmx5IHRoZSBjYXNlKSwgYnV0IGFsc28gdGhlIGNhc2UgaW4gd2hp Y2ggdGhleSBkb24ndCB3b3JrIHByb3Blcmx5Lg0KDQo+IElQdjQgYW5kIElQdjYgaGF2ZSB0byBi ZSBoYW5kbGVkIGRpZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xz LCByZXF1aXJpbmcgZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZQ0KPiBw ZXJmb3JtaW5nIE5BVCBvbiBJUHY0IHRyYWZmaWMgaXQgcmVjZWl2ZXMgYW5kIGRvaW5nIHN0YW5k YXJkIHN0YXRlbGVzcyBmb3J3YXJkaW5nIG9mIElQdjYgdHJhZmZpYy4gSXMgdGhhdCB0aGUgc2Nl bmFyaW8geW91J3JlIGRlc2NyaWJpbmc/DQoNClllcywgZm9yIGluc3RhbmNlLiAgT3IsIHRoZXkg aGFuZGxlIGNlcnRhaW4gZnVuY3Rpb25zIChlLmcuIE5BVCkgcHVyZWx5IGluIHRoZSBkYXRhIHBs YW5lIGFzIHRoZXkgYXJlIGxvZ2ljYWxseSBzaW1wbGUgdG8gYmUgaW1wbGVtZW50ZWQgaW4gZmly bXdhcmUsIHdoaWxlIG1vcmUgY29tcGxleCBmdW5jdGlvbnMgKGxpa2UgaW1wbGVtZW50aW5nIFVM QSBhZGRyZXNzZXMgdHJhbnNsYXRpb24pIHJlcXVpcmVzIHJvdXRpbmUgZW5naW5lcyB0byBiZSBp bnZvbHZlZCwgdGhlcmVmb3JlIGludm9sdmluZyBkaWZmZXJlbnQgbGF0ZW5jeSBmb3IgZXhlY3V0 aW9uLg0KDQpJdCBpcyBwcmV0dHkgY29tbW9uIHRoYXQgY3VzdG9tZXJzIHdpdGggSVNQcyBvZmZl cmluZyBkdWFsIHN0YWNrLCB0byBleHBlcmllbmNlIGEgaGlnaGVyIGxhdGVuY3kgZm9yIHRoZWly IGNvbm5lY3Rpb24gb25jZSB0aGV5IGltcGxlbWVudCBJUHY2IGFsb25nIHdpdGggSVB2NC4gICBU aGlzIGRvZXMgbm90IGFwcGx5IHdoZW4gb25seSBJUHY0IG9yIG9ubHkgSVB2NiBhcmUgdXNlZC4N Cg0KQW5vdGhlciByZXF1aXJlbWVudCBpcyB0aGF0IGEgc3BlY2lmaWMgbG9nZ2luZyBvciBtb25p dG9yaW5nIHN5c3RlbSBpcyBpbXBsZW1lbnRlZCAoZXNwZWNpYWxseSBmb3IgbGVnYWwgcmVxdWly ZW1lbnRzKSwgYW5kIHRoaXMgaXMgZG9uZSB0aHJvdWdoIGxvZ2dpbmcgTkFUIHRyYW5zbGF0aW9u cy4gIEFuIElTUCBpbXBsZW1lbnRpbmcgSVB2NiBhbG9uZyB3aXRoIElQdjQgd291bGQgYmUgaW4g dGhhdCBzaXR1YXRpb24uDQoNCkx1Y2tpbHksIHJvdXRlciB2ZW5kb3JzIGFyZSBtb3ZpbmcgYXdh eSBmcm9tIHRoZSBhbnRpcXVhdGUgYXJjaGl0ZWN0dXJlIHdoaWNoIHNlcGFyYXRlcyBkYXRhIGFu ZCBtYW5hZ2VtZW50IHBsYW5lLCBmb3IgdmFyaW91cyByZWFzb25zLg0KDQpUaGlzIGlzIGFsc28g d2h5IHdlIHB1Ymxpc2hlZCBkcmFmdC1nb250LW9wc2VjLWlwdjYtZmlyZXdhbGwtcmVxcy0wMy50 eHQsIHRvIG1ha2UgaXQgZXhwbGljaXQgdGhhdCB0aGlzIHNob3VsZCBub3QgaGFwcGVuLg0KDQoo SSBhbSBhd2FyZSB0aGlzIGlzIG9mZi10b3BpYywganVzdCBtYWtpbmcgbXkgcG9pbnQgOi0pKQ0K DQo+PlVuZm9ydHVuYXRlbHkgUkZDIDQ4NjQgZG9lcyBub3QgbWVudGlvbiBzdWNoIGNhc2UsIEFG QUlLLg0KPj4NCj4gSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29uY2VkZSBpdCBjb3VsZCBi ZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSBhbnltb3JlIGlu IElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UNCj4gY2FzZXMuDQoNCk9rYXkNCg0K Pj4gSSB3YXMgbm90IHJlYWxseSBtYWtpbmcgYSBzcGVjaWZpYyBjYXNlIGZvciBJUHY2IC0gbXkg b3Bwb3NpdGlvbiB3YXMgdG8gdGhlIGNvbmNlcHQgdGhhdCBOQVQgaXMgbm90IHNlY3VyaXR5LCBh bmQgdG8gdGhlIGZhY3QgdGhhdCBpdCBzaG91bGQgYmUNCj4+IHdyaXR0ZW4gYXMgc3VjaCBpbiB0 aGUgUkZDLg0KPiBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91dCBJUHY2LiBUaGVyZSB3aWxs IGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhhdCBjYW4gYmUgYXBwbGllZCB0 byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhlcnMNCj4gdGhhdCBzaG91bGRu J3QsIGFuZCBvcHBvcnR1bml0aWVzIHdoZXJlIElQdjYgY2FuIHByb3ZpZGUgYmV0dGVyIHNlY3Vy aXR5IHRoYXQgSVB2NCAoZS5nLiBzcGFyc2UgaG9zdCBhZGRyZXNzaW5nIGluIGEgLzY0IG1ha2Vz IGFkZHJlc3MgcHJvYmluZw0KPiB0byBkaXNjb3ZlciBob3N0cyBpbXBvc3NpYmxlIHdpdGhpbiBh IHVzZWZ1bCBhbmQgcHJhY3RpY2FsIHRpbWVmcmFtZS4pLg0KDQpPa2F5LCBJIGhhdmUgbm90aGlu ZyB0byBvYmplY3Qgb24gdGhpcy4NCg0KDQo+PiBOQVQgKmRvZXMqIHByb3ZpZGUgYSBmb3JtIG9m IHNlY3VyaXR5DQo+V2hhdCBzcGVjaWZpYyBzZWN1cml0eSBkb2VzIGl0IHByb3ZpZGUgdGhhdCBp cyBkdWUgdG8gdGhlIGFkZHJlc3MgdHJhbnNsYXRpb24gZnVuY3Rpb24/DQo+IElmIHlvdSdyZSB0 aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlvbiBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJl aW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRyZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQg c3RhdGUgY2FuIGJlDQo+IGNyZWF0ZWQgd2l0aG91dCBwZXJmb3JtaW5nIGFkZHJlc3MgdHJhbnNs YXRpb24sIHdoaWNoIGlzIHdoYXQgYSBzdGF0ZWZ1bCBmaXJld2FsbCBkb2VzIGFuZCBkaWQgaW4g SVB2NCBiZWZvcmUgTkFUIGJlY2FtZSB3aWRlbHkgZGVwbG95ZWQuDQoNCkkgdG90YWxseSBhZ3Jl ZSB3aXRoIHlvdS4gIEkgYW0gYWN0dWFsbHkgcmVmZXJyaW5nIHRvIHRoZSBwb3NzaWJpbGl0eSB0 byBoaWRlIHRoZSBzeXN0ZW1zIGJlaGluZCB0aGUgTkFUdGVkIGludGVyZmFjZXMgb2YgdGhlIHJv dXRlci9maXJld2FsbCwgbm90IGp1c3QgdGhlaXIgYWRkcmVzc2VzIGJ1dCBhbHNvIHBvcnRzIGFu ZCBzZXJ2aWNlcy4gIElmIHlvdSBvbmx5IGFwcGx5IGZpbHRlcmluZywgeW91IGFyZSBwcm90ZWN0 aW5nIC0gYnV0IG5vdCBoaWRpbmcuDQoNCkluIGEgcGVyZmVjdCB3b3JsZCwgeW91IGhhdmUgc3Vj aCBnb29kIGZpbHRlcnMgdGhhdCB5b3UgY2FuIHRyYW5zcGFyZW50bHkgcHJvdmlkZSB0aGUgcmVh bCBhZGRyZXNzZXMgYW5kIHBvcnRzIGZyb20gY2xpZW50cyB0byB0aGUgcmVzdCBvZiB0aGUgSW50 ZXJuZXQgLSBob3dldmVyIHdlIGRvbid0IGxpdmUgaW4gc3VjaCB3b3JsZCwgdGhlcmVmb3JlIGhp ZGluZyBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIHByb3RlY3Rpb24gaW4gdGhlICJk ZWZlbmNlIGluIGRlcHRoIiBhcHByb2FjaC4NCg0KVGhlIGZhY3QgdGhhdCB0aGlzICJoaWRpbmci IGFjdHVhbGx5IGhpbmRlcnMgdGhlIGRlcGxveW1lbnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFr ZXMgbGlmZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4gbWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3Bp YyBvbiB3aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDotKQ0KDQpUaGVyZSBhcmUgYWxzbyBjYXNlcyB3 aGVyZSBOQVQgb2ZmZXJzIGJldHRlciAob3IgYXQgbGVhc3Qgc2ltcGxlcikgcHJvdGVjdGlvbiB0 aGFuIGZpbHRlcnMuICBGb3IgaW5zdGFuY2UsIHRoZXJlIGFyZSBrbm93biAib3ZlcmJpbGxpbmcg YXR0YWNrcyIgcGVyZm9ybWVkIGluIHRlbGNvIG5ldHdvcmtzLCB3aGVyZSBtb2JpbGUgdGVybWlu YWxzIGFyZSBzZW50IHdpdGggVURQIHBhY2tldHMgdG8ga2VlcCB0aGVtIGFsaXZlIGV2ZW4gaWYg d291bGQgYWN0dWFsbHkgZGlzY29ubmVjdCwgY2F1c2luZyB0aGVtIHRvIGJlIGV4Y2Vzc2l2ZWx5 IGJpbGxlZC4gIEZpbHRlcnMgZm9yIHRob3NlIHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGlj YXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcg b3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUgdGVybWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRm b3J3YXJkIHByb3RlY3Rpb24sIGluc3RlYWQuDQoNClBTLiBJIGFtIGF3YXJlIHRoYXQgbWFqb3Ig ZmlyZXdhbGwgdmVuZG9ycyBpbXBsZW1lbnQgZmlsdGVycyBhZ2FpbnN0IG92ZXJiaWxsaW5nIGF0 dGFja3M7IEkgd2FzIG9ubHkgbWFraW5nIGFuIG9iamVjdGlvbiB0byB0aGUgc2VtYW50aWMgb2Yg dGhlIHNlbnRlbmNlOiBOQVQgKnByb3ZpZGVzKiBzZWN1cml0eSwgc2F5aW5nIHRoZSBjb250cmFy eSBpcyBub3QgY29ycmVjdC4gIFdoZXRoZXIgdGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiBzb21l IG90aGVyIHdheXMgaXMgYW5vdGhlciBtYXR0ZXIuDQoNCg0KPj4gLSB0aGUgZmFjdCB0aGF0IGl0 IGlzIG5vdCBkZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNlIGlzIGFub3RoZXIg dG9waWMsIGluIHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxlYXN0IGZvciA5OSUg b2YgdXNlIGNhc2VzIDstKSkNCj4NCj4gSSBkb24ndCBzZWUgYSBuZWVkIHRvIGRlcGxveSBOQVQg d2l0aCBJUHY2IGFzIHdoYXQgaGFzIGJlZW4gYWNoaWV2ZWQgd2l0aCBJUHY0IE5BVCBjYW4gYmUg YWNoaWV2ZWQgaW4gSVB2NiB3aXRob3V0IHRoZSBkcmF3YmFja3Mgb2YgTkFULg0KDQpJIG1lYW4g dGhlIHNhbWUgYXMgeW91IGRvLCBJIHdvdWxkIGp1c3QgcGhyYXNlIGl0IGFzICJ0aGUgcG9vciBJ U1BzIHdoaWNoIHN0aWxsIGRvIHRoYXQsIHNob3VsZCBjb25zaWRlciBtaWdyYXRpbmcgdGhlaXIg YXJjaGl0ZWN0dXJlIHRvIGJldHRlciBvcHRpb25zIi4NCg0KDQpSZWdhcmRzLA0KTWFyY28NCg0K Pg0KPlJlZ2FyZHMsDQo+TWFyay4NCj4NCj4gUmVnYXJkcywNCj4g4oCL4oCL4oCL4oCL4oCLDQo+ IE1hcmNvIEVybWluaQ0KPg0KPiBDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBo RA0KPiBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlzdA0KPiBEwqArNDkgKDApODk5IDkwMSAxNTIz IMKgTcKgKzQ5ICgwKTE3NSA0MzkgNTY0Mg0KPg0KPiBSZXNNZWQgR2VybWFueSBJbmMNCj4NCj4N Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBTbWl0aCBbbWFp bHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAy MDE2IDExOjQzIEFNDQo+IFRvOiBNYXJjbyBFcm1pbmkNCj4gQ2M6IEJyaWFuIEUgQ2FycGVudGVy OyBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSk7IGZnb250QHNpNm5ldHdvcmtzLmNv bTsgb3BzZWNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IGxpbmtlZGlu QHhuLS1kZWJybi1udmEuZGU7IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNd IFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTA4DQo+ DQo+IE9uIDE2IEp1bmUgMjAxNiBhdCAxOToxNSwgTWFyY28gRXJtaW5pIDxNYXJjby5Fcm1pbmlA cmVzbWVkLmNvbT4gd3JvdGU6DQo+ID4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhp ZGluZyBJUyBwYXJ0IG9mIHNlY3VyaXR5LsKgIEl0IGlzIG5vdCB0aGUgZnVsbCBwaWN0dXJlLCBi dXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSB0aGF0IGl0IGlzIG5vdC4NCj4gPg0KPiA+IEkgcGVy c29uYWxseSBkb24ndCBzeW1wYXRoaXplIG9uIE5BVC1oYXRlcnMuwqAgTkFUIGhhcyBpdHMgcmVh c29ucywNCj4gPiBlc3BlY2lhbGx5IGZvciBjYXJyaWVyLWdyYWRlIE5BVA0KPg0KPiBDR04gaXNu J3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgSVNQcyBy dW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy4NCj4NCj4gwqBhbmQgZXNwZWNpYWxseSBpbiB0 aGUgdGVsY28gc2NlbmFyaW8sIGFuZCB5ZXMsIGl0IGRvZXMgcHJvdmlkZSBzb21lIGxldmVsIG9m IHNlY3VyaXR5IC0gYWdhaW4sIG5vdCB0aGUgY29tcGxldGUgcGljdHVyZSwgYnV0IGl0IGRvZXMu DQo+ID4NCj4NCj4gTkFUIGlzIG5vdCBuZWNlc3NhcnkgaW4gSVB2Ni4gVGhlIGVxdWl2YWxlbnQg b2YgTkFUJ3MgcGVyY2VpdmVkIHNlY3VyaXR5IGNhbiBiZSBwcm92aWRlZCB2aWEgYWx0ZXJuYXRp dmUgbWV0aG9kcywgYXMgZGVzY3JpYmVkIGluIFJGQzQ4NjQuDQo+DQo+IEEgZnVydGhlciB0ZWNo bmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0IGlz IHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEgc2lu Z2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4gRXh0 ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJUHY2 IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCj4NCj4gSWYgeW91IHRydWx5 IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNuJ3QgZG8gZW5v dWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFzIHRoZXJlIGFy ZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNlbGYgc3VwcGxp ZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkgaG9zdHMgZS5n LiBIVFRQIGNvb2tpZXMuICJBIFRlY2huaXF1ZSBmb3IgQ291bnRpbmcgTkFUdGVkIEhvc3RzIg0K PiAoaHR0cHM6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRmKSBzaG93 ZWQgaG93IGEgZmllbGQgd2l0aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBhY3Jvc3Mg YSBOQVQgd2FzIGFibGUgdG8gYmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy4NCj4NCj4gSWYgeW91 IHRydWx5IHdhbnQgdG8gaGlkZSBhIGhvc3QgZnJvbSB0aGUgSW50ZXJuZXQsIHlldCBzdGlsbCBh bGxvdyBpdCB0byBhY2Nlc3MgdGhpbmdzIG9uIHRoZSBJbnRlcm5ldCwgdW5kZXIgSVB2NiB5b3Vy IG5ldHdvcmsgd291bGQgdXNlIFVMQSBhZGRyZXNzaW5nLCBhbmQgaGF2ZSBhIHBlci1hcHBsaWNh dGlvbiBwcm90b2NvbCBwcm94eSBzZXJ2ZXIgdGhhdCBtYWtlcyBhbGwgcmVxdWVzdHMgbG9vayBs aWtlIHRoZXkndmUgZW50aXJlbHkgb3JpZ2luYXRlZCBmcm9tIHRoZSBhcHBsaWNhdGlvbiBwcm94 eSBzZXJ2ZXIgaXRzZWxmLiBUbyB0aGUgSW50ZXJuZXQgc2VydmVyLCB0aGUgYXBwbGljYXRpb24g cHJveHkgc2VydmVyIHdvdWxkIGFwcGVhciB0byBiZSB0aGUgYXBwbGljYXRpb24gZW5kIGhvc3Qg bWFraW5nIHRoZSByZXF1ZXN0cywgcHJldmVudGluZyBhbnkgaW50ZXJuYWwgaG9zdCBpZGVudGlm aWVycyBvciBvdGhlciBhdHRyaWJ1dGVzIGZyb20gbGVha2luZy4NCj4NCj4NCj4gUmVnYXJkcywN Cj4gTWFyay4NCj4NCj4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBNYXJjbyBFcm1pbmkN Cj4gPg0KPiA+IENJU1NQLCBDSVNBLCBDSVNNLCBDRUgsIElUSUwsIE1DUCwgUGhEIFNlbmlvciBJ VCBTZWN1cml0eSBBbmFseXN0IEQNCj4gPiArNDkgKDApODk5IDkwMSAxNTIzwqAgTSArNDkgKDAp MTc1IDQzOSA1NjQyDQo+ID4NCj4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPg0KPiA+DQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2Vj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+ID4gQ2FycGVudGVyDQo+ ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMTo0NSBBTQ0KPiA+IFRvOiBFcmlrIEts aW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkNCj4gPiBDYzogZmdvbnRAc2k2bmV0d29ya3MuY29t OyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsNCj4gPiBkcmFmdC1p ZXRmLW9wc2VjLXY2QGlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb T1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZg0KPiA+IGRyYWZ0LWlldGYtb3Bz ZWMtdjYtMDgNCj4gPg0KPiA+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3JvdGU6 DQo+ID4+IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZlIGZvciBteSB0YXN0ZXMu wqAgV2UgbmVlZCB0byBiZQ0KPiA+PiBhYmxlIHRvIHNheSB0aGF0IFVMQStJUHY2IE5BVCBpcyBO T1QgUkVDT01NRU5ERUQgYnkgdGhlIElFVEYuDQo+ID4NCj4gPiBJIGhhdmUgc3Ryb25nIHN5bXBh dGh5IHdpdGggdGhhdCBzdGF0ZW1lbnQsIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIGRv Y3VtZW50IHRvIGRvIGl0OyB0aGUgcG9pbnQgaXMgbWFkZSBpbiBSRkM0ODY0IHRvby4gV2hhdCB3 ZSBzaG91bGQgZG8gaGVyZSBpcyB1bmRlcmxpbmUgdGhhdCBOQVQgIT0gc2VjdXJpdHkuDQo+ID4N Cj4gPiBXaGlsZSBJJ20gaGVyZSwgc29tZSBvdGhlciBwb2ludHM6DQo+ID4NCj4gPiAiMi4yLsKg IEV4dGVuc2lvbiBIZWFkZXJzDQo+ID4NCj4gPsKgIMKgIFRCRCwgYSBzaG9ydCBzZWN0aW9uIHJl ZmVycmluZyB0byBhbGwgRmVybmFuZG8ncyBJLUQgJiBSRkMuIg0KPiA+DQo+ID4gVGhhdCdzIG5v dCB0aGUgd2hvbGUgc3RvcnkgOy0pLiBGaXJzdGx5LCBSRkMgNzA0NSBoYXMgYSBsb3Qgb2YNCj4g PiByZWxldmFuY2UgdG8gc2VjdXJpdHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVyZSBpcyBubyByZWFz b24gdG8gcmVmZXIgdG8NCj4gPiBtb3N0IG9mIHRoZSBtYXRlcmlhbCAoRmVybmFuZG8ncyBvciBu b3QpIHVubGVzcyBpdCdzIGRpcmVjdGx5IHJlbGV2YW50DQo+ID4gdG8gb3BzZWMuIEkgdGhpbmsg dGhlIHJlZmVyZW5jZSBpcyBkcmFmdC1pZXRmLW9wc2VjLWlwdjYtZWgtZmlsdGVyaW5nLA0KPiA+ IGJ1dCBvbmx5IGlmIHRoYXQgZG9jdW1lbnQgaXMgZ29pbmcgYW55d2hlcmUuDQo+ID4NCj4gPiAi Mi4zLjMuwqAgTkQvUkEgUmF0ZSBMaW1pdGluZw0KPiA+IC4uLg0KPiA+wqAgwqAgVGhlIGZvbGxv d2luZyBkcmFmdHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0bw0KPiA+wqAgwqAg cmF0ZSBsaW1pdCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9uIHdpZmkgbmV0d29ya3MgaW4g b3JkZXIgdG8NCj4gPsKgIMKgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4gPg0KPiA+wqAgwqAgb8Kg IFtJLUQudGh1YmVydC1zYXZpLXJhLXRocm90dGxlcl0NCj4gPg0KPiA+wqAgwqAgb8KgIFtJLUQu Y2hha3JhYmFydGktbm9yZG1hcmstNm1hbi1lZmZpY2llbnQtbmRdIg0KPiA+DQo+ID4gTmVpdGhl ciBvZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAy MDE1IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFk ZXIsIElNSE8uDQo+ID4NCj4gPiAiNC4yLsKgIFRyYW5zaXRpb24gTWVjaGFuaXNtDQo+ID4NCj4g PsKgIMKgIFNQIHdpbGwgdHlwaWNhbGx5IHVzZSB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgc3VjaCBh cyA2cmQsIDZQRSwgTUFQLA0KPiA+wqAgwqAgRFMtTGl0ZSB3aGljaCBoYXZlIGJlZW4gYW5hbHl6 ZWQgaW4gdGhlIHRyYW5zaXRpb24gU2VjdGlvbiAyLjcuMg0KPiA+wqAgwqAgc2VjdGlvbi4iDQo+ ID4NCj4gPiBTaG91bGRuJ3QgeW91IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiA+DQo+ID4g RmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQcml2YWN5IENvbnNpZGVyYXRpb25z IHNlY3Rpb24uDQo+ID4NCj4gPiBSZ2RzDQo+ID7CoCDCoCDCoEJyaWFuDQo+ID4NCj4gPj4NCj4g Pj4gU2VjdGlvbiAyLjYuMS41IGNvdWxkIHB1bmNoIHVwIHRoZSBTQVZJIHN0dWZmIGEgYml0IG1v cmUgYXMgd2VsbC7CoCBXZQ0KPiA+PiBzaG91bGQsIGluIG15IG9waW5pb24sIG1ha2UgaXQgcGFp bmZ1bGx5IGNsZWFyIHRoYXQgREhDUCAob2YgYW55DQo+ID4+IHByb3RvY29sKSBpbiB0aGUgYWJz ZW5jZSBvZiBsaW5rLWxheWVyIHNlY3VyaXR5L2F1ZGl0YWJpbGl0eSBmZWF0dXJlcw0KPiA+PiBk b2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0 eSBhbmQNCj4gPj4gdHJhY2VhYmlsaXR5IiBbU2VjdGlvbiAyLjEuNl0uDQo+ID4+DQo+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHY2b3Bz IG1haWxpbmcgbGlzdA0KPiA+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9QU0VDIG1haWxpbmcgbGlz dA0KPiA+IE9QU0VDQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNlYw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jun 16 17:21:36 2016 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 D428512DE1F; Thu, 16 Jun 2016 17:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcDUsQas6v3r; Thu, 16 Jun 2016 17:21:29 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B48C12D7D1; Thu, 16 Jun 2016 17:21:28 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id t129so95801463vka.1; Thu, 16 Jun 2016 17:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=r6ujoTLccWEriWSSauQux8MbHlVs4m56qw1Fv33Cy70=; b=J8MOPmbGGiQ9+z1WDUDu+DGABako3qxvV8hb2WVQblzV76bmshJA1/QinmV5CGjfCG hlaoBFvG7Jn88wYp1V7wGFxNNPf776n6EUYUau8ECR/cFzUWcxSt15aRNgK4JliFi+kf tuW/f8k2+kAi/2m6X/9pGGlvrVRZ0qVuSluXbPMBGBKL0dEUeCNJg/rODDI1U8Liqb63 6dxcHDyjKjS3XX8DPevCZVMvCx3U4Vxtw+q+5vy+xsznAPufFg2r0+SV3mK5cDR3wFBS OJlgZUEu93rE8zxUXVsFBjdrCVxPwk6esPIG4oAwdvFBGexlTtEjFlCDUmC8MNXix2vN ioxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=r6ujoTLccWEriWSSauQux8MbHlVs4m56qw1Fv33Cy70=; b=StHD6h70cmPFxdTVMufRNUOVS+yXxjfFPmwm8TX1nfl7lNNgFDhFmpw9e6Y91Q7e9/ ZUzs7a9MvC1drLY2zXKBHmjGimdUjOCjPJMyq07VxEtSBEM1tr6zuQcckFScwEMMSfnA woPvIJa1pr2oWJzLbeZ2YwqUGp9gY5ZevRXrL91IMWIfIfiSFAZWfP95RyW3TC+kmw1B 9ttCwKXPPsBrOZz5fkCGqzCjeMyuHjwuxQG51HWWS6TsnGv4sgpk/7aC39uS0Vx4aKfr vHxTaPUdkFY15YdPk9mv8iLhH6n3YTSj11lx6cU661+SGX2O51L8X3gDy2WhG/RPfbbg 6Efw== X-Gm-Message-State: ALyK8tIhi0dwf50fcf2LF6HwSlGb4YPJtUU013NQEH/wFEIEaWPaPaQa6/7ETpWYztyoPzM+MUODB7Vd88N2Ow== MIME-Version: 1.0 X-Received: by 10.176.2.87 with SMTP id 81mr3036088uas.67.1466122887300; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) In-Reply-To: <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> Date: Fri, 17 Jun 2016 10:21:27 +1000 Message-ID: From: Mark Smith To: Marco Ermini Content-Type: multipart/alternative; boundary=001a1137634ae50e6505356e55a5 Archived-At: Cc: "v6ops@ietf.org" , draft-ietf-opsec-v6@ietf.org, "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 00:21:34 -0000 --001a1137634ae50e6505356e55a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 Jun 2016 00:15, "Marco Ermini" wrote: > > I'll try the horrible Outlook to reply using text, please beg my pardon if this is not formatted properly. > > On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto: markzzzsmith@gmail.com] wrote: > >> Hi, > >> > >> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the > >> CGN equipment can't handle them differently. > >Can you provide an example of this sort of CGN device. > > I would prefer not to make names, but you would be unpleasantly surprised= . I'm sceptical, I and I think others would want a concrete example. If people aren't implementing specifications well, we need to know, so that if necessary the specifications can be improved. Anyway, it is also not just a matter of not being able to configure them in a certain way (which is possibly the case), but also the case in which they don't work properly. > > > IPv4 and IPv6 have to be handled differently because they're different protocols, requiring different code. A single device might be > > performing NAT on IPv4 traffic it receives and doing standard stateless forwarding of IPv6 traffic. Is that the scenario you're describing? > > Yes, for instance. OK, so "CGN" is not being performed on IPv6 traffic. >Or, they handle certain functions (e.g. NAT) purely in the data plane as they are logically simple to be implemented in firmware, while more complex functions (like implementing ULA addresses translation) requires routine engines to be involved, therefore involving different latency for execution= . > So this sounds like equipment here additional features cannot be implemented in hardware, so it is implemented in control plane software. This is an example of why not to use NAT. It is technically very complex compared to pure IPv4 and pure IPv6 forwarding. I'm starting to wonder if people think that if they want to use ULAs for some reason, they think they then must NAT them. If they do, I think that might show a misunderstanding of something fundamental about IPv6 - a host natively supports multiple concurrent addresses with different scopes, and tries to choose one of its source address to match the destination address. > It is pretty common that customers with ISPs offering dual stack, to experience a higher latency for their connection once they implement IPv6 along with IPv4. This does not apply when only IPv4 or only IPv6 are used= . > I'd like some examples of this. I've been natively dual stacked at home for the past near 5 years. I have not experienced additional and noticeable higher latency for anything I do. It just works, and I can't tell what is going over IPv4 or IPv6 - and I know that most if not all Google, Facebook and Netflix traffic can and does come over IPv6. I also worked in the residential deployment of IPv6 at the other end of my connection in 2009/2010, and we never received any IPv6 latency complaints. In 2012 it was enabled by default for new customer connections. I have come across presentations over the past years that have shown that IPv6 has reduced latency for dual stack services, because the IPv6 path was different and simpler than the IPv4 path. > Another requirement is that a specific logging or monitoring system is implemented (especially for legal requirements), and this is done through logging NAT translations. An ISP implementing IPv6 along with IPv4 would be in that situation. > No need to do _address translation_ to be able to perform that. > Luckily, router vendors are moving away from the antiquate architecture which separates data and management plane, for various reasons. > Actually, that's going to increase the cost of equipment, because it isn't going to be cheap to do something complex fast. > This is also why we published draft-gont-opsec-ipv6-firewall-reqs-03.txt, to make it explicit that this should not happen. > > (I am aware this is off-topic, just making my point :-)) > > >>Unfortunately RFC 4864 does not mention such case, AFAIK. > >> > > In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use > > cases. > > Okay > > >> I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be > >> written as such in the RFC. > > So this draft is purely about IPv6. There will be a lot of IPv4 security measures that can be applied to IPv6, however there will also be others > > that shouldn't, and opportunities where IPv6 can provide better security that IPv4 (e.g. sparse host addressing in a /64 makes address probing > > to discover hosts impossible within a useful and practical timeframe.). > > Okay, I have nothing to object on this. > > > >> NAT *does* provide a form of security > >What specific security does it provide that is due to the address translation function? > > If you're thinking about the protection provided due to the state being created during the address translation process, that state can be > > created without performing address translation, which is what a stateful firewall does and did in IPv4 before NAT became widely deployed. > > I totally agree with you. I am actually referring to the possibility to hide the systems behind the NATted interfaces of the router/firewall, not just their addresses but also ports and services. If you only apply filtering, you are protecting - but not hiding. > NAT is no where near as effective at hiding systems as people think. Too many attributes of the system behind the NAT leak across NAT, or can be forced to leak across the NAT. It is quite a porous barrier, because NAT is not actually designed to hide systems. Address translation inherently hides some of the attributes of the systems (addresses) but not all of them. > In a perfect world, you have such good filters that you can transparently provide the real addresses and ports from clients to the rest of the Internet It's sounding like you're not up to date with IPv6 firewalling capabilities in devices, and therefore might be assuming that none exist. Are you aware for example that Windows has had a stateful IPv6 firewall, enabled by default, since Windows XP service pack 2, released more than a decade ago? I've been using IPv6 under Linux to access the Internet either via tunnels or natively for more than a decade, using the stateful IPv6 firewall that has been part of the Linux kernel for at least that long. This Android phone has native and public IPv6 addresses and is not behind any sort of IPv6 NAT. It's behind a device that can perform IPv6 stateful firewalling, however I think I've turned it off, because I trust that as Google can't trust there is a network firewall upstream of my phone, they ensure my phone is "Internet proof". The "perfect" world you're referring to is and has been reality for a long time for a lot of people. >- however we don't live in such world, therefore hiding provides an additional layer of protection in the "defence in depth" approach. > > The fact that this "hiding" actually hinders the deployment of many services and makes life worse to engineers in many cases, is another topic on which we agree totally :-) > > There are also cases where NAT offers better (or at least simpler) protection than filters. For instance, there are known "overbilling attacks" performed in telco networks, where mobile terminals are sent with UDP packets to keep them alive even if would actually disconnect, causing them to be excessively billed. Filters for those situations tend to be complicated and need to understand the Layer-7 protocol running over UDP to protect the terminals; NAT offers a straightforward protection, instead. > There is no need to perform _address translation_ to perform this protection. Continuing to say NAT in these examples is a bit like saying "I need my toolbox to bang in nails". You need your toolbox because that is where your hammer is, however it is actually your hammer that you use to bang in nails= . NAT is address translation + stateful filtering inherent in the operation of address translation. People who object to NAT in IPv6 are objecting to the implied assertion that it is necessary to perform address translation to achieve stateful filtering. People who advocate NAT for IPv6 for security purposes don't seem to understand that address translation is *not* required to be able to perform stateful filtering - or they're using the term "NAT" when they should really be using the term "stateful filtering". > PS. I am aware that major firewall vendors implement filters against overbilling attacks; I was only making an objection to the semantic of the sentence: NAT *provides* security, saying the contrary is not correct. "Security against what" is the key question. You can't actually say NAT provides security without defining the threat or context. If you don't define the threat, the implication of such a statement is that it provides security against literally every threat. If a bank implements NAT on their data network, are they now secured against bank robbers coming into a branch with guns? Obviously not. "NAT *provides* security" is going to be wrong in many cases because NAT is an entirely ineffective measure for a large set of threats. > Whether this could be achieved in some other ways is another matter. > It is the *exact* matter here. NAT is being asserted as the security measure that should by used in IPv6, because it has been used in IPv4 (and not necessarily exclusively because of security - lack of IPv4 addresses is another reason), without any consideration of its drawbacks or alternatives that don't have those drawbacks e.g. those described in RFC4864. > > >> - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-)) > > > > I don't see a need to deploy NAT with IPv6 as what has been achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT. > > I mean the same as you do, I would just phrase it as "the poor ISPs which still do that, should consider migrating their architecture to better options". > The cost of CGN capacity to NAT video traffic volumes from popular video sites is likely going to make deploying native IPv6 a cheaper alternative very quickly. Regards, Mark. > > Regards, > Marco > > > > >Regards, > >Mark. > > > > Regards, > > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > > Marco Ermini > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > > Senior IT Security Analyst > > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > ResMed Germany Inc > > > > > > > > -----Original Message----- > > From: Mark Smith [mailto:markzzzsmith@gmail.com] > > Sent: Thursday, June 16, 2016 11:43 AM > > To: Marco Ermini > > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org > > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 > > > > On 16 June 2016 at 19:15, Marco Ermini wrote: > > > Well, actually, infrastructure hiding IS part of security. It is not the full picture, but it is incorrect to say that it is not. > > > > > > I personally don't sympathize on NAT-haters. NAT has its reasons, > > > especially for carrier-grade NAT > > > > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. > > > > and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > > > > > > > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. > > > > A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. > > > > If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" > > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. > > > > If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. > > > > > > Regards, > > Mark. > > > > > > > > > > Regards, > > > > > > Marco Ermini > > > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D > > > +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > > > ResMed Germany Inc > > > > > > > > > -----Original Message----- > > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E > > > Carpenter > > > Sent: Thursday, June 16, 2016 1:45 AM > > > To: Erik Kline; Eric Vyncke (evyncke) > > > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; > > > draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > > > Subject: Re: [OPSEC] [v6ops] Asking for a review of > > > draft-ietf-opsec-v6-08 > > > > > > On 16/06/2016 07:45, 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. > > > > > > I have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT !=3D security. > > > > > > While I'm here, some other points: > > > > > > "2.2. Extension Headers > > > > > > TBD, a short section referring to all Fernando's I-D & RFC." > > > > > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of > > > relevance to security aspects. Second, there is no reason to refer to > > > most of the material (Fernando's or not) unless it's directly relevan= t > > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering= , > > > but only if that document is going anywhere. > > > > > > "2.3.3. ND/RA Rate Limiting > > > ... > > > The following drafts are actively discussing methods to > > > rate limit RAs and other ND messages on wifi networks in order to > > > address this issue: > > > > > > o [I-D.thubert-savi-ra-throttler] > > > > > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > > > > > Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. > > > > > > "4.2. Transition Mechanism > > > > > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > > > DS-Lite which have been analyzed in the transition Section 2.7.2 > > > section." > > > > > > Shouldn't you add RFC6877 464XLAT now? > > > > > > Finally, I think there should be a Privacy Considerations section. > > > > > > Rgds > > > Brian > > > > > >> > > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. W= e > > >> should, in my opinion, make it painfully clear that DHCP (of any > > >> protocol) in the absence of link-layer security/auditability feature= s > > >> does not provide any satisfactory way "to ensure audibility and > > >> traceability" [Section 2.1.6]. > > >> > > >> _______________________________________________ > > >> 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 > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops --001a1137634ae50e6505356e55a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 17 Jun 2016 00:15, "Marco Ermini" <Marco.Ermini@resmed.com> wrote:
>
> I'll try the horrible Outlook to reply using text, please beg my p= ardon if this is not formatted properly.
>
> On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto:markzzzsmith@gmail.com] wrote:
> >> Hi,
> >>
> >> NAT can be still necessary in IPv6 in dual-stack scenario, fo= r instance, where every host is assigned both a IPv4 and IPv6 addresses and= the
> >> CGN equipment can't handle them differently.=C2=A0
> >Can you provide an example of this sort of CGN device.
>
> I would prefer not to make names, but you would be unpleasantly surpri= sed.

I'm sceptical, I and I think others would want a concret= e example.

If people aren't implementing specifications well, we ne= ed to know, so that if necessary the specifications can be improved.

=C2=A0 Anyway, it is also not just a matter of not being abl= e to configure them in a certain way (which is possibly the case), but also= the case in which they don't work properly.
>
> > IPv4 and IPv6 have to be handled differently because they're = different protocols, requiring different code. A single device might be
> > performing NAT on IPv4 traffic it receives and doing standard sta= teless forwarding of IPv6 traffic. Is that the scenario you're describi= ng?
>
> Yes, for instance.=C2=A0

OK, so "CGN" is not being performed on IPv6 traffi= c.

>Or, they handle certain functions (e.g. NAT) purely in = the data plane as they are logically simple to be implemented in firmware, = while more complex functions (like implementing ULA addresses translation) = requires routine engines to be involved, therefore involving different late= ncy for execution.
>

So this sounds like equipment here additional features canno= t be implemented in hardware, so it is implemented in control plane softwar= e.

This is an example of why not to use NAT. It is technically = very complex compared to pure IPv4 and pure IPv6 forwarding.

I'm starting to wonder if people think that if they want= to use ULAs for some reason, they think they then must NAT them. If they d= o, I think that might show a misunderstanding of something fundamental abou= t IPv6 - a host natively supports multiple concurrent addresses with differ= ent scopes, and tries to choose one of its source address to match the dest= ination address.

> It is pretty common that customers with ISPs offering d= ual stack, to experience a higher latency for their connection once they im= plement IPv6 along with IPv4.=C2=A0 =C2=A0This does not apply when only IPv= 4 or only IPv6 are used.
>

I'd like some examples of this.

I've been natively dual stacked at home for the past nea= r 5 years. I have not experienced additional and noticeable higher latency = for anything I do. It just works, and I can't tell what is going over I= Pv4 or IPv6 - and I know that most if not all Google, Facebook and Netflix = traffic can and does come over IPv6.

I also worked in the residential deployment of IPv6 at the o= ther end of my connection in 2009/2010, and we never received any IPv6 late= ncy complaints. In 2012 it was enabled by default for new customer connecti= ons.

I have come across presentations over the past years that ha= ve shown that IPv6 has reduced latency for dual stack services, because the= IPv6 path was different and simpler than the IPv4 path.

> Another requirement is that a specific logging or monit= oring system is implemented (especially for legal requirements), and this i= s done through logging NAT translations.=C2=A0 An ISP implementing IPv6 alo= ng with IPv4 would be in that situation.
>

No need to do _address translation_ to be able to perform th= at.

> Luckily, router vendors are moving away from the antiqu= ate architecture which separates data and management plane, for various rea= sons.
>

Actually, that's going to increase the cost of equipment= , because it isn't going to be cheap to do something complex fast.

> This is also why we published draft-gont-opsec-ipv6-fir= ewall-reqs-03.txt, to make it explicit that this should not happen.
>
> (I am aware this is off-topic, just making my point :-))
>
> >>Unfortunately RFC 4864 does not mention such case, AFAIK.
> >>
> > In any case, I am happy to concede it could be an extreme case an= d that it is not necessary anymore in IPv6 for the great majority of use > > cases.
>
> Okay
>
> >> I was not really making a specific case for IPv6 - my opposit= ion was to the concept that NAT is not security, and to the fact that it sh= ould be
> >> written as such in the RFC.
> > So this draft is purely about IPv6. There will be a lot of IPv4 s= ecurity measures that can be applied to IPv6, however there will also be ot= hers
> > that shouldn't, and opportunities where IPv6 can provide bett= er security that IPv4 (e.g. sparse host addressing in a /64 makes address p= robing
> > to discover hosts impossible within a useful and practical timefr= ame.).
>
> Okay, I have nothing to object on this.
>
>
> >> NAT *does* provide a form of security
> >What specific security does it provide that is due to the address = translation function?
> > If you're thinking about the protection provided due to the s= tate being created during the address translation process, that state can b= e
> > created without performing address translation, which is what a s= tateful firewall does and did in IPv4 before NAT became widely deployed. >
> I totally agree with you.=C2=A0 I am actually referring to the possibi= lity to hide the systems behind the NATted interfaces of the router/firewal= l, not just their addresses but also ports and services.=C2=A0 If you only = apply filtering, you are protecting - but not hiding.
>

NAT is no where near as effective at hiding systems as peopl= e think. Too many attributes of the system behind the NAT leak across NAT, = or can be forced to leak across the NAT.

It is quite a porous barrier, because NAT is not actually de= signed to hide systems. Address translation inherently hides some of the at= tributes of the systems (addresses) but not all of them.

> In a perfect world, you have such good filters that you= can transparently provide the real addresses and ports from clients to the= rest of the Internet

It's sounding like you're not up to date with IPv6 f= irewalling capabilities in devices, and therefore might be assuming that no= ne exist.

Are you aware for example that Windows has had a stateful IP= v6 firewall, enabled by default, since Windows XP service pack 2, released = more than a decade ago?

I've been using IPv6 under Linux to access the Internet = either via tunnels or natively for more than a decade, using the stateful I= Pv6 firewall that has been part of the Linux kernel for at least that long.=

This Android phone has native and public IPv6 addresses and = is not behind any sort of IPv6 NAT. It's behind a device that can perfo= rm IPv6 stateful firewalling, however I think I've turned it off, becau= se I trust that as Google can't trust there is a network firewall upstr= eam of my phone, they ensure my phone is "Internet proof".

The "perfect" world you're referring to is and= has been reality for a long time for a lot of people.

>- however we don't live in such world, therefore hid= ing provides an additional layer of protection in the "defence in dept= h" approach.
>
> The fact that this "hiding" actually hinders the deployment = of many services and makes life worse to engineers in many cases, is anothe= r topic on which we agree totally :-)
>
> There are also cases where NAT offers better (or at least simpler) pro= tection than filters.=C2=A0 For instance, there are known "overbilling= attacks" performed in telco networks, where mobile terminals are sent= with UDP packets to keep them alive even if would actually disconnect, cau= sing them to be excessively billed.=C2=A0 Filters for those situations tend= to be complicated and need to understand the Layer-7 protocol running over= UDP to protect the terminals; NAT offers a straightforward protection, ins= tead.
>

There is no need to perform _address translation_ to perform= this protection.

Continuing to say NAT in these examples is a bit like saying= "I need my toolbox to bang in nails". You need your toolbox beca= use that is where your hammer is, however it is actually your hammer that y= ou use to bang in nails.

NAT is address translation + stateful filtering inherent in = the operation of address translation. People who object to NAT in IPv6 are = objecting to the implied assertion that it is necessary to perform address = translation to achieve stateful filtering.

People who advocate NAT for IPv6 for security purposes don&#= 39;t seem to understand that address translation is *not* required to be ab= le to perform stateful filtering - or they're using the term "NAT&= quot; when they should really be using the term "stateful filtering&qu= ot;.

> PS. I am aware that major firewall vendors implement fi= lters against overbilling attacks; I was only making an objection to the se= mantic of the sentence: NAT *provides* security, saying the contrary is not= correct.=C2=A0

"Security against what" is the key question. You c= an't actually say NAT provides security without defining the threat or = context. If you don't define the threat, the implication of such a stat= ement is that it provides security against literally every threat.

If a bank implements NAT on their data network, are they now= secured against bank robbers coming into a branch with guns? Obviously not= .

"NAT *provides* security" is going to be wrong in = many cases because NAT is an entirely ineffective measure for a large set o= f threats.

> Whether this could be achieved in some other ways is an= other matter.
>

It is the *exact* matter here.

NAT is being asserted as the security measure that should by= used in IPv6, because it has been used in IPv4 (and not necessarily exclus= ively because of security - lack of IPv4 addresses is another reason), with= out any consideration of its drawbacks or alternatives that don't have = those drawbacks e.g. those described in RFC4864.

>
> >> - the fact that it is not desirable or it is unnecessary to u= se is another topic, in which I believe we all agree (at least for 99% of u= se cases ;-))
> >
> > I don't see a need to deploy NAT with IPv6 as what has been a= chieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT.=
>
> I mean the same as you do, I would just phrase it as "the poor IS= Ps which still do that, should consider migrating their architecture to bet= ter options".
>

The cost of CGN capacity to NAT video traffic volumes from p= opular video sites is likely going to make deploying native IPv6 a cheaper = alternative very quickly.

Regards,
Mark.

>
> Regards,
> Marco
>
> >
> >Regards,
> >Mark.
> >
> > Regards,
> > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B
> > Marco Ermini
> >
> > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> > Senior IT Security Analyst
> > D=C2=A0+49 (0)899 901 1523 =C2=A0M=C2=A0+49 (0)175 439 5642
> >
> > ResMed Germany Inc
> >
> >
> >
> > -----Original Message-----
> > From: Mark Smith [mailto:markzzzsmith@gmail.com]
> > Sent: Thursday, June 16, 2016 11:43 AM
> > To: Marco Ermini
> > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org
> > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-op= sec-v6-08
> >
> > On 16 June 2016 at 19:15, Marco Ermini <Marco.Ermini@resmed.com> wrote:
> > > Well, actually, infrastructure hiding IS part of security.= =C2=A0 It is not the full picture, but it is incorrect to say that it is no= t.
> > >
> > > I personally don't sympathize on NAT-haters.=C2=A0 NAT h= as its reasons,
> > > especially for carrier-grade NAT
> >
> > CGN isn't necessary in IPv6, it's to solve the problem of= ISPs running out of IPv4 addresses.
> >
> > =C2=A0and especially in the telco scenario, and yes, it does prov= ide some level of security - again, not the complete picture, but it does.<= br> > > >
> >
> > NAT is not necessary in IPv6. The equivalent of NAT's perceiv= ed security can be provided via alternative methods, as described in RFC486= 4.
> >
> > A further technique to hide topology that isn't mentioned in = RFC4864 is to use something like ISATAP or similar, to create a single /64 = subnet over the top of multiple IPv4 subnets. Externally, all hosts will ap= pear to belong to a single IPv6 subnet, hiding the internal topology.
> >
> > If you truly want to hide the identities of hosts, NAT doesn'= t do enough - it is only translating addresses, where as there are many oth= er host identifiers that the host itself supplies or will receive and suppl= y that can identify hosts e.g. HTTP cookies. "A Technique for Counting= NATted Hosts"
> > (htt= ps://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field withi= n the IPv4 header that leaked across a NAT was able to be used to identify = hosts.
> >
> > If you truly want to hide a host from the Internet, yet still all= ow it to access things on the Internet, under IPv6 your network would use U= LA addressing, and have a per-application protocol proxy server that makes = all requests look like they've entirely originated from the application= proxy server itself. To the Internet server, the application proxy server = would appear to be the application end host making the requests, preventing= any internal host identifiers or other attributes from leaking.
> >
> >
> > Regards,
> > Mark.
> >
> >
> > >
> > > Regards,
> > >
> > > Marco Ermini
> > >
> > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security An= alyst D
> > > +49 (0)899 901 1523=C2=A0 M +49 (0)175 439 5642
> > >
> > > ResMed Germany Inc
> > >
> > >
> > > -----Original Message-----
> > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E
> > > Carpenter
> > > Sent: Thursday, June 16, 2016 1:45 AM
> > > To: Erik Kline; Eric Vyncke (evyncke)
> > > Cc: fgont@si6networ= ks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de;
> > > draft-ietf-o= psec-v6@ietf.org; v6ops@ietf.org<= br> > > > Subject: Re: [OPSEC] [v6ops] Asking for a review of
> > > draft-ietf-opsec-v6-08
> > >
> > > On 16/06/2016 07:45, Erik Kline wrote:
> > >> Section 2.1.2 is far too permissive for my tastes.=C2=A0= We need to be
> > >> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the = IETF.
> > >
> > > I have strong sympathy with that statement, but I don't = think this is the document to do it; the point is made in RFC4864 too. What= we should do here is underline that NAT !=3D security.
> > >
> > > While I'm here, some other points:
> > >
> > > "2.2.=C2=A0 Extension Headers
> > >
> > >=C2=A0 =C2=A0 TBD, a short section referring to all Fernando&= #39;s I-D & RFC."
> > >
> > > That's not the whole story ;-). Firstly, RFC 7045 has a = lot of
> > > relevance to security aspects. Second, there is no reason to= refer to
> > > most of the material (Fernando's or not) unless it's= directly relevant
> > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-= filtering,
> > > but only if that document is going anywhere.
> > >
> > > "2.3.3.=C2=A0 ND/RA Rate Limiting
> > > ...
> > >=C2=A0 =C2=A0 The following drafts are actively discussing me= thods to
> > >=C2=A0 =C2=A0 rate limit RAs and other ND messages on wifi ne= tworks in order to
> > >=C2=A0 =C2=A0 address this issue:
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 [I-D.thubert-savi-ra-throttler]
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 [I-D.chakrabarti-nordmark-6man-efficien= t-nd]"
> > >
> > > Neither of those drafts is in the least active (from 2012 an= d 2015 respectively). Dead drafts are of no help to the reader, IMHO.
> > >
> > > "4.2.=C2=A0 Transition Mechanism
> > >
> > >=C2=A0 =C2=A0 SP will typically use transition mechanisms suc= h as 6rd, 6PE, MAP,
> > >=C2=A0 =C2=A0 DS-Lite which have been analyzed in the transit= ion Section 2.7.2
> > >=C2=A0 =C2=A0 section."
> > >
> > > Shouldn't you add RFC6877 464XLAT now?
> > >
> > > Finally, I think there should be a Privacy Considerations se= ction.
> > >
> > > Rgds
> > >=C2=A0 =C2=A0 =C2=A0Brian
> > >
> > >>
> > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more= as well.=C2=A0 We
> > >> should, in my opinion, make it painfully clear that DHCP= (of any
> > >> protocol) in the absence of link-layer security/auditabi= lity features
> > >> does not provide any satisfactory way "to ensure au= dibility and
> > >> traceability" [Section 2.1.6].
> > >>
> > >> _______________________________________________
> > >> v6ops mailing list
> > >> v6ops@ietf.org
> > >> = https://www.ietf.org/mailman/listinfo/v6ops
> > >>
> > >
> > > _______________________________________________
> > > OPSEC mailing list
> > > OPSEC@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/opsec
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/v6ops

--001a1137634ae50e6505356e55a5-- From nobody Thu Jun 16 18:39:34 2016 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 34B0F12DE5A; Thu, 16 Jun 2016 18:39:29 -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 GjLP6bkdhEmM; Thu, 16 Jun 2016 18:39:26 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 45BF412D8E3; Thu, 16 Jun 2016 18:39:26 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id i123so21504406pfg.0; Thu, 16 Jun 2016 18:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=odFFwxCuq6kkO8jAxT6tY0fM0ohVaoty6Gkts7IHa+A=; b=JgWqkC+cerirZUGo79Nq5mFmK5LIWwxN+mHsxMTCQelGs0j9RRE2o6BhOs44BDm4m9 kaBdjURFLo4ITciTyz9mHRPCAoX2/0FHI+61Shz8LSEDOMN5phmgnnVn+Bt0N8YTdY/N v/g7fRq6J8WI0vuFtG4ymwQ6rXBD1GNpmm2m8Hhb3309bA9tm4d3Nkc7u0ht4jtX0IJS 0fENS9kzw4bKbhzCrR66QtFeVbpsQeucv9mpE8wpAvvEGZZYzdeARuv3AfFJA+AZL1RM V/Vc578vZ/u0r+WJyUtq2ywkRlIEr7VHLDlCcM4XUUtDQ1TF15KGIfFeWPjgFSOBBdOt zRtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=odFFwxCuq6kkO8jAxT6tY0fM0ohVaoty6Gkts7IHa+A=; b=JvtSXlaPuntVYazpg0p+Ic/rZgnIZ5b1SmiiYg1+gt+1FsCQdDiXhNNOihOubYfXOK 9DgAzoxTEPAkr5zQNG7AkwqfLbClHdpHQLgUbMDwLj2P2JyZrCEqkhh9ORuHeVUKkGD/ iG4cKT2QuRd2crCbaD2x5rIEZY/1zY277sbMOcAjnkZTv7BGsMA27RViHarTBOZhc7aP 5kiH9RCWJcQl9p8nhxm5h592BN2m+moeb5nEAJh3LeSEHvMEZqo7KfGppuuueG758Utq jy0zXyHwkTqr79qWFtAUgA8rUcuGIOT1BtgEXDmE1RT6uI+DqTfXpWGeNOj32GD26o1t 9Elw== X-Gm-Message-State: ALyK8tKrnbkhCr22+4LLpipgjPK24XUmRhfcyJ7c0j2MEy6DhyDM1PdhrDZrtYqLPVKPWA== X-Received: by 10.98.70.11 with SMTP id t11mr8657013pfa.16.1466127565821; Thu, 16 Jun 2016 18:39:25 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id c8sm40992272pfb.33.2016.06.16.18.39.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:39:25 -0700 (PDT) To: Marco Ermini , Erik Kline , "Eric Vyncke (evyncke)" References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 17 Jun 2016 13:39:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:39:29 -0000 On 16/06/2016 21:15, Marco Ermini wrote: > Well, actually, infrastructure hiding IS part of security. It is not t= he full picture, but it is incorrect to say that it is not. Have you read RFC4864 recently? Section 4.4 is all about how you don't ne= ed NAT to hide infrastructure topology in IPv6. > I personally don't sympathize on NAT-haters. NAT has its reasons, espe= cially for carrier-grade NAT and especially in the telco scenario, and ye= s, it does provide some level of security - again, not the complete pictu= re, but it does. That's IPv4. This is IPv6. Brian >=20 >=20 > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini >=20 > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 >=20 > ResMed Germany Inc >=20 >=20 > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E Carpen= ter > Sent: Thursday, June 16, 2016 1:45 AM > To: Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; d= raft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16/06/2016 07:45, Erik Kline wrote: >> Section 2.1.2 is far too permissive for my tastes. We need to be able= =20 >> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >=20 > I have strong sympathy with that statement, but I don't think this is t= he document to do it; the point is made in RFC4864 too. What we should do= here is underline that NAT !=3D security. >=20 > While I'm here, some other points: >=20 > "2.2. Extension Headers >=20 > TBD, a short section referring to all Fernando's I-D & RFC." >=20 > That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevanc= e to security aspects. Second, there is no reason to refer to most of the= material (Fernando's or not) unless it's directly relevant to opsec. I t= hink the reference is draft-ietf-opsec-ipv6-eh-filtering, > but only if that document is going anywhere. >=20 > "2.3.3. ND/RA Rate Limiting > ... > The following drafts are actively discussing methods to > rate limit RAs and other ND messages on wifi networks in order to > address this issue: >=20 > o [I-D.thubert-savi-ra-throttler] >=20 > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >=20 > Neither of those drafts is in the least active (from 2012 and 2015 resp= ectively). Dead drafts are of no help to the reader, IMHO. >=20 > "4.2. Transition Mechanism >=20 > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > DS-Lite which have been analyzed in the transition Section 2.7.2 > section." >=20 > Shouldn't you add RFC6877 464XLAT now? >=20 > Finally, I think there should be a Privacy Considerations section. >=20 > Rgds > Brian >=20 >> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We = >> should, in my opinion, make it painfully clear that DHCP (of any >> protocol) in the absence of link-layer security/auditability features = >> does not provide any satisfactory way "to ensure audibility and=20 >> traceability" [Section 2.1.6]. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 From nobody Thu Jun 16 18:46:20 2016 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 0950812DA0A; Thu, 16 Jun 2016 18:46:19 -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 ZxADrLFNjejF; Thu, 16 Jun 2016 18:46:16 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C93112DE56; Thu, 16 Jun 2016 18:46:16 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id h14so10161240pfe.1; Thu, 16 Jun 2016 18:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZY0kZ3X+yCP9p6KciCKJCOMMqenZ5XX12oaNASeBKrU=; b=xylTvYBb3/MlGM3TZKIqkaoXIzJzA9wiaZNAH2huQQ2UQ1WYqHIUBc1UJ8gD2ffgbY LhZUd0cHuCAo2G+wWr62FuMcj9SRkFUknQc0TEcaD9FPpGojBe/yCEDD6HcPpAURKdDu HYhdfA2U54DHcMNhpiP0w8YOp9eEWPxtUZ1YWJGMBgsy3IuVa+QAUsXjj7Cqf+54T3xQ tr3PFbqlBgmWyXTreMzLwQW8dnmNykhoWZN5QNvIN7V8m23TmrZJ20bLkcZ6vHd2PkVe 1XP2rgPtiwT/hOSyhQX0X+BmzurfdKa9Zv42OgpjddBYJ7JbMz+wWbf4Z/WZEGXJS1Sq nGcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=ZY0kZ3X+yCP9p6KciCKJCOMMqenZ5XX12oaNASeBKrU=; b=GKpBuZe56HG0Vsy74WcjHrds/fhS5AVTSDmyBPZgJpicxe5Uz/tnjmfq3KfL8xDOkz NhdL3CXP3CF2qB9A7rloWrQNVq2mKAbMG9/Na2aILDPSSY8MW1k5EVHBNp3//PiwJE4o PJUva/CYS4DmGb6PaErqX3YAamcNXlF4xXTatmG2fBza2pJ7/u/BWQCftBnPuZnFTpb1 jT7SsTqQBMHZo3E7mR2F1FuNBSMhV+ShYk4sMXtxU0oFh5ncQqPorq+TjHieh8dByufY 7mwPtBk88+axIKNIDWR0YOdtxVmTeTkLEfOuI9t6LodS3+pzmrOvuzvfF23zdZiIs09F GHiw== X-Gm-Message-State: ALyK8tKVqS9oZ5Sv7/EYkSTWI03UOsjSEZU8ySuLsxDVDT6rz7e6lznifeRuufAzzgHHZw== X-Received: by 10.98.56.86 with SMTP id f83mr8734966pfa.83.1466127975543; Thu, 16 Jun 2016 18:46:15 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id p1sm63499854pfb.73.2016.06.16.18.46.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:46:15 -0700 (PDT) To: Marco Ermini , Mark Smith References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1e28b94a-e920-4b0e-c062-100cc598ba85@gmail.com> Date: Fri, 17 Jun 2016 13:46:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:46:19 -0000 In addition to what Mark said about this: On 16/06/2016 22:03, Marco Ermini wrote: > Hi, >=20 > NAT can be still necessary in IPv6 in dual-stack scenario, for instance= , where every host is assigned both a IPv4 and IPv6 addresses and the CGN= equipment can't handle them differently. Unfortunately RFC 4864 does no= t mention such case, AFAIK. CGN and IPv6 are completely orthogonal, even in a dual stack scenario. v4 packets go to the CGN function and v6 packets go to the v6 router function, possibly in the same box. So absolutely the equipment handles them differently. (If there are sick products that get this wrong, that is not really the IETF's business. Although it's a bit out of date in seome aspects, RFC 6264, An Incremental Carrier-Grade NAT (CGN) for IPv6= Transition, explains how to do it correctly.) Brian >=20 > In any case, I am happy to concede it could be an extreme case and that= it is not necessary anymore in IPv6 for the great majority of use cases.= >=20 > I was not really making a specific case for IPv6 - my opposition was to= the concept that NAT is not security, and to the fact that it should be = written as such in the RFC. NAT *does* provide a form of security - the = fact that it is not desirable or it is unnecessary to use is another topi= c, in which I believe we all agree (at least for 99% of use cases ;-)) >=20 >=20 > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini >=20 > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 >=20 > ResMed Germany Inc >=20 >=20 >=20 > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com]=20 > Sent: Thursday, June 16, 2016 11:43 AM > To: Marco Ermini > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6netw= orks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debr= n-nva.de; v6ops@ietf.org > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16 June 2016 at 19:15, Marco Ermini wrote:= >> Well, actually, infrastructure hiding IS part of security. It is not = the full picture, but it is incorrect to say that it is not. >> >> I personally don't sympathize on NAT-haters. NAT has its reasons,=20 >> especially for carrier-grade NAT >=20 > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running = out of IPv4 addresses. >=20 > and especially in the telco scenario, and yes, it does provide some le= vel of security - again, not the complete picture, but it does. >> >=20 > NAT is not necessary in IPv6. The equivalent of NAT's perceived securit= y can be provided via alternative methods, as described in RFC4864. >=20 > A further technique to hide topology that isn't mentioned in RFC4864 is= to use something like ISATAP or similar, to create a single /64 subnet o= ver the top of multiple IPv4 subnets. Externally, all hosts will appear t= o belong to a single IPv6 subnet, hiding the internal topology. >=20 > If you truly want to hide the identities of hosts, NAT doesn't do enoug= h - it is only translating addresses, where as there are many other host = identifiers that the host itself supplies or will receive and supply that= can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted H= osts" > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field w= ithin the IPv4 header that leaked across a NAT was able to be used to ide= ntify hosts. >=20 > If you truly want to hide a host from the Internet, yet still allow it = to access things on the Internet, under IPv6 your network would use ULA a= ddressing, and have a per-application protocol proxy server that makes al= l requests look like they've entirely originated from the application pro= xy server itself. To the Internet server, the application proxy server wo= uld appear to be the application end host making the requests, preventing= any internal host identifiers or other attributes from leaking. >=20 >=20 > Regards, > Mark. >=20 >=20 >> >> Regards, >> >> Marco Ermini >> >> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D=20 >> +49 (0)899 901 1523 M +49 (0)175 439 5642 >> >> ResMed Germany Inc >> >> >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E=20 >> Carpenter >> Sent: Thursday, June 16, 2016 1:45 AM >> To: Erik Kline; Eric Vyncke (evyncke) >> Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; = >> draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org >> Subject: Re: [OPSEC] [v6ops] Asking for a review of=20 >> draft-ietf-opsec-v6-08 >> >> On 16/06/2016 07:45, Erik Kline wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be=20 >>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I have strong sympathy with that statement, but I don't think this is = the document to do it; the point is made in RFC4864 too. What we should d= o here is underline that NAT !=3D security. >> >> While I'm here, some other points: >> >> "2.2. Extension Headers >> >> TBD, a short section referring to all Fernando's I-D & RFC." >> >> That's not the whole story ;-). Firstly, RFC 7045 has a lot of=20 >> relevance to security aspects. Second, there is no reason to refer to = >> most of the material (Fernando's or not) unless it's directly relevant= =20 >> to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,= >> but only if that document is going anywhere. >> >> "2.3.3. ND/RA Rate Limiting >> ... >> The following drafts are actively discussing methods to >> rate limit RAs and other ND messages on wifi networks in order to >> address this issue: >> >> o [I-D.thubert-savi-ra-throttler] >> >> o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >> >> Neither of those drafts is in the least active (from 2012 and 2015 res= pectively). Dead drafts are of no help to the reader, IMHO. >> >> "4.2. Transition Mechanism >> >> SP will typically use transition mechanisms such as 6rd, 6PE, MAP, >> DS-Lite which have been analyzed in the transition Section 2.7.2 >> section." >> >> Shouldn't you add RFC6877 464XLAT now? >> >> Finally, I think there should be a Privacy Considerations section. >> >> Rgds >> Brian >> >>> >>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We= =20 >>> should, in my opinion, make it painfully clear that DHCP (of any >>> protocol) in the absence of link-layer security/auditability features= =20 >>> does not provide any satisfactory way "to ensure audibility and=20 >>> traceability" [Section 2.1.6]. >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 16 19:12:14 2016 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 1B06E12D924 for ; Thu, 16 Jun 2016 19:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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=-1.426, 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 0E4Td5C3DsWG for ; Thu, 16 Jun 2016 19:12:11 -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 62E4512DBF1 for ; Thu, 16 Jun 2016 19:12:11 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id n127so66511062iof.3 for ; Thu, 16 Jun 2016 19:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F55m/HLDOKD3NVKGrkeTL+aBiT0k1zDA7h6eJsCzxUA=; b=ozdm0+s0hMkh+EK/aBd3osiBX5kj1lUL+0v5JqcGCmuofAyZjn6HQdHm9EOW92H/Nl Z0co7W3KueEsUvJI3ZJEA1zJCrlhu1OCxceLrAKhUoRH19nxdG3Ewhn/DPPcyzVXU/cr gB0m9oI7sjvtGuSdhtnHcGC74XrgODXtlzeL7ad5YHcARCcuTuZ/FWqQR8bkKw4+pw4x pWOs4LeBF8v0I6UJ45ISc0pTaQIPeAs4936r2oKU899dB+5Hcq8emFwaY4OHjjVOvmQ9 CxNZkPA6BFnUcpdK8LchXcybZt/h4hTr1GC8mZ4gtMWzDL3ZFo1sBhNVtGZHhlF98QYe BesA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F55m/HLDOKD3NVKGrkeTL+aBiT0k1zDA7h6eJsCzxUA=; b=msUJ9nB3djV3cB3V1IlXeInA8yQN6UlZNXzJmpK3UdkqlTntYeHbCb7JSniKA1wBaE BxqThTgmpbs8AW3MRF1jwewz9rQ0PQMR6DtknXlfVI4DVKHfHGi1P5yF9fnmttNivkRk ibQy0FbQOsUYPw80FaB3LKYhLwrJ0JEMoqgHgesirkHYzrdnvkIT/3b6ie5dpFvtaL9Q mI3eD7VaCYa5UcCbufGCApear7EEqXBAAWhokgEkUQ73hWd5GrJ0a0psbN7WC6qw1hiZ xLlb/+obafB7hy4to2dd+jbNriy8Etyivyv630N/Ce+1+yZKh5OlJTMtdMwii6gMcWzv 9fpw== X-Gm-Message-State: ALyK8tL4dTT+MgKP4Y4SC0D4xElZOmjim+DoWIEbQYmdBGlL2gyD7MqsVjnw9e/lLsYC/PA56ci3dvWcCbYAUMcw X-Received: by 10.107.14.140 with SMTP id 134mr7624410ioo.94.1466129530574; Thu, 16 Jun 2016 19:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.225.228 with HTTP; Thu, 16 Jun 2016 19:11:50 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 16 Jun 2016 19:11:50 -0700 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a113fef80ddd36805356fe1f1 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 02:12:13 -0000 --001a113fef80ddd36805356fe1f1 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 12:45 PM, 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. > +1. I recall long queues at the mike at IETF 94 saying that. > Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > should, in my opinion, make it painfully clear that DHCP (of any > protocol) in the absence of link-layer security/auditability features > does not provide any satisfactory way "to ensure audibility and > traceability" [Section 2.1.6]. +1. Instead of the text you have here, I would suggest citing section 9.1 of draft-ietf-v6ops-host-addr-availability, which deals with the problem in detail. --001a113fef80ddd36805356fe1f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 15, 2016 at 12:45 PM, Erik Kline <ek@google.com> wrote:
Section 2.1.2 is far too permissive for = my tastes.=C2=A0 We need to be able
to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

+1. I recall long queues at the mike at IETF 94 saying th= at.
=C2=A0
Section 2.6.1.5 could punch up the SAVI stuff a bit more as well.=C2=A0 We=
should, in my opinion, make it painfully clear that DHCP (of any
protocol) in the absence of link-layer security/auditability features
does not provide any satisfactory way "to ensure audibility and
traceability" [Section 2.1.6].

+1. Ins= tead of the text you have here, I would suggest citing section 9.1 of=C2=A0= draft-ietf-v6ops-host-addr-availability, which deals with the problem in de= tail.
--001a113fef80ddd36805356fe1f1-- From nobody Fri Jun 17 04:29:19 2016 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 2CB5712D1D1; Fri, 17 Jun 2016 04:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 HIJeb1wE1E3n; Fri, 17 Jun 2016 04:29:11 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.249]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC912D19B; Fri, 17 Jun 2016 04:29:10 -0700 (PDT) Received: from [85.158.143.99] by server-2.bemta-6.messagelabs.com id E3/6F-11548-50FD3675; Fri, 17 Jun 2016 11:29:09 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRWlGSWpSXmKPExsVy+JUily7z/eR wgy9bhCye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y9vL7UwFH3Ur9q6dwNzA uES3i5GLQ0hgPaNE14QNjBDOHkaJs6dvMXcxcnKwCehI/F++ix3EFhGolZhy/A8zSBGzwBdGi WNzVjF1MXJwCAt4SVzs9Iao8ZZoePubFcL2k9h3chULiM0ioCrR/OATWJxXwFni7ue/bBDLJj JJfN+8jQ0kwSlgK/H31kywZYwCshJfGleDHcEsIC5x68l8JhBbQkBAYsme88wQtqjEy8f/WCF sRYnLv6ewgNzDLKApsX6XPkSrosSU7ofsEHsFJU7OfAJ2j5CAikT7gmVQrcESs7/dYJrAKDYL ybZZCJNmIZk0C8mkBYwsqxjVi1OLylKLdA31kooy0zNKchMzc3QNDcz0clOLixPTU3MSk4r1k vNzNzECI4sBCHYw7nzudIhRkoNJSZR37rnkcCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvHfvAu UEi1LTUyvSMnOAMQ6TluDgURLhnQWS5i0uSMwtzkyHSJ1itOS4s/jGWiaOW88eAMlPEw4cYxJ iycvPS5US5z0D0iAA0pBRmgc3DpaGLjHKSgnzMgIdKMRTkFqUm1mCKv+KUZyDUUmYdzHIFJ7M vBK4ra+ADmICOkhzHthBJYkIKakGRtaYr4fiPrRpfePo2/k6+JlTxCI52yKBYw8OcBqvzLG3m 3zbTCjQ6BPf7vc5oSzcF07NYgnf8I7508XAGfec9YW/bj1vu2iaHPOr4+dO+c+SZnb/wnNF0u 3ie6Y+Lnml3HerRD5X7HFs/vDyGtfU3S9Ovn59pGL7Xe7mQw5zbibM//XT3MlPr1eJpTgj0VC Luag4EQA6weCAPgMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1466162947!11271579!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27432 invoked from network); 17 Jun 2016 11:29:07 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-8.tower-216.messagelabs.com with SMTP; 17 Jun 2016 11:29:07 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 13:29:06 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%16]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 13:29:08 +0200 From: Marco Ermini To: Brian E Carpenter , Erik Kline , "Eric Vyncke (evyncke)" Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qzYSAgABC14CAAMBooIAA8f0AgADFp2A= Date: Fri, 17 Jun 2016 11:29:05 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 11:29:06.0849 (UTC) FILETIME=[758AB910:01D1C88B] Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:29:13 -0000 SSBhbSBzb3JyeSBCcmlhbiwgSSBkb24ndCB0aGluayB5b3UgdW5kZXJzdG9vZCBteSBhcmd1bWVu dC4gIEkgYW0gbm90IGFyZ3VpbmcgYWJvdXQgeW91IG1lbnRpb24uICBJIGFtIGFyZ3VpbmcgYWdh aW5zdCB0aGUgc2VtYW50aWMgb2YgYSBwaHJhc2UgdGhhdCBzYXlzICJOQVQgZG9lcyBub3QgcHJv dmlkZSBzZWN1cml0eSIuICBUaGlzIHNlbnRlbmNlIGlzIHNlbWFudGljYWxseSB3cm9uZywgYW5k IHVzdWFsbHkgY29tZXMgZnJvbSBhIHByaW9yaSBOQVQtaGF0ZXJzIChJIGhhdmUgbWV0IGEgZmV3 KS4NCg0KSSBhbSBvbmx5IGFnYWluc3Qgc3RhdGluZyBzdWNoIHNlbnRlbmNlIGluIHRoZSBSRkMs IG5vdCBhZ2FpbnN0IHRoZSBmYWN0IHRoYXQgd2UgZG9uJ3QgbmVlZCBOQVQuICBJIGhvcGUgdGhp cyBpcyBjbGVhcmVyIG5vdy4NCg0KQW55d2F5LCBJIGhhdmUgbWFkZSBteSBwb2ludCBzdWZmaWNp ZW50bHksIEkgYmVsaWV2ZS4NCg0KDQpSZWdhcmRzLA0KTWFyY28uDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgMzo0MCBBTQ0K VG86IE1hcmNvIEVybWluaTsgRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQpDYzog ZmdvbnRAc2k2bmV0d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJu LW52YS5kZTsgZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1p ZXRmLW9wc2VjLXY2LTA4DQoNCk9uIDE2LzA2LzIwMTYgMjE6MTUsIE1hcmNvIEVybWluaSB3cm90 ZToNCj4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNl Y3VyaXR5LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3Qg dG8gc2F5IHRoYXQgaXQgaXMgbm90Lg0KDQpIYXZlIHlvdSByZWFkIFJGQzQ4NjQgcmVjZW50bHk/ IFNlY3Rpb24gNC40IGlzIGFsbCBhYm91dCBob3cgeW91IGRvbid0IG5lZWQgTkFUIHRvIGhpZGUg aW5mcmFzdHJ1Y3R1cmUgdG9wb2xvZ3kgaW4gSVB2Ni4NCg0KPiBJIHBlcnNvbmFsbHkgZG9uJ3Qg c3ltcGF0aGl6ZSBvbiBOQVQtaGF0ZXJzLiAgTkFUIGhhcyBpdHMgcmVhc29ucywgZXNwZWNpYWxs eSBmb3IgY2Fycmllci1ncmFkZSBOQVQgYW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5h cmlvLCBhbmQgeWVzLCBpdCBkb2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFn YWluLCBub3QgdGhlIGNvbXBsZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLg0KDQpUaGF0J3MgSVB2 NC4gVGhpcyBpcyBJUHY2Lg0KDQogICAgQnJpYW4NCg0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IOKA i+KAi+KAi+KAi+KAiw0KPiBNYXJjbyBFcm1pbmkNCj4gDQo+IENJU1NQLCBDSVNBLCBDSVNNLCBD RUgsIElUSUwsIE1DUCwgUGhEIFNlbmlvciBJVCBTZWN1cml0eSBBbmFseXN0IEQgDQo+ICs0OSAo MCk4OTkgOTAxIDE1MjMgIE0gKzQ5ICgwKTE3NSA0MzkgNTY0Mg0KPiANCj4gUmVzTWVkIEdlcm1h bnkgSW5jDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT1BT RUMgW21haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSAN Cj4gQ2FycGVudGVyDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDE6NDUgQU0NCj4g VG86IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKQ0KPiBDYzogZmdvbnRAc2k2bmV0 d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgDQo+ IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZiANCj4gZHJhZnQtaWV0 Zi1vcHNlYy12Ni0wOA0KPiANCj4gT24gMTYvMDYvMjAxNiAwNzo0NSwgRXJpayBLbGluZSB3cm90 ZToNCj4+IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZlIGZvciBteSB0YXN0ZXMu ICBXZSBuZWVkIHRvIGJlIA0KPj4gYWJsZSB0byBzYXkgdGhhdCBVTEErSVB2NiBOQVQgaXMgTk9U IFJFQ09NTUVOREVEIGJ5IHRoZSBJRVRGLg0KPiANCj4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3 aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVu dCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUgaW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hv dWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQgTkFUICE9IHNlY3VyaXR5Lg0KPiANCj4gV2hp bGUgSSdtIGhlcmUsIHNvbWUgb3RoZXIgcG9pbnRzOg0KPiANCj4gIjIuMi4gIEV4dGVuc2lvbiBI ZWFkZXJzDQo+IA0KPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZl cm5hbmRvJ3MgSS1EICYgUkZDLiINCj4gDQo+IFRoYXQncyBub3QgdGhlIHdob2xlIHN0b3J5IDst KS4gRmlyc3RseSwgUkZDIDcwNDUgaGFzIGEgbG90IG9mIA0KPiByZWxldmFuY2UgdG8gc2VjdXJp dHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVyZSBpcyBubyByZWFzb24gdG8gcmVmZXIgdG8gDQo+IG1v c3Qgb2YgdGhlIG1hdGVyaWFsIChGZXJuYW5kbydzIG9yIG5vdCkgdW5sZXNzIGl0J3MgZGlyZWN0 bHkgcmVsZXZhbnQgDQo+IHRvIG9wc2VjLiBJIHRoaW5rIHRoZSByZWZlcmVuY2UgaXMgZHJhZnQt aWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZywNCj4gYnV0IG9ubHkgaWYgdGhhdCBkb2N1bWVu dCBpcyBnb2luZyBhbnl3aGVyZS4NCj4gDQo+ICIyLjMuMy4gIE5EL1JBIFJhdGUgTGltaXRpbmcN Cj4gLi4uDQo+ICAgIFRoZSBmb2xsb3dpbmcgZHJhZnRzIGFyZSBhY3RpdmVseSBkaXNjdXNzaW5n IG1ldGhvZHMgdG8NCj4gICAgcmF0ZSBsaW1pdCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9u IHdpZmkgbmV0d29ya3MgaW4gb3JkZXIgdG8NCj4gICAgYWRkcmVzcyB0aGlzIGlzc3VlOg0KPiAN Cj4gICAgbyAgW0ktRC50aHViZXJ0LXNhdmktcmEtdGhyb3R0bGVyXQ0KPiANCj4gICAgbyAgW0kt RC5jaGFrcmFiYXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQo+IA0KPiBOZWl0aGVy IG9mIHRob3NlIGRyYWZ0cyBpcyBpbiB0aGUgbGVhc3QgYWN0aXZlIChmcm9tIDIwMTIgYW5kIDIw MTUgcmVzcGVjdGl2ZWx5KS4gRGVhZCBkcmFmdHMgYXJlIG9mIG5vIGhlbHAgdG8gdGhlIHJlYWRl ciwgSU1ITy4NCj4gDQo+ICI0LjIuICBUcmFuc2l0aW9uIE1lY2hhbmlzbQ0KPiANCj4gICAgU1Ag d2lsbCB0eXBpY2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBF LCBNQVAsDQo+ICAgIERTLUxpdGUgd2hpY2ggaGF2ZSBiZWVuIGFuYWx5emVkIGluIHRoZSB0cmFu c2l0aW9uIFNlY3Rpb24gMi43LjINCj4gICAgc2VjdGlvbi4iDQo+IA0KPiBTaG91bGRuJ3QgeW91 IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiANCj4gRmluYWxseSwgSSB0aGluayB0aGVyZSBz aG91bGQgYmUgYSBQcml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+IA0KPiBSZ2RzDQo+ ICAgICBCcmlhbg0KPiANCj4+DQo+PiBTZWN0aW9uIDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhl IFNBVkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxsLiAgV2UgDQo+PiBzaG91bGQsIGluIG15IG9w aW5pb24sIG1ha2UgaXQgcGFpbmZ1bGx5IGNsZWFyIHRoYXQgREhDUCAob2YgYW55DQo+PiBwcm90 b2NvbCkgaW4gdGhlIGFic2VuY2Ugb2YgbGluay1sYXllciBzZWN1cml0eS9hdWRpdGFiaWxpdHkg ZmVhdHVyZXMgDQo+PiBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBl bnN1cmUgYXVkaWJpbGl0eSBhbmQgDQo+PiB0cmFjZWFiaWxpdHkiIFtTZWN0aW9uIDIuMS42XS4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9QU0VDIG1haWxpbmcgbGlzdA0K PiBPUFNFQ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29wc2VjDQo+IA0KDQo= From nobody Fri Jun 17 04:47:38 2016 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 C18D912B016 for ; Fri, 17 Jun 2016 04:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 FVSDL-P0SmPI for ; Fri, 17 Jun 2016 04:47:35 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1733212D533 for ; Fri, 17 Jun 2016 04:47:34 -0700 (PDT) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AF18B61C9B for ; Fri, 17 Jun 2016 13:47:32 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 56AAD60878; Fri, 17 Jun 2016 13:47:32 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 44FA6345F4; Fri, 17 Jun 2016 13:47:32 +0200 (CEST) Date: Fri, 17 Jun 2016 13:47:32 +0200 From: Gert Doering To: Marco Ermini Message-ID: <20160617114732.GK79185@Space.Net> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , Mark Smith , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:47:37 -0000 Hi, On Thu, Jun 16, 2016 at 10:03:25AM +0000, Marco Ermini wrote: > NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently. Unfortunately RFC 4864 does not mention such case, AFAIK. Why would anyone route their IPv6 traffic to the IPv4 CGN box? CGN boxes are way expensive, so anyone with a calculator would route everything that does not need NAT around the CGN box. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Jun 17 06:12:29 2016 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 E87CE12D1E7; Fri, 17 Jun 2016 06:12:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 ZmEddaosXvAl; Fri, 17 Jun 2016 06:12:14 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) by ietfa.amsl.com (Postfix) with ESMTP id 634F512D52B; Fri, 17 Jun 2016 06:12:13 -0700 (PDT) Received: from [85.158.136.227] by server-11.bemta-5.messagelabs.com id 56/75-04210-C27F3675; Fri, 17 Jun 2016 13:12:12 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRWlGSWpSXmKPExsVy+JUil67W9+R wg4kfLSye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1493ZG0wFDyaxVvRc+s3U wNjdxdrFyMkhJLCeUeLaFIMuRi4gew+jxIRt08ESbAI6Ev+X72LvYuTgEBFQl/jYxwhSwyzwg Uli5oFOJpAaYQEvif17W5lBbBEBb4mtNzYzQthOEsuaDoDVsAioSvx+dwHM5hVwltjU8Z4NYt lLFom5a5aCJTgFAiXWX73NAmIzCshKfGlcDTaUWUBc4taT+WA1EgICEkv2nGeGsEUlXj7+xwp hK0pc/j2FBaI+W+LljfVsEMsEJU7OfMIC8aWKRPuCZVD1wRIt27exTmAUnYVkxSwk7bOQtM8C +p9ZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2JUL04tKkst0rXQSyrKTM8oyU3MzNE1N DDVy00tLk5MT81JTCrWS87P3cQIjEYGINjBeLDZ+RCjJAeTkijv3HPJ4UJ8SfkplRmJxRnxRa U5qcWHGGU4OJQkeC99BcoJFqWmp1akZeYA0wJMWoKDR0mE9wxImre4IDG3ODMdInWK0Z5jweI ba5k4roHJO2Dy04QDx5iEWPLy81KlxHlPgbQJgLRllObBDYWlsUuMslLCvIxAZwrxFKQW5WaW oMq/YhTnYFQS5r0LMoUnM68EbvcroLOYgM7SnAd2VkkiQkqqgdH3M9vsDY3ak/MXng8Pli+97 a+9aqvrc03pWhb9gAcLDc/oFl9qC853juh5PyMpr9bjw8eeGVoFs/zOGcycqaDAwPC+8UFxvd f3LxPnzXhoXD2HfXFs1CHeiEQd2d2eQdV8y0Uc5XsbeTbdOdIXyJspJ3qJpdHCXsvb8L5AQOl Pv7AFIlW7lViKMxINtZiLihMBxAtStV4DAAA= X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-3.tower-162.messagelabs.com!1466169130!10883781!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5877 invoked from network); 17 Jun 2016 13:12:10 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-3.tower-162.messagelabs.com with SMTP; 17 Jun 2016 13:12:10 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 15:12:10 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 15:12:10 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx8kDZDWt19w1D06Dzoga8sHTvZ/sGD1ggACTCYCAAN1lEA== Date: Fri, 17 Jun 2016 13:12:09 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: multipart/alternative; boundary="_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 13:12:10.0364 (UTC) FILETIME=[DB343BC0:01D1C899] Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" , Erik Kline , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:12:19 -0000 --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBzb3JyeSwgSSBzdXJyZW5kZXIgdGhlIE91dGxvb2sgb24gdGhlIHRoaXJkIGluZGVudA0K DQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NClNlbnQ6 IEZyaWRheSwgSnVuZSAxNywgMjAxNiAyOjIxIEFNDQpUbzogTWFyY28gRXJtaW5pDQpDYzogRXJp YyBWeW5ja2UgKGV2eW5ja2UpOyBkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnOyBFcmlrIEts aW5lOyB2Nm9wc0BpZXRmLm9yZzsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1kZWJybi1u dmEuZGU7IGZnb250QHNpNm5ldHdvcmtzLmNvbTsgQnJpYW4gRSBDYXJwZW50ZXINClN1YmplY3Q6 IFJFOiBbdjZvcHNdIFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1pZXRmLW9w c2VjLXY2LTA4DQoNCg0KT24gMTcgSnVuIDIwMTYgMDA6MTUsICJNYXJjbyBFcm1pbmkiIDxNYXJj by5Fcm1pbmlAcmVzbWVkLmNvbTxtYWlsdG86TWFyY28uRXJtaW5pQHJlc21lZC5jb20+PiB3cm90 ZToNCj4NCj4gSSdsbCB0cnkgdGhlIGhvcnJpYmxlIE91dGxvb2sgdG8gcmVwbHkgdXNpbmcgdGV4 dCwgcGxlYXNlIGJlZyBteSBwYXJkb24gaWYgdGhpcyBpcyBub3QgZm9ybWF0dGVkIHByb3Blcmx5 Lg0KPg0KPiBPbiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBNLCBNYXJrIFNtaXRoIFtt YWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbTxtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNv bT5dIHdyb3RlOg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gTkFUIGNhbiBiZSBzdGlsbCBuZWNlc3Nh cnkgaW4gSVB2NiBpbiBkdWFsLXN0YWNrIHNjZW5hcmlvLCBmb3IgaW5zdGFuY2UsIHdoZXJlIGV2 ZXJ5IGhvc3QgaXMgYXNzaWduZWQgYm90aCBhIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzIGFuZCB0 aGUNCj4gPj4gQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUgdGhlbSBkaWZmZXJlbnRseS4NCj4g PkNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2aWNlLg0K Pg0KPiBJIHdvdWxkIHByZWZlciBub3QgdG8gbWFrZSBuYW1lcywgYnV0IHlvdSB3b3VsZCBiZSB1 bnBsZWFzYW50bHkgc3VycHJpc2VkLg0KDQpJJ20gc2NlcHRpY2FsLCBJIGFuZCBJIHRoaW5rIG90 aGVycyB3b3VsZCB3YW50IGEgY29uY3JldGUgZXhhbXBsZS4NCg0KW01hcmNvIEVybWluaV0NCg0K SSBhbSBzb3JyeSwgSSBhbSBub3QgYXV0aG9yaXNlZCB0byBkbyB0aGF0IHB1YmxpY2FsbHkuICBC dXQgdGhpcyBpcyBub3QgbmVjZXNzYXJ5IGFueXdheS4gIFRoZXJlIGlzIG5vIG5lZWQgdG8gbGlz dCBldmVyeXRoaW5nIHRoYXQgd29ya3Mgd3JvbmcsIHRvIGRlZmluZSB3aGF0IHRoZSBjb3JyZWN0 IGJlaGF2aW91ciBzaG91bGQgYmUuDQoNCklmIHBlb3BsZSBhcmVuJ3QgaW1wbGVtZW50aW5nIHNw ZWNpZmljYXRpb25zIHdlbGwsIHdlIG5lZWQgdG8ga25vdywgc28gdGhhdCBpZiBuZWNlc3Nhcnkg dGhlIHNwZWNpZmljYXRpb25zIGNhbiBiZSBpbXByb3ZlZC4NCg0KW01hcmNvIEVybWluaV0NCg0K VGhpcyBpcyB3aHkgd2UgaGF2ZSBkcmFmdC1nb250LW9wc2VjLWlwdjYtZmlyZXdhbGwtcmVxcy0w My50eHQuDQoNCiAgQW55d2F5LCBpdCBpcyBhbHNvIG5vdCBqdXN0IGEgbWF0dGVyIG9mIG5vdCBi ZWluZyBhYmxlIHRvIGNvbmZpZ3VyZSB0aGVtIGluIGEgY2VydGFpbiB3YXkgKHdoaWNoIGlzIHBv c3NpYmx5IHRoZSBjYXNlKSwgYnV0IGFsc28gdGhlIGNhc2UgaW4gd2hpY2ggdGhleSBkb24ndCB3 b3JrIHByb3Blcmx5Lg0KPg0KPiA+IElQdjQgYW5kIElQdjYgaGF2ZSB0byBiZSBoYW5kbGVkIGRp ZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xzLCByZXF1aXJpbmcg ZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZQ0KPiA+IHBlcmZvcm1pbmcg TkFUIG9uIElQdjQgdHJhZmZpYyBpdCByZWNlaXZlcyBhbmQgZG9pbmcgc3RhbmRhcmQgc3RhdGVs ZXNzIGZvcndhcmRpbmcgb2YgSVB2NiB0cmFmZmljLiBJcyB0aGF0IHRoZSBzY2VuYXJpbyB5b3Un cmUgZGVzY3JpYmluZz8NCj4NCj4gWWVzLCBmb3IgaW5zdGFuY2UuDQoNCk9LLCBzbyAiQ0dOIiBp cyBub3QgYmVpbmcgcGVyZm9ybWVkIG9uIElQdjYgdHJhZmZpYy4NCg0KW01hcmNvIEVybWluaV0N Cg0KU29ydCBvZiBDRyBlcXVpcG1lbnQgd2lsbCBiZSBhbnl3YXkgaW4gdGhlIHdheSBhbHNvIGZv ciBkdWFsLXN0YWNrIHJlc2lkZW50aWFsIGNvbm5lY3Rpb25zLCBhbmQgQ0dOIGlzIHN0aWxsIHVz ZWQgb24gcHVyZSBJUHY2IGltcGxlbWVudGF0aW9ucyBhcyB5b3UgbmVlZCB0byBvZmZlciBjb25u ZWN0aXZpdHkgdG8gSVB2NC1vbmx5IGhvc3RzLg0KDQo+T3IsIHRoZXkgaGFuZGxlIGNlcnRhaW4g ZnVuY3Rpb25zIChlLmcuIE5BVCkgcHVyZWx5IGluIHRoZSBkYXRhIHBsYW5lIGFzIHRoZXkgYXJl IGxvZ2ljYWxseSBzaW1wbGUgdG8gYmUgaW1wbGVtZW50ZWQgaW4gZmlybXdhcmUsIHdoaWxlIG1v cmUgY29tcGxleCBmdW5jdGlvbnMgKGxpa2UgaW1wbGVtZW50aW5nIFVMQSBhZGRyZXNzZXMgdHJh bnNsYXRpb24pIHJlcXVpcmVzIHJvdXRpbmUgZW5naW5lcyB0byBiZSBpbnZvbHZlZCwgdGhlcmVm b3JlIGludm9sdmluZyBkaWZmZXJlbnQgbGF0ZW5jeSBmb3IgZXhlY3V0aW9uLg0KPg0KDQpTbyB0 aGlzIHNvdW5kcyBsaWtlIGVxdWlwbWVudCBoZXJlIGFkZGl0aW9uYWwgZmVhdHVyZXMgY2Fubm90 IGJlIGltcGxlbWVudGVkIGluIGhhcmR3YXJlLCBzbyBpdCBpcyBpbXBsZW1lbnRlZCBpbiBjb250 cm9sIHBsYW5lIHNvZnR3YXJlLg0KDQpUaGlzIGlzIGFuIGV4YW1wbGUgb2Ygd2h5IG5vdCB0byB1 c2UgTkFULiBJdCBpcyB0ZWNobmljYWxseSB2ZXJ5IGNvbXBsZXggY29tcGFyZWQgdG8gcHVyZSBJ UHY0IGFuZCBwdXJlIElQdjYgZm9yd2FyZGluZy4NCg0KW01hcmNvIEVybWluaV0NCg0KSSBkbyBh Z3JlZSB3aXRoIHlvdS4NCg0KSSdtIHN0YXJ0aW5nIHRvIHdvbmRlciBpZiBwZW9wbGUgdGhpbmsg dGhhdCBpZiB0aGV5IHdhbnQgdG8gdXNlIFVMQXMgZm9yIHNvbWUgcmVhc29uLCB0aGV5IHRoaW5r IHRoZXkgdGhlbiBtdXN0IE5BVCB0aGVtLiBJZiB0aGV5IGRvLCBJIHRoaW5rIHRoYXQgbWlnaHQg c2hvdyBhIG1pc3VuZGVyc3RhbmRpbmcgb2Ygc29tZXRoaW5nIGZ1bmRhbWVudGFsIGFib3V0IElQ djYgLSBhIGhvc3QgbmF0aXZlbHkgc3VwcG9ydHMgbXVsdGlwbGUgY29uY3VycmVudCBhZGRyZXNz ZXMgd2l0aCBkaWZmZXJlbnQgc2NvcGVzLCBhbmQgdHJpZXMgdG8gY2hvb3NlIG9uZSBvZiBpdHMg c291cmNlIGFkZHJlc3MgdG8gbWF0Y2ggdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MuDQoNCltNYXJj byBFcm1pbmldDQoNCkkgY2FuIHJlYWxseSBzZWUgeW91ciBwb2ludCBoZXJlLiAgSXQgbWF5IHdl bGwgYmUgdGhhdCDigJxwZW9wbGXigJ0gY2FuIG1pc3VuZGVyc3RhbmQgSVB2Ni4gIERlc3BpdGUg aXRzIGV4aXN0ZW5jZSBzaW5jZSBhIGRlY2FkZSwgaXQgaXMgbm90IHdpZGVseSBhZG9wdGVkIG91 dHNpZGUgb2YgY2VydGFpbiBBc2lhbiBjb3VudHJpZXMuDQoNCj4gSXQgaXMgcHJldHR5IGNvbW1v biB0aGF0IGN1c3RvbWVycyB3aXRoIElTUHMgb2ZmZXJpbmcgZHVhbCBzdGFjaywgdG8gZXhwZXJp ZW5jZSBhIGhpZ2hlciBsYXRlbmN5IGZvciB0aGVpciBjb25uZWN0aW9uIG9uY2UgdGhleSBpbXBs ZW1lbnQgSVB2NiBhbG9uZyB3aXRoIElQdjQuICAgVGhpcyBkb2VzIG5vdCBhcHBseSB3aGVuIG9u bHkgSVB2NCBvciBvbmx5IElQdjYgYXJlIHVzZWQuDQo+DQoNCkknZCBsaWtlIHNvbWUgZXhhbXBs ZXMgb2YgdGhpcy4NCg0KSSd2ZSBiZWVuIG5hdGl2ZWx5IGR1YWwgc3RhY2tlZCBhdCBob21lIGZv ciB0aGUgcGFzdCBuZWFyIDUgeWVhcnMuIEkgaGF2ZSBub3QgZXhwZXJpZW5jZWQgYWRkaXRpb25h bCBhbmQgbm90aWNlYWJsZSBoaWdoZXIgbGF0ZW5jeSBmb3IgYW55dGhpbmcgSSBkby4gSXQganVz dCB3b3JrcywgYW5kIEkgY2FuJ3QgdGVsbCB3aGF0IGlzIGdvaW5nIG92ZXIgSVB2NCBvciBJUHY2 IC0gYW5kIEkga25vdyB0aGF0IG1vc3QgaWYgbm90IGFsbCBHb29nbGUsIEZhY2Vib29rIGFuZCBO ZXRmbGl4IHRyYWZmaWMgY2FuIGFuZCBkb2VzIGNvbWUgb3ZlciBJUHY2Lg0KDQpbTWFyY28gRXJt aW5pXQ0KDQpZb3UgYXJlIGx1Y2t5LiAgQWdhaW4sIEkgY2Fubm90IG1ha2UgbmFtZXMsIGJ1dCB5 b3UgYXJlIG15IGd1ZXN0IGlmIHlvdSBjb21lIG5lYXIgTXVuaWNoIHNvbWV0aW1lcywgYW5kIEni gJlsbCBzaG93IHlvdSB0aGUgdHlwaWNhbCBFdXJvcGVhbiBkdWFsIHN0YWNrIGltcGxlbWVudGF0 aW9uLiDimLkNCg0KSSBhbHNvIHdvcmtlZCBpbiB0aGUgcmVzaWRlbnRpYWwgZGVwbG95bWVudCBv ZiBJUHY2IGF0IHRoZSBvdGhlciBlbmQgb2YgbXkgY29ubmVjdGlvbiBpbiAyMDA5LzIwMTAsIGFu ZCB3ZSBuZXZlciByZWNlaXZlZCBhbnkgSVB2NiBsYXRlbmN5IGNvbXBsYWludHMuIEluIDIwMTIg aXQgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBmb3IgbmV3IGN1c3RvbWVyIGNvbm5lY3Rpb25zLg0K DQpbTWFyY28gRXJtaW5pXQ0KDQpUaGVyZSBhcmUgSVNQcyBpbiBHZXJtYW55IHdoaWNoIG9mZmVy IGJ5IGRlZmF1bHQgSVB2NiwgYW5kIHJlcXVpcmVzIHRvIHBheSBhZGRpdGlvbmFsIGZlZXMgaWYg eW91IHdhbnQgSVB2NCAod2hpY2ggaXMgc29tZXRpbWVzIG5lY2Vzc2FyeSBpZiB5b3VyIGNvbXBh bnkgb25seSBpbXBsZW1lbnRzIElQdjQgYW5kIHlvdSBuZWVkIHRvIFZQTiBpbiwgYXMgQ0dOIGZy b20gSVB2NiB0byBJUHY0IGJyZWFrcyBtb3N0IFZQTiBwbGF0Zm9ybXMpLg0KDQpIb3dldmVyLCB0 aGUgRXVyb3BlYW4gb3BlcmF0b3JzIG9mZmVyaW5nIGR1YWwgc3RhY2sgYWxsIHN1ZmZlcnMgZnJv bSBsYXRlbmN5IGlzc3Vlcy4gIEl0IGNhbiBhbHNvIGJlIHBhcnRpYWxseSBkdWUgdG8gdGhlIGNs aWVudCBvcGVyYXRpdmUgc3lzdGVtIGFuZCBob3cgaXQgZGV0ZWN0cyB3aGljaCBpcyB0aGUgYmVz dCBwYXRoIHRvIHVzZSBmb3IgaG9zdHMgdGhhdCBvZmZlciBib3RoIGNvbm5lY3Rpdml0eS4NCg0K SSBoYXZlIGNvbWUgYWNyb3NzIHByZXNlbnRhdGlvbnMgb3ZlciB0aGUgcGFzdCB5ZWFycyB0aGF0 IGhhdmUgc2hvd24gdGhhdCBJUHY2IGhhcyByZWR1Y2VkIGxhdGVuY3kgZm9yIGR1YWwgc3RhY2sg c2VydmljZXMsIGJlY2F1c2UgdGhlIElQdjYgcGF0aCB3YXMgZGlmZmVyZW50IGFuZCBzaW1wbGVy IHRoYW4gdGhlIElQdjQgcGF0aC4NCg0KW01hcmNvIEVybWluaV0NCg0KQWdhaW4sIHRoYXQgaXMg aW4gdGhlIGlkZWFsIHdvcmxkLCBidXQgaXQgaXMgbm90IG15IGV4cGVyaWVuY2Ugd2l0aCBkaWZm ZXJlbnQgRXVyb3BlYW4gcmVzaWRlbnRpYWwgc2VydmljZSBwcm92aWRlcnMuDQoNCklQdjYgc2hv dWxkIGhhdmUgYmVlbiB0aGUgdWx0aW1hdGUgc29sdXRpb24gdG8gbWFueSBpc3N1ZXMsIGJ1dCBh cHBhcmVudGx5IGl0IGhhcyBub3QgYmVlbiB0aGF0IHNpbHZlciBidWxsZXQgdGhhdCBldmVyeW9u ZSB3YXMgaG9waW5nIGZvci4NCg0KPiBBbm90aGVyIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzcGVj aWZpYyBsb2dnaW5nIG9yIG1vbml0b3Jpbmcgc3lzdGVtIGlzIGltcGxlbWVudGVkIChlc3BlY2lh bGx5IGZvciBsZWdhbCByZXF1aXJlbWVudHMpLCBhbmQgdGhpcyBpcyBkb25lIHRocm91Z2ggbG9n Z2luZyBOQVQgdHJhbnNsYXRpb25zLiAgQW4gSVNQIGltcGxlbWVudGluZyBJUHY2IGFsb25nIHdp dGggSVB2NCB3b3VsZCBiZSBpbiB0aGF0IHNpdHVhdGlvbi4NCj4NCg0KTm8gbmVlZCB0byBkbyBf YWRkcmVzcyB0cmFuc2xhdGlvbl8gdG8gYmUgYWJsZSB0byBwZXJmb3JtIHRoYXQuDQoNCltNYXJj byBFcm1pbmldDQoNCk9mIGNvdXJzZSwgaWYgeW91IGhhdmUgdGhlIHBvc3NpYmlsaXR5LCB5b3Ug Y2FuIGFsd2F5cyBkbyB0aGluZ3MgZGlmZmVyZW50bHkgYW5kIGJldHRlci4NCg0KPiBMdWNraWx5 LCByb3V0ZXIgdmVuZG9ycyBhcmUgbW92aW5nIGF3YXkgZnJvbSB0aGUgYW50aXF1YXRlIGFyY2hp dGVjdHVyZSB3aGljaCBzZXBhcmF0ZXMgZGF0YSBhbmQgbWFuYWdlbWVudCBwbGFuZSwgZm9yIHZh cmlvdXMgcmVhc29ucy4NCj4NCg0KQWN0dWFsbHksIHRoYXQncyBnb2luZyB0byBpbmNyZWFzZSB0 aGUgY29zdCBvZiBlcXVpcG1lbnQsIGJlY2F1c2UgaXQgaXNuJ3QgZ29pbmcgdG8gYmUgY2hlYXAg dG8gZG8gc29tZXRoaW5nIGNvbXBsZXggZmFzdC4NCg0KW01hcmNvIEVybWluaV0NCg0KQXUgY29u dHJhaXJlLCBmb3IgZXF1aXBtZW50IHZlbmRvcnMsIG1vdmluZyBmcm9tIGhhdmluZyBoYXJkd2Fy ZSBhbmQgZGlmZmVyZW50IHBsYW5lcyB0byBtYW5hZ2UsIHRvIGEgc29mdHdhcmUtb25seSB2ZXJz aW9uIHdoaWNoIGNhbiBiZSBzaGlwcGVkIGFzIGJvdGggaGFyZHdhcmUgYW5kIHZpcnR1YWwgaW1h Z2UsIG1lYW5zIG5vdGFibGUgcmVkdWN0aW9uIG9mIGNvc3RzIGluIHRlcm1zIG9mIGRldmVsb3Bt ZW50LCBzdXBwb3J0LCBldGMuDQoNCkJ1dCBvZiBjb3Vyc2UgSSBjb25jZWRlIHRoZXJlIG1heSBi ZSBkaWZmZXJlbmNlcyBjYXNlIGJ5IGNhc2UuDQoNCg0KDQo+IFRoaXMgaXMgYWxzbyB3aHkgd2Ug cHVibGlzaGVkIGRyYWZ0LWdvbnQtb3BzZWMtaXB2Ni1maXJld2FsbC1yZXFzLTAzLnR4dCwgdG8g bWFrZSBpdCBleHBsaWNpdCB0aGF0IHRoaXMgc2hvdWxkIG5vdCBoYXBwZW4uDQo+DQo+IChJIGFt IGF3YXJlIHRoaXMgaXMgb2ZmLXRvcGljLCBqdXN0IG1ha2luZyBteSBwb2ludCA6LSkpDQo+DQo+ ID4+VW5mb3J0dW5hdGVseSBSRkMgNDg2NCBkb2VzIG5vdCBtZW50aW9uIHN1Y2ggY2FzZSwgQUZB SUsuDQo+ID4+DQo+ID4gSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29uY2VkZSBpdCBjb3Vs ZCBiZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSBhbnltb3Jl IGluIElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UNCj4gPiBjYXNlcy4NCj4NCj4g T2theQ0KPg0KPiA+PiBJIHdhcyBub3QgcmVhbGx5IG1ha2luZyBhIHNwZWNpZmljIGNhc2UgZm9y IElQdjYgLSBteSBvcHBvc2l0aW9uIHdhcyB0byB0aGUgY29uY2VwdCB0aGF0IE5BVCBpcyBub3Qg c2VjdXJpdHksIGFuZCB0byB0aGUgZmFjdCB0aGF0IGl0IHNob3VsZCBiZQ0KPiA+PiB3cml0dGVu IGFzIHN1Y2ggaW4gdGhlIFJGQy4NCj4gPiBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91dCBJ UHY2LiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhhdCBj YW4gYmUgYXBwbGllZCB0byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhlcnMN Cj4gPiB0aGF0IHNob3VsZG4ndCwgYW5kIG9wcG9ydHVuaXRpZXMgd2hlcmUgSVB2NiBjYW4gcHJv dmlkZSBiZXR0ZXIgc2VjdXJpdHkgdGhhdCBJUHY0IChlLmcuIHNwYXJzZSBob3N0IGFkZHJlc3Np bmcgaW4gYSAvNjQgbWFrZXMgYWRkcmVzcyBwcm9iaW5nDQo+ID4gdG8gZGlzY292ZXIgaG9zdHMg aW1wb3NzaWJsZSB3aXRoaW4gYSB1c2VmdWwgYW5kIHByYWN0aWNhbCB0aW1lZnJhbWUuKS4NCj4N Cj4gT2theSwgSSBoYXZlIG5vdGhpbmcgdG8gb2JqZWN0IG9uIHRoaXMuDQo+DQo+DQo+ID4+IE5B VCAqZG9lcyogcHJvdmlkZSBhIGZvcm0gb2Ygc2VjdXJpdHkNCj4gPldoYXQgc3BlY2lmaWMgc2Vj dXJpdHkgZG9lcyBpdCBwcm92aWRlIHRoYXQgaXMgZHVlIHRvIHRoZSBhZGRyZXNzIHRyYW5zbGF0 aW9uIGZ1bmN0aW9uPw0KPiA+IElmIHlvdSdyZSB0aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlv biBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJlaW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRy ZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQgc3RhdGUgY2FuIGJlDQo+ID4gY3JlYXRlZCB3 aXRob3V0IHBlcmZvcm1pbmcgYWRkcmVzcyB0cmFuc2xhdGlvbiwgd2hpY2ggaXMgd2hhdCBhIHN0 YXRlZnVsIGZpcmV3YWxsIGRvZXMgYW5kIGRpZCBpbiBJUHY0IGJlZm9yZSBOQVQgYmVjYW1lIHdp ZGVseSBkZXBsb3llZC4NCj4NCj4gSSB0b3RhbGx5IGFncmVlIHdpdGggeW91LiAgSSBhbSBhY3R1 YWxseSByZWZlcnJpbmcgdG8gdGhlIHBvc3NpYmlsaXR5IHRvIGhpZGUgdGhlIHN5c3RlbXMgYmVo aW5kIHRoZSBOQVR0ZWQgaW50ZXJmYWNlcyBvZiB0aGUgcm91dGVyL2ZpcmV3YWxsLCBub3QganVz dCB0aGVpciBhZGRyZXNzZXMgYnV0IGFsc28gcG9ydHMgYW5kIHNlcnZpY2VzLiAgSWYgeW91IG9u bHkgYXBwbHkgZmlsdGVyaW5nLCB5b3UgYXJlIHByb3RlY3RpbmcgLSBidXQgbm90IGhpZGluZy4N Cj4NCg0KTkFUIGlzIG5vIHdoZXJlIG5lYXIgYXMgZWZmZWN0aXZlIGF0IGhpZGluZyBzeXN0ZW1z IGFzIHBlb3BsZSB0aGluay4gVG9vIG1hbnkgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVtIGJlaGlu ZCB0aGUgTkFUIGxlYWsgYWNyb3NzIE5BVCwgb3IgY2FuIGJlIGZvcmNlZCB0byBsZWFrIGFjcm9z cyB0aGUgTkFULg0KDQpJdCBpcyBxdWl0ZSBhIHBvcm91cyBiYXJyaWVyLCBiZWNhdXNlIE5BVCBp cyBub3QgYWN0dWFsbHkgZGVzaWduZWQgdG8gaGlkZSBzeXN0ZW1zLiBBZGRyZXNzIHRyYW5zbGF0 aW9uIGluaGVyZW50bHkgaGlkZXMgc29tZSBvZiB0aGUgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVt cyAoYWRkcmVzc2VzKSBidXQgbm90IGFsbCBvZiB0aGVtLg0KDQpbTWFyY28gRXJtaW5pXQ0KDQpN b3N0IG9mIHRoZSBOQVQgdnVsbmVyYWJpbGl0aWVzIGNvbWUgZnJvbSBob21lIHJvdXRlcnMsIHdp dGggdGhlaXIgUG5QIGFuZCBvdGhlciBwcm90b2NvbHMgd2hpY2ggYXJlIG9mdGVuIGJhZGx5IGlt cGxlbWVudGVkLCBhcyB3ZWxsIGFzIHByb3RvY29scyB0aGF0IGRvIG5vdCBuZWNlc3NhcmlseSBw bGF5IHdlbGwgd2l0aCBOQVQuICBJZiBpdCBqdXN0IGhpZGVzIElQcyBhbmQgcG9ydHMsIHRoYXQg aXMgYWxyZWFkeSBkb2luZyBzb21ldGhpbmcuDQoNClBsZWFzZSBkbyBub3QgZ2V0IG1lIHdyb25n LiAgSSBhbSBhcyBtdWNoIGFzIGFueW9uZSBlbHNlIGhvcGluZyB0byBzZWUgdGhlIGRheSB0aGF0 IE5BVCBpcyByZWxlZ2F0ZWQgaW50byB0aGUgcGxhY2UgaW4gaGlzdG9yeSB3aGVyZSBpdCBzaG91 bGQgYmUuICBBbmQgSSBhbSAodW5mb3J0dW5hdGVseSkgd2VsbCBhd2FyZSB0aGF0IGFsbCBwcm90 b2NvbHMgd2hpY2ggbmVnb3RpYXRlIGFuIGhpZ2ggcG9ydCB0aHJvdWdoIGFuIGVuY3J5cHRlZCBj aGFubmVsIChGVFAtUywgb3IgY2VydGFpbiB2ZXJzaW9ucyBvZiBNaWNyb3NvZnQgQ29tbXVuaWNh dG9yL0x5bmMsIGNlcnRhaW4gVlBOLCBldGMuKSB3aWxsIG5ldmVyIHdvcmsgd2l0aCBhbnkgTkFU IChJIGVuc3VyZSB5b3UgSSBoYXZlIGxpdmVkIHRoYXQgb24gbXkgc2tpbikuDQoNCkF0IHRoZSBz YW1lIHRpbWUsIEkgY2Fubm90IG5lZ2xlY3QgdGhhdCBwcmFjdGljYWxseSBzcGVha2luZywgbXkg ZXhwZXJpZW5jZSB3aXRoIENHTiB3aXRoIElQdjQgaW4gdGVsY29zIGlzIHRoYXQgaXQgaXMgcXVp dGUgZWZmZWN0aXZlLiAgRmlyZXdhbGwgdmVuZG9ycyBoYXZlIHNwZW50IGEgZGVjYWRlIGZpeGlu ZyBpdCBhbmQgaW1wbGVtZW50aW5nIGV2ZXJ5IHNvcnQgb2YgdmFyaWFudCBzdWNoIGFzIE5BVC1U LCBOQVQtUE1QLCBOQVQgZm9yIFJQQywgZXRjLg0KDQo+IEluIGEgcGVyZmVjdCB3b3JsZCwgeW91 IGhhdmUgc3VjaCBnb29kIGZpbHRlcnMgdGhhdCB5b3UgY2FuIHRyYW5zcGFyZW50bHkgcHJvdmlk ZSB0aGUgcmVhbCBhZGRyZXNzZXMgYW5kIHBvcnRzIGZyb20gY2xpZW50cyB0byB0aGUgcmVzdCBv ZiB0aGUgSW50ZXJuZXQNCg0KSXQncyBzb3VuZGluZyBsaWtlIHlvdSdyZSBub3QgdXAgdG8gZGF0 ZSB3aXRoIElQdjYgZmlyZXdhbGxpbmcgY2FwYWJpbGl0aWVzIGluIGRldmljZXMsIGFuZCB0aGVy ZWZvcmUgbWlnaHQgYmUgYXNzdW1pbmcgdGhhdCBub25lIGV4aXN0Lg0KDQpBcmUgeW91IGF3YXJl IGZvciBleGFtcGxlIHRoYXQgV2luZG93cyBoYXMgaGFkIGEgc3RhdGVmdWwgSVB2NiBmaXJld2Fs bCwgZW5hYmxlZCBieSBkZWZhdWx0LCBzaW5jZSBXaW5kb3dzIFhQIHNlcnZpY2UgcGFjayAyLCBy ZWxlYXNlZCBtb3JlIHRoYW4gYSBkZWNhZGUgYWdvPw0KDQpJJ3ZlIGJlZW4gdXNpbmcgSVB2NiB1 bmRlciBMaW51eCB0byBhY2Nlc3MgdGhlIEludGVybmV0IGVpdGhlciB2aWEgdHVubmVscyBvciBu YXRpdmVseSBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlLCB1c2luZyB0aGUgc3RhdGVmdWwgSVB2NiBm aXJld2FsbCB0aGF0IGhhcyBiZWVuIHBhcnQgb2YgdGhlIExpbnV4IGtlcm5lbCBmb3IgYXQgbGVh c3QgdGhhdCBsb25nLg0KDQpUaGlzIEFuZHJvaWQgcGhvbmUgaGFzIG5hdGl2ZSBhbmQgcHVibGlj IElQdjYgYWRkcmVzc2VzIGFuZCBpcyBub3QgYmVoaW5kIGFueSBzb3J0IG9mIElQdjYgTkFULiBJ dCdzIGJlaGluZCBhIGRldmljZSB0aGF0IGNhbiBwZXJmb3JtIElQdjYgc3RhdGVmdWwgZmlyZXdh bGxpbmcsIGhvd2V2ZXIgSSB0aGluayBJJ3ZlIHR1cm5lZCBpdCBvZmYsIGJlY2F1c2UgSSB0cnVz dCB0aGF0IGFzIEdvb2dsZSBjYW4ndCB0cnVzdCB0aGVyZSBpcyBhIG5ldHdvcmsgZmlyZXdhbGwg dXBzdHJlYW0gb2YgbXkgcGhvbmUsIHRoZXkgZW5zdXJlIG15IHBob25lIGlzICJJbnRlcm5ldCBw cm9vZiIuDQoNClRoZSAicGVyZmVjdCIgd29ybGQgeW91J3JlIHJlZmVycmluZyB0byBpcyBhbmQg aGFzIGJlZW4gcmVhbGl0eSBmb3IgYSBsb25nIHRpbWUgZm9yIGEgbG90IG9mIHBlb3BsZS4NCg0K W01hcmNvIEVybWluaV0NCg0KSSBhbSBzb3JyeSwgSSBkbyBub3QgdGhpbmsgYnJpbmdpbmcgdGhl IGRpc2N1c3Npb24gb24gYSBwZXJzb25hbCBsZXZlbCBpcyB1c2VmdWwgdG8gdGhlIGRpc2N1c3Np b24uICBJZiB0aGlzIGlzIGludGVyZXN0aW5nLCBJIGFtIGF3YXJlIHRoYXQgV2luZG93cyBoYXMg SVB2NiBhbmQgYSBmaXJld2FsbC4gIFRoaXMgaXMgbm90IGEgZGVtb25zdHJhdGlvbiB0aGF0IElQ djYgZmlsdGVycyBhcmUgbmVhciBhcyBnb29kIGFzIElQdjQgb25lcy4NCg0KT24gcmVzaWRlbnRp YWwgcm91dGVycywgdGhlIG15dGggdGhhdCBJUHY2IHdpbGwgY29tZSBhbmQgc29sdmUgYWxsIG9m IHRoZSBOQVQgcHJvYmxlbXMgaXMsIGFuZCBhbGxvdyB1YmlxdWl0b3VzIGFuZCBzZWN1cmUgYWNj ZXNzIHRvIGFsbCB0aGUgZGV2aWNlcyBpcywgaW4gZmFjdCwgYSBteXRoLiAgSVB2NiBicmVha3Mg cHJvdG9jb2xzIGFzIG11Y2ggKGlmIG5vdCBtb3JlKSB0aGFuIElQdjQgTkFULiAgVGhlIG1vc3Qg dXNlZCByZXNpZGVudGlhbCByb3V0ZXJzIGluIEdlcm1hbnkgKGFuZCBwcm91ZGx5IEdlcm1hbiBl bmdpbmVlcmVkIHByb2R1Y3QpIHJlcXVpcmVzIOKAnGFkdmFuY2VkIHZpZXfigJ0gZW5hYmxlZCBq dXN0IHRvIGVuYWJsZSBpdDsgaXQgcHJvdmlkZXMgVUxBcyB2aWEgREhDUHY2LCBhbmQgcGVyZm9y bXMgdHJhbnNsYXRpb24gdG8gcm91dGFibGUgSVB2NiBhZGRyZXNzZXMuICBXaGlsZSBJUHY0IE5B VCBuZWVkcyB0byBwZXJmb3JtIHN0YXRlZnVsIHRyYW5zbGF0aW9uIG9mIElQcyBhbmQgcG9ydHMs IHJlc2lkZW50aWFsIHJvdXRlcnMgb24gSVB2NiBvbmx5IHRyYW5zbGF0ZSBJUHMg4oCTIGJ1dCB0 aGF0IGlzIG5vdCBpbXByb3ZpbmcgYSBsb3QuDQoNCk9uIHRvcCBvZiBpdCwgbm90IHRvIGJyZWFr IGNlcnRhaW4sIG1vcmUgY29tcGxleCBwcm90b2NvbHMgdG8gd29yayAoc3VjaCBhcyBCaXRUb3Jy ZW50IG9mIEZUUCksIHRoZXkgbmVlZCB0byBhY3R1YWxseSB1bmRlcnN0YW5kIHRoZW0gYXQgTGF5 ZXItNyBsZXZlbCB0byBtYWtlIHRoZW0gd29yayB0aHJvdWdoIHRoZSB0cmFuc2xhdGlvbiDigJMg YW5kIGd1ZXNzIHdoYXQsIE5BVCBpcyBtdWNoIG1vcmUgdGVzdGVkLiAgTXkgYWN0dWFsIGNvbXBh bnkgaGFzIHRvIHJlcXVpcmUgdGhlaXIgZW1wbG95ZWVzIHRvIHJlcXVlc3QgSVB2NCBpZiB0aGV5 IHdhbnQgdG8gd29yayBmcm9tIGhvbWUgYW5kIGhhdmUgdGhlaXIgc29mdCBwaG9uZSB3b3JrIHBy b3Blcmx5Lg0KDQpBIGZhbW91cyB2ZW5kb3Igb2YgcGVyc29uYWwgY29tcHV0ZXIgd2hpY2ggYWxz byBwcm92aWRlcyDigJxUVuKAnSBhbmQg4oCcUGhvbmXigJ0gdmVyc2lvbiBvZiB0aGVpciBPUywg dXNlcyBOQVQgdG8gaW1wbGVtZW50IHRoZWlyIGFwcGxpY2F0aW9uIGZpbHRlcmluZy4gIFRoaXMg bWVhbnMgdGhhdCB0aGVyZSBpcyBubyBsYXllci03IHN0YXRlZnVsIGZpbHRlciB3aXRob3V0IE5B VCAoc28gZmFyKS4NCg0KQ2VydGFpbiBmaXJld2FsbCB2ZW5kb3JzIChJIGFtIHNvcnJ5LCBhZ2Fp biwgSSBjYW5ub3QgbWFrZSBuYW1lcywgYnV0IHRoZXkgY2FuIGJlIGZvdW5kIGVhc2lseSkgY29t ZSB3aXRoIElQdjYgZGlzYWJsZWQgYW5kIHdpbGwgc2ltcGx5ICppZ25vcmUqIGFuZCAqbGV0IGNv bWUgdGhyb3VnaCogSVB2NiB0cmFmZmljIGFycml2aW5nIG9uIHRoZWlyIGludGVyZmFjZXMgKmJ5 IGRlZmF1bHQqLiAgQW5kIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQg4oCccGVyc29uYWwgZmlyZXdh bGxz4oCdLCBidXQgb2YgTkFTREFRLXF1b3RlZCDigJxuZXh0IGdlbmVyYXRpb27igJ0gZW50ZXJw cmlzZSB2ZW5kb3Igb2YgYXBwbGlhbmNlcyDigJxHYXJ0bmVyIGxlYWRlciBhZ2Fpbi4gQWdhaW4u 4oCdLg0KDQpQcmFjdGljYWxseSBzcGVha2luZywgdG8gYnJpbmcgSVB2NiB0byBhIHN0YXRlIHdo ZXJlIHRoZSBob3N0cyBhcmUgYXMgc2VjdXJlIGFzIHRoZXkgYXJlIHRvZGF5IG9uIElQdjQgb24g bG9jYWwgbmV0d29ya3MgYmVoaW5kIE5BVCwgeW91IG5lZWQgd2VsbC10aG91Z2h0IGZpcmV3YWxs IHNldHVwcywgbXVjaCBiZXR0ZXIgZGVmYXVsdCwgaW1wcm92ZWQgc29mdHdhcmUgc3RhY2sgYW5k IGFwcGxpY2F0aW9uLXVuZGVyc3RhbmRpbmcgbGF5ZXItNyBmaWx0ZXJzLiAgVGhpcyBpcyBub3Qg dGhlIGFjdHVhbCBjYXNlIGdlbmVyYWxseSBvbiBJUHY2IG5ldHdvcmtzIGFuZCBOQVQgZG9lcyBw cm92aWRlIGEgcG9vci1tYW4g4oCcaGFja+KAnSB0byBhdCBsZWFzdCBwcmV2ZW50IGVhc3kgYWNj ZXNzIHRvIHlvdXIgbmV0d29yay1lbmFibGVkIHJlZnJpZ2VyYXRvciBhbmQgbWljcm93YXZlIGF0 IGhvbWUgZnJvbSBpbnRydWRlcnMuDQoNCg0KDQo+LSBob3dldmVyIHdlIGRvbid0IGxpdmUgaW4g c3VjaCB3b3JsZCwgdGhlcmVmb3JlIGhpZGluZyBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGxheWVy IG9mIHByb3RlY3Rpb24gaW4gdGhlICJkZWZlbmNlIGluIGRlcHRoIiBhcHByb2FjaC4NCj4NCj4g VGhlIGZhY3QgdGhhdCB0aGlzICJoaWRpbmciIGFjdHVhbGx5IGhpbmRlcnMgdGhlIGRlcGxveW1l bnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFrZXMgbGlmZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4g bWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3BpYyBvbiB3aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDot KQ0KPg0KPiBUaGVyZSBhcmUgYWxzbyBjYXNlcyB3aGVyZSBOQVQgb2ZmZXJzIGJldHRlciAob3Ig YXQgbGVhc3Qgc2ltcGxlcikgcHJvdGVjdGlvbiB0aGFuIGZpbHRlcnMuICBGb3IgaW5zdGFuY2Us IHRoZXJlIGFyZSBrbm93biAib3ZlcmJpbGxpbmcgYXR0YWNrcyIgcGVyZm9ybWVkIGluIHRlbGNv IG5ldHdvcmtzLCB3aGVyZSBtb2JpbGUgdGVybWluYWxzIGFyZSBzZW50IHdpdGggVURQIHBhY2tl dHMgdG8ga2VlcCB0aGVtIGFsaXZlIGV2ZW4gaWYgd291bGQgYWN0dWFsbHkgZGlzY29ubmVjdCwg Y2F1c2luZyB0aGVtIHRvIGJlIGV4Y2Vzc2l2ZWx5IGJpbGxlZC4gIEZpbHRlcnMgZm9yIHRob3Nl IHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGljYXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0YW5k IHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcgb3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUgdGVy bWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRmb3J3YXJkIHByb3RlY3Rpb24sIGluc3RlYWQu DQo+DQoNClRoZXJlIGlzIG5vIG5lZWQgdG8gcGVyZm9ybSBfYWRkcmVzcyB0cmFuc2xhdGlvbl8g dG8gcGVyZm9ybSB0aGlzIHByb3RlY3Rpb24uDQoNCltNYXJjbyBFcm1pbmldDQoNClRoZXJlIGlz IG5vIHRoZW9yZXRpY2FsIG5lZWQsIGJ1dCB0aGlzIGlzIHdoYXQgd29ya3MuDQoNCkNvbnRpbnVp bmcgdG8gc2F5IE5BVCBpbiB0aGVzZSBleGFtcGxlcyBpcyBhIGJpdCBsaWtlIHNheWluZyAiSSBu ZWVkIG15IHRvb2xib3ggdG8gYmFuZyBpbiBuYWlscyIuIFlvdSBuZWVkIHlvdXIgdG9vbGJveCBi ZWNhdXNlIHRoYXQgaXMgd2hlcmUgeW91ciBoYW1tZXIgaXMsIGhvd2V2ZXIgaXQgaXMgYWN0dWFs bHkgeW91ciBoYW1tZXIgdGhhdCB5b3UgdXNlIHRvIGJhbmcgaW4gbmFpbHMuDQoNCk5BVCBpcyBh ZGRyZXNzIHRyYW5zbGF0aW9uICsgc3RhdGVmdWwgZmlsdGVyaW5nIGluaGVyZW50IGluIHRoZSBv cGVyYXRpb24gb2YgYWRkcmVzcyB0cmFuc2xhdGlvbi4gUGVvcGxlIHdobyBvYmplY3QgdG8gTkFU IGluIElQdjYgYXJlIG9iamVjdGluZyB0byB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhhdCBpdCBp cyBuZWNlc3NhcnkgdG8gcGVyZm9ybSBhZGRyZXNzIHRyYW5zbGF0aW9uIHRvIGFjaGlldmUgc3Rh dGVmdWwgZmlsdGVyaW5nLg0KDQpQZW9wbGUgd2hvIGFkdm9jYXRlIE5BVCBmb3IgSVB2NiBmb3Ig c2VjdXJpdHkgcHVycG9zZXMgZG9uJ3Qgc2VlbSB0byB1bmRlcnN0YW5kIHRoYXQgYWRkcmVzcyB0 cmFuc2xhdGlvbiBpcyAqbm90KiByZXF1aXJlZCB0byBiZSBhYmxlIHRvIHBlcmZvcm0gc3RhdGVm dWwgZmlsdGVyaW5nIC0gb3IgdGhleSdyZSB1c2luZyB0aGUgdGVybSAiTkFUIiB3aGVuIHRoZXkg c2hvdWxkIHJlYWxseSBiZSB1c2luZyB0aGUgdGVybSAic3RhdGVmdWwgZmlsdGVyaW5nIi4NCg0K W01hcmNvIEVybWluaV0NCg0KSSBhZ3JlZSwgYnV0IG5vIG9uZSBpcyBhZHZvY2F0aW5nIGZvciBO QVQg4oCTIG5vdCBtZSwgY2VydGFpbmx5LiAgQWdhaW4sIEkgYW0gc29ycnksIGJ1dCBJIGJlbGll dmUgdGhlcmUgYXJlIHBlb3BsZSB3aG8gYXJlIG92ZXItc2Vuc2libGUgYWJvdXQgdGhpcyB0b3Bp YyBhbmQgaGF2ZW7igJl0IGdvdCBteSBhcmd1bWVudCBwcm9wZXJseS4NCg0KDQoNCj4gUFMuIEkg YW0gYXdhcmUgdGhhdCBtYWpvciBmaXJld2FsbCB2ZW5kb3JzIGltcGxlbWVudCBmaWx0ZXJzIGFn YWluc3Qgb3ZlcmJpbGxpbmcgYXR0YWNrczsgSSB3YXMgb25seSBtYWtpbmcgYW4gb2JqZWN0aW9u IHRvIHRoZSBzZW1hbnRpYyBvZiB0aGUgc2VudGVuY2U6IE5BVCAqcHJvdmlkZXMqIHNlY3VyaXR5 LCBzYXlpbmcgdGhlIGNvbnRyYXJ5IGlzIG5vdCBjb3JyZWN0Lg0KDQoiU2VjdXJpdHkgYWdhaW5z dCB3aGF0IiBpcyB0aGUga2V5IHF1ZXN0aW9uLiBZb3UgY2FuJ3QgYWN0dWFsbHkgc2F5IE5BVCBw cm92aWRlcyBzZWN1cml0eSB3aXRob3V0IGRlZmluaW5nIHRoZSB0aHJlYXQgb3IgY29udGV4dC4g SWYgeW91IGRvbid0IGRlZmluZSB0aGUgdGhyZWF0LCB0aGUgaW1wbGljYXRpb24gb2Ygc3VjaCBh IHN0YXRlbWVudCBpcyB0aGF0IGl0IHByb3ZpZGVzIHNlY3VyaXR5IGFnYWluc3QgbGl0ZXJhbGx5 IGV2ZXJ5IHRocmVhdC4NCg0KSWYgYSBiYW5rIGltcGxlbWVudHMgTkFUIG9uIHRoZWlyIGRhdGEg bmV0d29yaywgYXJlIHRoZXkgbm93IHNlY3VyZWQgYWdhaW5zdCBiYW5rIHJvYmJlcnMgY29taW5n IGludG8gYSBicmFuY2ggd2l0aCBndW5zPyBPYnZpb3VzbHkgbm90Lg0KDQoiTkFUICpwcm92aWRl cyogc2VjdXJpdHkiIGlzIGdvaW5nIHRvIGJlIHdyb25nIGluIG1hbnkgY2FzZXMgYmVjYXVzZSBO QVQgaXMgYW4gZW50aXJlbHkgaW5lZmZlY3RpdmUgbWVhc3VyZSBmb3IgYSBsYXJnZSBzZXQgb2Yg dGhyZWF0cy4NCg0KW01hcmNvIEVybWluaV0NCg0KSSBkbyBub3QgYmVsaWV2ZSBzby4gIEkgYmVs aWV2ZSB0aGF0IG9uIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbiwgTkFUIGlzIG11Y2ggc2FmZXIg dGhhbiB0aGUgY3VycmVudCBJUHY2IGZpbHRlcnMuDQoNCg0KDQo+IFdoZXRoZXIgdGhpcyBjb3Vs ZCBiZSBhY2hpZXZlZCBpbiBzb21lIG90aGVyIHdheXMgaXMgYW5vdGhlciBtYXR0ZXIuDQo+DQoN Ckl0IGlzIHRoZSAqZXhhY3QqIG1hdHRlciBoZXJlLg0KDQpOQVQgaXMgYmVpbmcgYXNzZXJ0ZWQg YXMgdGhlIHNlY3VyaXR5IG1lYXN1cmUgdGhhdCBzaG91bGQgYnkgdXNlZCBpbiBJUHY2LCBiZWNh dXNlIGl0IGhhcyBiZWVuIHVzZWQgaW4gSVB2NCAoYW5kIG5vdCBuZWNlc3NhcmlseSBleGNsdXNp dmVseSBiZWNhdXNlIG9mIHNlY3VyaXR5IC0gbGFjayBvZiBJUHY0IGFkZHJlc3NlcyBpcyBhbm90 aGVyIHJlYXNvbiksIHdpdGhvdXQgYW55IGNvbnNpZGVyYXRpb24gb2YgaXRzIGRyYXdiYWNrcyBv ciBhbHRlcm5hdGl2ZXMgdGhhdCBkb24ndCBoYXZlIHRob3NlIGRyYXdiYWNrcyBlLmcuIHRob3Nl IGRlc2NyaWJlZCBpbiBSRkM0ODY0Lg0KDQpbTWFyY28gRXJtaW5pXQ0KDQpJIGFtIG5vdCBhc3Nl cnRpbmcgdGhhdCBOQVQgc2hvdWxkIGJlIHVzZWQgaW4gSVB2NiAobm90IHN1cmUgaWYgdGhpcyBp cyByZWZlcnJlZCB0byBtZSkuDQoNCj4NCj4gPj4gLSB0aGUgZmFjdCB0aGF0IGl0IGlzIG5vdCBk ZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNlIGlzIGFub3RoZXIgdG9waWMsIGlu IHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxlYXN0IGZvciA5OSUgb2YgdXNlIGNh c2VzIDstKSkNCj4gPg0KPiA+IEkgZG9uJ3Qgc2VlIGEgbmVlZCB0byBkZXBsb3kgTkFUIHdpdGgg SVB2NiBhcyB3aGF0IGhhcyBiZWVuIGFjaGlldmVkIHdpdGggSVB2NCBOQVQgY2FuIGJlIGFjaGll dmVkIGluIElQdjYgd2l0aG91dCB0aGUgZHJhd2JhY2tzIG9mIE5BVC4NCj4NCj4gSSBtZWFuIHRo ZSBzYW1lIGFzIHlvdSBkbywgSSB3b3VsZCBqdXN0IHBocmFzZSBpdCBhcyAidGhlIHBvb3IgSVNQ cyB3aGljaCBzdGlsbCBkbyB0aGF0LCBzaG91bGQgY29uc2lkZXIgbWlncmF0aW5nIHRoZWlyIGFy Y2hpdGVjdHVyZSB0byBiZXR0ZXIgb3B0aW9ucyIuDQo+DQoNClRoZSBjb3N0IG9mIENHTiBjYXBh Y2l0eSB0byBOQVQgdmlkZW8gdHJhZmZpYyB2b2x1bWVzIGZyb20gcG9wdWxhciB2aWRlbyBzaXRl cyBpcyBsaWtlbHkgZ29pbmcgdG8gbWFrZSBkZXBsb3lpbmcgbmF0aXZlIElQdjYgYSBjaGVhcGVy IGFsdGVybmF0aXZlIHZlcnkgcXVpY2tseS4NCg0KW01hcmNvIEVybWluaV0NCg0K4oCmb3IgaXQg aXMgZ29pbmcgdG8gYm91bmNlIGJhY2sgb25jZSB0aGUgdXN1YWwgSVB2NiBwcm9ibGVtcyBhcmlz ZSDigJMgc3RpY2tpbmcgcHVyZWx5IHRvIHRoZSBleGFtcGxlIHlvdSBtYWRlLCBzZWUgcmVjZW50 bHkgaG93IE5ldEZsaXggaGFkIHRvIGJsb2NrIGNlcnRhaW4gSVB2NiBhY2Nlc3NlcyBiZWNhdXNl IGl0IGNhbuKAmXQgYXBwbHkgaXRzIG9yaWdpbiBmaWx0ZXJzLg0KDQoNCg0KUmVnYXJkcywNCk1h cmsuDQoNCltNYXJjbyBFcm1pbmldDQoNClJlZ2FyZHMuDQoNCj4NCj4gUmVnYXJkcywNCj4gTWFy Y28NCj4NCj4gPg0KPiA+UmVnYXJkcywNCj4gPk1hcmsuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+ IOKAi+KAi+KAi+KAi+KAiw0KPiA+IE1hcmNvIEVybWluaQ0KPiA+DQo+ID4gQ0lTU1AsIENJU0Es IENJU00sIENFSCwgSVRJTCwgTUNQLCBQaEQNCj4gPiBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlz dA0KPiA+IEQgKzQ5ICgwKTg5OSA5MDEgMTUyMyAgTSArNDkgKDApMTc1IDQzOSA1NjQyDQo+ID4N Cj4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhA Z21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPl0NCj4gPiBTZW50OiBUaHVy c2RheSwgSnVuZSAxNiwgMjAxNiAxMTo0MyBBTQ0KPiA+IFRvOiBNYXJjbyBFcm1pbmkNCj4gPiBD YzogQnJpYW4gRSBDYXJwZW50ZXI7IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKTsg ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyBvcHNl Y0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9wc2VjLXY2QGll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnPjsgbGlua2VkaW5AeG4t LWRlYnJuLW52YS5kZTxtYWlsdG86bGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZT47IHY2b3BzQGll dGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBb T1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNlYy12Ni0wOA0KPiA+ DQo+ID4gT24gMTYgSnVuZSAyMDE2IGF0IDE5OjE1LCBNYXJjbyBFcm1pbmkgPE1hcmNvLkVybWlu aUByZXNtZWQuY29tPG1haWx0bzpNYXJjby5Fcm1pbmlAcmVzbWVkLmNvbT4+IHdyb3RlOg0KPiA+ ID4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNlY3Vy aXR5LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3QgdG8g c2F5IHRoYXQgaXQgaXMgbm90Lg0KPiA+ID4NCj4gPiA+IEkgcGVyc29uYWxseSBkb24ndCBzeW1w YXRoaXplIG9uIE5BVC1oYXRlcnMuICBOQVQgaGFzIGl0cyByZWFzb25zLA0KPiA+ID4gZXNwZWNp YWxseSBmb3IgY2Fycmllci1ncmFkZSBOQVQNCj4gPg0KPiA+IENHTiBpc24ndCBuZWNlc3Nhcnkg aW4gSVB2NiwgaXQncyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBJU1BzIHJ1bm5pbmcgb3V0IG9m IElQdjQgYWRkcmVzc2VzLg0KPiA+DQo+ID4gIGFuZCBlc3BlY2lhbGx5IGluIHRoZSB0ZWxjbyBz Y2VuYXJpbywgYW5kIHllcywgaXQgZG9lcyBwcm92aWRlIHNvbWUgbGV2ZWwgb2Ygc2VjdXJpdHkg LSBhZ2Fpbiwgbm90IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCBidXQgaXQgZG9lcy4NCj4gPiA+DQo+ ID4NCj4gPiBOQVQgaXMgbm90IG5lY2Vzc2FyeSBpbiBJUHY2LiBUaGUgZXF1aXZhbGVudCBvZiBO QVQncyBwZXJjZWl2ZWQgc2VjdXJpdHkgY2FuIGJlIHByb3ZpZGVkIHZpYSBhbHRlcm5hdGl2ZSBt ZXRob2RzLCBhcyBkZXNjcmliZWQgaW4gUkZDNDg2NC4NCj4gPg0KPiA+IEEgZnVydGhlciB0ZWNo bmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0IGlz IHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEgc2lu Z2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4gRXh0 ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJUHY2 IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCj4gPg0KPiA+IElmIHlvdSB0 cnVseSB3YW50IHRvIGhpZGUgdGhlIGlkZW50aXRpZXMgb2YgaG9zdHMsIE5BVCBkb2Vzbid0IGRv IGVub3VnaCAtIGl0IGlzIG9ubHkgdHJhbnNsYXRpbmcgYWRkcmVzc2VzLCB3aGVyZSBhcyB0aGVy ZSBhcmUgbWFueSBvdGhlciBob3N0IGlkZW50aWZpZXJzIHRoYXQgdGhlIGhvc3QgaXRzZWxmIHN1 cHBsaWVzIG9yIHdpbGwgcmVjZWl2ZSBhbmQgc3VwcGx5IHRoYXQgY2FuIGlkZW50aWZ5IGhvc3Rz IGUuZy4gSFRUUCBjb29raWVzLiAiQSBUZWNobmlxdWUgZm9yIENvdW50aW5nIE5BVHRlZCBIb3N0 cyINCj4gPiAoaHR0cHM6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRm KSBzaG93ZWQgaG93IGEgZmllbGQgd2l0aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBh Y3Jvc3MgYSBOQVQgd2FzIGFibGUgdG8gYmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy4NCj4gPg0K PiA+IElmIHlvdSB0cnVseSB3YW50IHRvIGhpZGUgYSBob3N0IGZyb20gdGhlIEludGVybmV0LCB5 ZXQgc3RpbGwgYWxsb3cgaXQgdG8gYWNjZXNzIHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQsIHVuZGVy IElQdjYgeW91ciBuZXR3b3JrIHdvdWxkIHVzZSBVTEEgYWRkcmVzc2luZywgYW5kIGhhdmUgYSBw ZXItYXBwbGljYXRpb24gcHJvdG9jb2wgcHJveHkgc2VydmVyIHRoYXQgbWFrZXMgYWxsIHJlcXVl c3RzIGxvb2sgbGlrZSB0aGV5J3ZlIGVudGlyZWx5IG9yaWdpbmF0ZWQgZnJvbSB0aGUgYXBwbGlj YXRpb24gcHJveHkgc2VydmVyIGl0c2VsZi4gVG8gdGhlIEludGVybmV0IHNlcnZlciwgdGhlIGFw cGxpY2F0aW9uIHByb3h5IHNlcnZlciB3b3VsZCBhcHBlYXIgdG8gYmUgdGhlIGFwcGxpY2F0aW9u IGVuZCBob3N0IG1ha2luZyB0aGUgcmVxdWVzdHMsIHByZXZlbnRpbmcgYW55IGludGVybmFsIGhv c3QgaWRlbnRpZmllcnMgb3Igb3RoZXIgYXR0cmlidXRlcyBmcm9tIGxlYWtpbmcuDQo+ID4NCj4g Pg0KPiA+IFJlZ2FyZHMsDQo+ID4gTWFyay4NCj4gPg0KPiA+DQo+ID4gPg0KPiA+ID4gUmVnYXJk cywNCj4gPiA+DQo+ID4gPiBNYXJjbyBFcm1pbmkNCj4gPiA+DQo+ID4gPiBDSVNTUCwgQ0lTQSwg Q0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRCBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlzdCBEDQo+ ID4gPiArNDkgKDApODk5IDkwMSAxNTIzICBNICs0OSAoMCkxNzUgNDM5IDU2NDINCj4gPiA+DQo+ ID4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IE9QU0VDIFttYWlsdG86b3BzZWMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b3BzZWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlh biBFDQo+ID4gPiBDYXJwZW50ZXINCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2 IDE6NDUgQU0NCj4gPiA+IFRvOiBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkNCj4g PiA+IENjOiBmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNv bT47IG9wc2VjQGlldGYub3JnPG1haWx0bzpvcHNlY0BpZXRmLm9yZz47IGxpbmtlZGluQHhuLS1k ZWJybi1udmEuZGU8bWFpbHRvOmxpbmtlZGluQHhuLS1kZWJybi1udmEuZGU+Ow0KPiA+ID4gZHJh ZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRm Lm9yZz47IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+IFN1Ympl Y3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZg0KPiA+ID4gZHJh ZnQtaWV0Zi1vcHNlYy12Ni0wOA0KPiA+ID4NCj4gPiA+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVy aWsgS2xpbmUgd3JvdGU6DQo+ID4gPj4gU2VjdGlvbiAyLjEuMiBpcyBmYXIgdG9vIHBlcm1pc3Np dmUgZm9yIG15IHRhc3Rlcy4gIFdlIG5lZWQgdG8gYmUNCj4gPiA+PiBhYmxlIHRvIHNheSB0aGF0 IFVMQStJUHY2IE5BVCBpcyBOT1QgUkVDT01NRU5ERUQgYnkgdGhlIElFVEYuDQo+ID4gPg0KPiA+ ID4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24n dCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVudCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUg aW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hvdWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQg TkFUICE9IHNlY3VyaXR5Lg0KPiA+ID4NCj4gPiA+IFdoaWxlIEknbSBoZXJlLCBzb21lIG90aGVy IHBvaW50czoNCj4gPiA+DQo+ID4gPiAiMi4yLiAgRXh0ZW5zaW9uIEhlYWRlcnMNCj4gPiA+DQo+ ID4gPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5hbmRvJ3Mg SS1EICYgUkZDLiINCj4gPiA+DQo+ID4gPiBUaGF0J3Mgbm90IHRoZSB3aG9sZSBzdG9yeSA7LSku IEZpcnN0bHksIFJGQyA3MDQ1IGhhcyBhIGxvdCBvZg0KPiA+ID4gcmVsZXZhbmNlIHRvIHNlY3Vy aXR5IGFzcGVjdHMuIFNlY29uZCwgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHJlZmVyIHRvDQo+ID4g PiBtb3N0IG9mIHRoZSBtYXRlcmlhbCAoRmVybmFuZG8ncyBvciBub3QpIHVubGVzcyBpdCdzIGRp cmVjdGx5IHJlbGV2YW50DQo+ID4gPiB0byBvcHNlYy4gSSB0aGluayB0aGUgcmVmZXJlbmNlIGlz IGRyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmcsDQo+ID4gPiBidXQgb25seSBpZiB0 aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLg0KPiA+ID4NCj4gPiA+ICIyLjMuMy4gIE5E L1JBIFJhdGUgTGltaXRpbmcNCj4gPiA+IC4uLg0KPiA+ID4gICAgVGhlIGZvbGxvd2luZyBkcmFm dHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0bw0KPiA+ID4gICAgcmF0ZSBsaW1p dCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9uIHdpZmkgbmV0d29ya3MgaW4gb3JkZXIgdG8N Cj4gPiA+ICAgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4gPiA+DQo+ID4gPiAgICBvICBbSS1ELnRo dWJlcnQtc2F2aS1yYS10aHJvdHRsZXJdDQo+ID4gPg0KPiA+ID4gICAgbyAgW0ktRC5jaGFrcmFi YXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQo+ID4gPg0KPiA+ID4gTmVpdGhlciBv ZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAyMDE1 IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFkZXIs IElNSE8uDQo+ID4gPg0KPiA+ID4gIjQuMi4gIFRyYW5zaXRpb24gTWVjaGFuaXNtDQo+ID4gPg0K PiA+ID4gICAgU1Agd2lsbCB0eXBpY2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNo IGFzIDZyZCwgNlBFLCBNQVAsDQo+ID4gPiAgICBEUy1MaXRlIHdoaWNoIGhhdmUgYmVlbiBhbmFs eXplZCBpbiB0aGUgdHJhbnNpdGlvbiBTZWN0aW9uIDIuNy4yDQo+ID4gPiAgICBzZWN0aW9uLiIN Cj4gPiA+DQo+ID4gPiBTaG91bGRuJ3QgeW91IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiA+ ID4NCj4gPiA+IEZpbmFsbHksIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgUHJpdmFjeSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KPiA+ID4NCj4gPiA+IFJnZHMNCj4gPiA+ICAgICBCcmlhbg0K PiA+ID4NCj4gPiA+Pg0KPiA+ID4+IFNlY3Rpb24gMi42LjEuNSBjb3VsZCBwdW5jaCB1cCB0aGUg U0FWSSBzdHVmZiBhIGJpdCBtb3JlIGFzIHdlbGwuICBXZQ0KPiA+ID4+IHNob3VsZCwgaW4gbXkg b3BpbmlvbiwgbWFrZSBpdCBwYWluZnVsbHkgY2xlYXIgdGhhdCBESENQIChvZiBhbnkNCj4gPiA+ PiBwcm90b2NvbCkgaW4gdGhlIGFic2VuY2Ugb2YgbGluay1sYXllciBzZWN1cml0eS9hdWRpdGFi aWxpdHkgZmVhdHVyZXMNCj4gPiA+PiBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkg d2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0eSBhbmQNCj4gPiA+PiB0cmFjZWFiaWxpdHkiIFtTZWN0 aW9uIDIuMS42XS4NCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gPj4gdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiA+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPiA+Pg0KPiA+ID4NCj4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPUFNFQyBt YWlsaW5nIGxpc3QNCj4gPiA+IE9QU0VDQGlldGYub3JnPG1haWx0bzpPUFNFQ0BpZXRmLm9yZz4N Cj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiA+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg== --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBhbSBzb3JyeSwgSSBzdXJyZW5kZXIgdGhlIE91dGxvb2sgb24gdGhlIHRoaXJk IGluZGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgMjoyMSBBTTxi cj4NCjxiPlRvOjwvYj4gTWFyY28gRXJtaW5pPGJyPg0KPGI+Q2M6PC9iPiBFcmljIFZ5bmNrZSAo ZXZ5bmNrZSk7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IEVyaWsgS2xpbmU7IHY2b3Bz QGlldGYub3JnOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgZmdv bnRAc2k2bmV0d29ya3MuY29tOyBCcmlhbiBFIENhcnBlbnRlcjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3Y2b3BzXSBbT1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v cHNlYy12Ni0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KT24gMTcgSnVuIDIwMTYgMDA6MTUsICZxdW90 O01hcmNvIEVybWluaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmNvLkVybWluaUByZXNt ZWQuY29tIj5NYXJjby5Fcm1pbmlAcmVzbWVkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7IEknbGwgdHJ5IHRoZSBob3JyaWJsZSBPdXRsb29rIHRvIHJlcGx5IHVzaW5nIHRl eHQsIHBsZWFzZSBiZWcgbXkgcGFyZG9uIGlmIHRoaXMgaXMgbm90IGZvcm1hdHRlZCBwcm9wZXJs eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBN LCBNYXJrIFNtaXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5j b20iPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+XSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEhpLDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE5BVCBjYW4gYmUgc3Rp bGwgbmVjZXNzYXJ5IGluIElQdjYgaW4gZHVhbC1zdGFjayBzY2VuYXJpbywgZm9yIGluc3RhbmNl LCB3aGVyZSBldmVyeSBob3N0IGlzIGFzc2lnbmVkIGJvdGggYSBJUHY0IGFuZCBJUHY2IGFkZHJl c3NlcyBhbmQgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDR04gZXF1aXBtZW50IGNhbid0IGhhbmRs ZSB0aGVtIGRpZmZlcmVudGx5LiZuYnNwOzxicj4NCiZndDsgJmd0O0NhbiB5b3UgcHJvdmlkZSBh biBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2aWNlLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgd291bGQgcHJlZmVyIG5vdCB0byBtYWtlIG5hbWVzLCBidXQgeW91IHdvdWxkIGJlIHVucGxl YXNhbnRseSBzdXJwcmlzZWQuPG86cD48L286cD48L3A+DQo8cD5JJ20gc2NlcHRpY2FsLCBJIGFu ZCBJIHRoaW5rIG90aGVycyB3b3VsZCB3YW50IGEgY29uY3JldGUgZXhhbXBsZS4gPG86cD48L286 cD48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W01hcmNvIEVybWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gc29ycnks IEkgYW0gbm90IGF1dGhvcmlzZWQgdG8gZG8gdGhhdCBwdWJsaWNhbGx5LiZuYnNwOyBCdXQgdGhp cyBpcyBub3QgbmVjZXNzYXJ5IGFueXdheS4mbmJzcDsgVGhlcmUgaXMgbm8gbmVlZCB0byBsaXN0 IGV2ZXJ5dGhpbmcgdGhhdCB3b3JrcyB3cm9uZywgdG8gZGVmaW5lIHdoYXQgdGhlIGNvcnJlY3QN CiBiZWhhdmlvdXIgc2hvdWxkIGJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+ SWYgcGVvcGxlIGFyZW4ndCBpbXBsZW1lbnRpbmcgc3BlY2lmaWNhdGlvbnMgd2VsbCwgd2UgbmVl ZCB0byBrbm93LCBzbyB0aGF0IGlmIG5lY2Vzc2FyeSB0aGUgc3BlY2lmaWNhdGlvbnMgY2FuIGJl IGltcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGlzIGlzIHdoeSB3ZSBoYXZlIGRyYWZ0LWdvbnQtb3BzZWMtaXB2Ni1maXJld2Fs bC1yZXFzLTAzLnR4dC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+ Jm5ic3A7IEFueXdheSwgaXQgaXMgYWxzbyBub3QganVzdCBhIG1hdHRlciBvZiBub3QgYmVpbmcg YWJsZSB0byBjb25maWd1cmUgdGhlbSBpbiBhIGNlcnRhaW4gd2F5ICh3aGljaCBpcyBwb3NzaWJs eSB0aGUgY2FzZSksIGJ1dCBhbHNvIHRoZSBjYXNlIGluIHdoaWNoIHRoZXkgZG9uJ3Qgd29yayBw cm9wZXJseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElQdjQgYW5kIElQdjYgaGF2ZSB0byBi ZSBoYW5kbGVkIGRpZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xz LCByZXF1aXJpbmcgZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZTxicj4N CiZndDsgJmd0OyBwZXJmb3JtaW5nIE5BVCBvbiBJUHY0IHRyYWZmaWMgaXQgcmVjZWl2ZXMgYW5k IGRvaW5nIHN0YW5kYXJkIHN0YXRlbGVzcyBmb3J3YXJkaW5nIG9mIElQdjYgdHJhZmZpYy4gSXMg dGhhdCB0aGUgc2NlbmFyaW8geW91J3JlIGRlc2NyaWJpbmc/PGJyPg0KJmd0Ozxicj4NCiZndDsg WWVzLCBmb3IgaW5zdGFuY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PSywgc28gJnF1b3Q7 Q0dOJnF1b3Q7IGlzIG5vdCBiZWluZyBwZXJmb3JtZWQgb24gSVB2NiB0cmFmZmljLjxvOnA+PC9v OnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3J0IG9mIENH IGVxdWlwbWVudCB3aWxsIGJlIGFueXdheSBpbiB0aGUgd2F5IGFsc28gZm9yIGR1YWwtc3RhY2sg cmVzaWRlbnRpYWwgY29ubmVjdGlvbnMsIGFuZCBDR04gaXMgc3RpbGwgdXNlZCBvbiBwdXJlIElQ djYgaW1wbGVtZW50YXRpb25zIGFzIHlvdSBuZWVkIHRvIG9mZmVyIGNvbm5lY3Rpdml0eQ0KIHRv IElQdjQtb25seSBob3N0cy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPiZndDtP ciwgdGhleSBoYW5kbGUgY2VydGFpbiBmdW5jdGlvbnMgKGUuZy4gTkFUKSBwdXJlbHkgaW4gdGhl IGRhdGEgcGxhbmUgYXMgdGhleSBhcmUgbG9naWNhbGx5IHNpbXBsZSB0byBiZSBpbXBsZW1lbnRl ZCBpbiBmaXJtd2FyZSwgd2hpbGUgbW9yZSBjb21wbGV4IGZ1bmN0aW9ucyAobGlrZSBpbXBsZW1l bnRpbmcgVUxBIGFkZHJlc3NlcyB0cmFuc2xhdGlvbikgcmVxdWlyZXMgcm91dGluZSBlbmdpbmVz IHRvIGJlIGludm9sdmVkLCB0aGVyZWZvcmUNCiBpbnZvbHZpbmcgZGlmZmVyZW50IGxhdGVuY3kg Zm9yIGV4ZWN1dGlvbi48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5TbyB0aGlzIHNvdW5k cyBsaWtlIGVxdWlwbWVudCBoZXJlIGFkZGl0aW9uYWwgZmVhdHVyZXMgY2Fubm90IGJlIGltcGxl bWVudGVkIGluIGhhcmR3YXJlLCBzbyBpdCBpcyBpbXBsZW1lbnRlZCBpbiBjb250cm9sIHBsYW5l IHNvZnR3YXJlLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBpcyBhbiBleGFtcGxlIG9mIHdoeSBu b3QgdG8gdXNlIE5BVC4gSXQgaXMgdGVjaG5pY2FsbHkgdmVyeSBjb21wbGV4IGNvbXBhcmVkIHRv IHB1cmUgSVB2NCBhbmQgcHVyZSBJUHY2IGZvcndhcmRpbmcuPG86cD48L286cD48L3A+DQo8cD48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVy bWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG8gYWdyZWUgd2l0aCB5b3UuPC9z cGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPkknbSBzdGFydGluZyB0byB3b25kZXIgaWYgcGVvcGxl IHRoaW5rIHRoYXQgaWYgdGhleSB3YW50IHRvIHVzZSBVTEFzIGZvciBzb21lIHJlYXNvbiwgdGhl eSB0aGluayB0aGV5IHRoZW4gbXVzdCBOQVQgdGhlbS4gSWYgdGhleSBkbywgSSB0aGluayB0aGF0 IG1pZ2h0IHNob3cgYSBtaXN1bmRlcnN0YW5kaW5nIG9mIHNvbWV0aGluZyBmdW5kYW1lbnRhbCBh Ym91dCBJUHY2IC0gYSBob3N0IG5hdGl2ZWx5IHN1cHBvcnRzIG11bHRpcGxlIGNvbmN1cnJlbnQN CiBhZGRyZXNzZXMgd2l0aCBkaWZmZXJlbnQgc2NvcGVzLCBhbmQgdHJpZXMgdG8gY2hvb3NlIG9u ZSBvZiBpdHMgc291cmNlIGFkZHJlc3MgdG8gbWF0Y2ggdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mu PG86cD48L286cD48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg Y2FuIHJlYWxseSBzZWUgeW91ciBwb2ludCBoZXJlLiZuYnNwOyBJdCBtYXkgd2VsbCBiZSB0aGF0 IOKAnHBlb3BsZeKAnSBjYW4gbWlzdW5kZXJzdGFuZCBJUHY2LiZuYnNwOyBEZXNwaXRlIGl0cyBl eGlzdGVuY2Ugc2luY2UgYSBkZWNhZGUsIGl0IGlzIG5vdCB3aWRlbHkgYWRvcHRlZCBvdXRzaWRl IG9mIGNlcnRhaW4NCiBBc2lhbiBjb3VudHJpZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cD4mZ3Q7IEl0IGlzIHByZXR0eSBjb21tb24gdGhhdCBjdXN0b21lcnMgd2l0aCBJU1Bz IG9mZmVyaW5nIGR1YWwgc3RhY2ssIHRvIGV4cGVyaWVuY2UgYSBoaWdoZXIgbGF0ZW5jeSBmb3Ig dGhlaXIgY29ubmVjdGlvbiBvbmNlIHRoZXkgaW1wbGVtZW50IElQdjYgYWxvbmcgd2l0aCBJUHY0 LiZuYnNwOyAmbmJzcDtUaGlzIGRvZXMgbm90IGFwcGx5IHdoZW4gb25seSBJUHY0IG9yIG9ubHkg SVB2NiBhcmUgdXNlZC48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5JJ2QgbGlrZSBzb21l IGV4YW1wbGVzIG9mIHRoaXMuPG86cD48L286cD48L3A+DQo8cD5JJ3ZlIGJlZW4gbmF0aXZlbHkg ZHVhbCBzdGFja2VkIGF0IGhvbWUgZm9yIHRoZSBwYXN0IG5lYXIgNSB5ZWFycy4gSSBoYXZlIG5v dCBleHBlcmllbmNlZCBhZGRpdGlvbmFsIGFuZCBub3RpY2VhYmxlIGhpZ2hlciBsYXRlbmN5IGZv ciBhbnl0aGluZyBJIGRvLiBJdCBqdXN0IHdvcmtzLCBhbmQgSSBjYW4ndCB0ZWxsIHdoYXQgaXMg Z29pbmcgb3ZlciBJUHY0IG9yIElQdjYgLSBhbmQgSSBrbm93IHRoYXQgbW9zdCBpZiBub3QgYWxs IEdvb2dsZSwNCiBGYWNlYm9vayBhbmQgTmV0ZmxpeCB0cmFmZmljIGNhbiBhbmQgZG9lcyBjb21l IG92ZXIgSVB2Ni48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WW91IGFyZSBsdWNreS4mbmJzcDsgQWdhaW4sIEkgY2Fubm90IG1ha2UgbmFtZXMs IGJ1dCB5b3UgYXJlIG15IGd1ZXN0IGlmIHlvdSBjb21lIG5lYXIgTXVuaWNoIHNvbWV0aW1lcywg YW5kIEnigJlsbCBzaG93IHlvdSB0aGUgdHlwaWNhbCBFdXJvcGVhbiBkdWFsIHN0YWNrIGltcGxl bWVudGF0aW9uLg0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPkw8L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+SSBhbHNvIHdvcmtlZCBpbiB0aGUgcmVzaWRlbnRpYWwgZGVwbG95bWVu dCBvZiBJUHY2IGF0IHRoZSBvdGhlciBlbmQgb2YgbXkgY29ubmVjdGlvbiBpbiAyMDA5LzIwMTAs IGFuZCB3ZSBuZXZlciByZWNlaXZlZCBhbnkgSVB2NiBsYXRlbmN5IGNvbXBsYWludHMuIEluIDIw MTIgaXQgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBmb3IgbmV3IGN1c3RvbWVyIGNvbm5lY3Rpb25z LjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGVyZSBhcmUgSVNQcyBpbiBHZXJtYW55IHdoaWNoIG9mZmVyIGJ5IGRlZmF1bHQgSVB2NiwgYW5k IHJlcXVpcmVzIHRvIHBheSBhZGRpdGlvbmFsIGZlZXMgaWYgeW91IHdhbnQgSVB2NCAod2hpY2gg aXMgc29tZXRpbWVzIG5lY2Vzc2FyeSBpZiB5b3VyIGNvbXBhbnkgb25seSBpbXBsZW1lbnRzDQog SVB2NCBhbmQgeW91IG5lZWQgdG8gVlBOIGluLCBhcyBDR04gZnJvbSBJUHY2IHRvIElQdjQgYnJl YWtzIG1vc3QgVlBOIHBsYXRmb3JtcykuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZl ciwgdGhlIEV1cm9wZWFuIG9wZXJhdG9ycyBvZmZlcmluZyBkdWFsIHN0YWNrIGFsbCBzdWZmZXJz IGZyb20gbGF0ZW5jeSBpc3N1ZXMuJm5ic3A7IEl0IGNhbiBhbHNvIGJlIHBhcnRpYWxseSBkdWUg dG8gdGhlIGNsaWVudCBvcGVyYXRpdmUgc3lzdGVtIGFuZCBob3cgaXQgZGV0ZWN0cyB3aGljaA0K IGlzIHRoZSBiZXN0IHBhdGggdG8gdXNlIGZvciBob3N0cyB0aGF0IG9mZmVyIGJvdGggY29ubmVj dGl2aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+SSBoYXZlIGNvbWUgYWNy b3NzIHByZXNlbnRhdGlvbnMgb3ZlciB0aGUgcGFzdCB5ZWFycyB0aGF0IGhhdmUgc2hvd24gdGhh dCBJUHY2IGhhcyByZWR1Y2VkIGxhdGVuY3kgZm9yIGR1YWwgc3RhY2sgc2VydmljZXMsIGJlY2F1 c2UgdGhlIElQdjYgcGF0aCB3YXMgZGlmZmVyZW50IGFuZCBzaW1wbGVyIHRoYW4gdGhlIElQdjQg cGF0aC48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QWdhaW4sIHRoYXQgaXMgaW4gdGhlIGlkZWFsIHdvcmxkLCBidXQgaXQgaXMgbm90IG15IGV4 cGVyaWVuY2Ugd2l0aCBkaWZmZXJlbnQgRXVyb3BlYW4gcmVzaWRlbnRpYWwgc2VydmljZSBwcm92 aWRlcnMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SVB2NiBzaG91bGQgaGF2ZSBiZWVuIHRo ZSB1bHRpbWF0ZSBzb2x1dGlvbiB0byBtYW55IGlzc3VlcywgYnV0IGFwcGFyZW50bHkgaXQgaGFz IG5vdCBiZWVuIHRoYXQgc2lsdmVyIGJ1bGxldCB0aGF0IGV2ZXJ5b25lIHdhcyBob3BpbmcgZm9y Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IEFub3RoZXIgcmVxdWlyZW1lbnQgaXMg dGhhdCBhIHNwZWNpZmljIGxvZ2dpbmcgb3IgbW9uaXRvcmluZyBzeXN0ZW0gaXMgaW1wbGVtZW50 ZWQgKGVzcGVjaWFsbHkgZm9yIGxlZ2FsIHJlcXVpcmVtZW50cyksIGFuZCB0aGlzIGlzIGRvbmUg dGhyb3VnaCBsb2dnaW5nIE5BVCB0cmFuc2xhdGlvbnMuJm5ic3A7IEFuIElTUCBpbXBsZW1lbnRp bmcgSVB2NiBhbG9uZyB3aXRoIElQdjQgd291bGQgYmUgaW4gdGhhdCBzaXR1YXRpb24uPGJyPg0K Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+Tm8gbmVlZCB0byBkbyBfYWRkcmVzcyB0cmFuc2xhdGlv bl8gdG8gYmUgYWJsZSB0byBwZXJmb3JtIHRoYXQuPG86cD48L286cD48L3A+DQo8cD48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgaWYgeW91IGhhdmUgdGhlIHBv c3NpYmlsaXR5LCB5b3UgY2FuIGFsd2F5cyBkbyB0aGluZ3MgZGlmZmVyZW50bHkgYW5kIGJldHRl ci48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPiZndDsgTHVja2lseSwgcm91dGVy IHZlbmRvcnMgYXJlIG1vdmluZyBhd2F5IGZyb20gdGhlIGFudGlxdWF0ZSBhcmNoaXRlY3R1cmUg d2hpY2ggc2VwYXJhdGVzIGRhdGEgYW5kIG1hbmFnZW1lbnQgcGxhbmUsIGZvciB2YXJpb3VzIHJl YXNvbnMuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+QWN0dWFsbHksIHRoYXQncyBnb2lu ZyB0byBpbmNyZWFzZSB0aGUgY29zdCBvZiBlcXVpcG1lbnQsIGJlY2F1c2UgaXQgaXNuJ3QgZ29p bmcgdG8gYmUgY2hlYXAgdG8gZG8gc29tZXRoaW5nIGNvbXBsZXggZmFzdC48bzpwPjwvbzpwPjwv cD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b TWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXUgY29udHJhaXJlLCBm b3IgZXF1aXBtZW50IHZlbmRvcnMsIG1vdmluZyBmcm9tIGhhdmluZyBoYXJkd2FyZSBhbmQgZGlm ZmVyZW50IHBsYW5lcyB0byBtYW5hZ2UsIHRvIGEgc29mdHdhcmUtb25seSB2ZXJzaW9uIHdoaWNo IGNhbiBiZSBzaGlwcGVkIGFzIGJvdGggaGFyZHdhcmUgYW5kIHZpcnR1YWwNCiBpbWFnZSwgbWVh bnMgbm90YWJsZSByZWR1Y3Rpb24gb2YgY29zdHMgaW4gdGVybXMgb2YgZGV2ZWxvcG1lbnQsIHN1 cHBvcnQsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgb2YgY291cnNlIEkgY29u Y2VkZSB0aGVyZSBtYXkgYmUgZGlmZmVyZW5jZXMgY2FzZSBieSBjYXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgVGhpcyBpcyBhbHNvIHdoeSB3ZSBwdWJsaXNo ZWQgZHJhZnQtZ29udC1vcHNlYy1pcHY2LWZpcmV3YWxsLXJlcXMtMDMudHh0LCB0byBtYWtlIGl0 IGV4cGxpY2l0IHRoYXQgdGhpcyBzaG91bGQgbm90IGhhcHBlbi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAoSSBhbSBhd2FyZSB0aGlzIGlzIG9mZi10b3BpYywganVzdCBtYWtpbmcgbXkgcG9pbnQgOi0p KTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7VW5mb3J0dW5hdGVseSBSRkMgNDg2NCBkb2Vz IG5vdCBtZW50aW9uIHN1Y2ggY2FzZSwgQUZBSUsuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyBJbiBhbnkgY2FzZSwgSSBhbSBoYXBweSB0byBjb25jZWRlIGl0IGNvdWxkIGJlIGFu IGV4dHJlbWUgY2FzZSBhbmQgdGhhdCBpdCBpcyBub3QgbmVjZXNzYXJ5IGFueW1vcmUgaW4gSVB2 NiBmb3IgdGhlIGdyZWF0IG1ham9yaXR5IG9mIHVzZTxicj4NCiZndDsgJmd0OyBjYXNlcy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPa2F5PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSB3YXMg bm90IHJlYWxseSBtYWtpbmcgYSBzcGVjaWZpYyBjYXNlIGZvciBJUHY2IC0gbXkgb3Bwb3NpdGlv biB3YXMgdG8gdGhlIGNvbmNlcHQgdGhhdCBOQVQgaXMgbm90IHNlY3VyaXR5LCBhbmQgdG8gdGhl IGZhY3QgdGhhdCBpdCBzaG91bGQgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdyaXR0ZW4gYXMgc3Vj aCBpbiB0aGUgUkZDLjxicj4NCiZndDsgJmd0OyBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91 dCBJUHY2LiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhh dCBjYW4gYmUgYXBwbGllZCB0byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhl cnM8YnI+DQomZ3Q7ICZndDsgdGhhdCBzaG91bGRuJ3QsIGFuZCBvcHBvcnR1bml0aWVzIHdoZXJl IElQdjYgY2FuIHByb3ZpZGUgYmV0dGVyIHNlY3VyaXR5IHRoYXQgSVB2NCAoZS5nLiBzcGFyc2Ug aG9zdCBhZGRyZXNzaW5nIGluIGEgLzY0IG1ha2VzIGFkZHJlc3MgcHJvYmluZzxicj4NCiZndDsg Jmd0OyB0byBkaXNjb3ZlciBob3N0cyBpbXBvc3NpYmxlIHdpdGhpbiBhIHVzZWZ1bCBhbmQgcHJh Y3RpY2FsIHRpbWVmcmFtZS4pLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9rYXksIEkgaGF2ZSBub3Ro aW5nIHRvIG9iamVjdCBvbiB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBOQVQgKmRvZXMqIHByb3ZpZGUgYSBmb3JtIG9mIHNlY3VyaXR5PGJyPg0KJmd0OyAmZ3Q7 V2hhdCBzcGVjaWZpYyBzZWN1cml0eSBkb2VzIGl0IHByb3ZpZGUgdGhhdCBpcyBkdWUgdG8gdGhl IGFkZHJlc3MgdHJhbnNsYXRpb24gZnVuY3Rpb24/PGJyPg0KJmd0OyAmZ3Q7IElmIHlvdSdyZSB0 aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlvbiBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJl aW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRyZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQg c3RhdGUgY2FuIGJlPGJyPg0KJmd0OyAmZ3Q7IGNyZWF0ZWQgd2l0aG91dCBwZXJmb3JtaW5nIGFk ZHJlc3MgdHJhbnNsYXRpb24sIHdoaWNoIGlzIHdoYXQgYSBzdGF0ZWZ1bCBmaXJld2FsbCBkb2Vz IGFuZCBkaWQgaW4gSVB2NCBiZWZvcmUgTkFUIGJlY2FtZSB3aWRlbHkgZGVwbG95ZWQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSB0b3RhbGx5IGFncmVlIHdpdGggeW91LiZuYnNwOyBJIGFtIGFjdHVh bGx5IHJlZmVycmluZyB0byB0aGUgcG9zc2liaWxpdHkgdG8gaGlkZSB0aGUgc3lzdGVtcyBiZWhp bmQgdGhlIE5BVHRlZCBpbnRlcmZhY2VzIG9mIHRoZSByb3V0ZXIvZmlyZXdhbGwsIG5vdCBqdXN0 IHRoZWlyIGFkZHJlc3NlcyBidXQgYWxzbyBwb3J0cyBhbmQgc2VydmljZXMuJm5ic3A7IElmIHlv dSBvbmx5IGFwcGx5IGZpbHRlcmluZywgeW91IGFyZSBwcm90ZWN0aW5nIC0gYnV0IG5vdA0KIGhp ZGluZy48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5OQVQgaXMgbm8gd2hlcmUgbmVhciBh cyBlZmZlY3RpdmUgYXQgaGlkaW5nIHN5c3RlbXMgYXMgcGVvcGxlIHRoaW5rLiBUb28gbWFueSBh dHRyaWJ1dGVzIG9mIHRoZSBzeXN0ZW0gYmVoaW5kIHRoZSBOQVQgbGVhayBhY3Jvc3MgTkFULCBv ciBjYW4gYmUgZm9yY2VkIHRvIGxlYWsgYWNyb3NzIHRoZSBOQVQuPG86cD48L286cD48L3A+DQo8 cD5JdCBpcyBxdWl0ZSBhIHBvcm91cyBiYXJyaWVyLCBiZWNhdXNlIE5BVCBpcyBub3QgYWN0dWFs bHkgZGVzaWduZWQgdG8gaGlkZSBzeXN0ZW1zLiBBZGRyZXNzIHRyYW5zbGF0aW9uIGluaGVyZW50 bHkgaGlkZXMgc29tZSBvZiB0aGUgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVtcyAoYWRkcmVzc2Vz KSBidXQgbm90IGFsbCBvZiB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Nb3N0IG9mIHRoZSBOQVQgdnVsbmVyYWJpbGl0aWVzIGNvbWUg ZnJvbSBob21lIHJvdXRlcnMsIHdpdGggdGhlaXIgUG5QIGFuZCBvdGhlciBwcm90b2NvbHMgd2hp Y2ggYXJlIG9mdGVuIGJhZGx5IGltcGxlbWVudGVkLCBhcyB3ZWxsIGFzIHByb3RvY29scyB0aGF0 IGRvIG5vdCBuZWNlc3NhcmlseQ0KIHBsYXkgd2VsbCB3aXRoIE5BVC4mbmJzcDsgSWYgaXQganVz dCBoaWRlcyBJUHMgYW5kIHBvcnRzLCB0aGF0IGlzIGFscmVhZHkgZG9pbmcgc29tZXRoaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBkbyBub3QgZ2V0IG1lIHdyb25nLiZuYnNw OyBJIGFtIGFzIG11Y2ggYXMgYW55b25lIGVsc2UgaG9waW5nIHRvIHNlZSB0aGUgZGF5IHRoYXQg TkFUIGlzIHJlbGVnYXRlZCBpbnRvIHRoZSBwbGFjZSBpbiBoaXN0b3J5IHdoZXJlIGl0IHNob3Vs ZCBiZS4mbmJzcDsgQW5kIEkgYW0gKHVuZm9ydHVuYXRlbHkpDQogd2VsbCBhd2FyZSB0aGF0IGFs bCBwcm90b2NvbHMgd2hpY2ggbmVnb3RpYXRlIGFuIGhpZ2ggcG9ydCB0aHJvdWdoIGFuIGVuY3J5 cHRlZCBjaGFubmVsIChGVFAtUywgb3IgY2VydGFpbiB2ZXJzaW9ucyBvZiBNaWNyb3NvZnQgQ29t bXVuaWNhdG9yL0x5bmMsIGNlcnRhaW4gVlBOLCBldGMuKSB3aWxsIG5ldmVyIHdvcmsgd2l0aCBh bnkgTkFUIChJIGVuc3VyZSB5b3UgSSBoYXZlIGxpdmVkIHRoYXQgb24gbXkgc2tpbikuPG86cD48 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgdGhlIHNhbWUgdGltZSwgSSBjYW5ub3QgbmVnbGVjdCB0 aGF0IHByYWN0aWNhbGx5IHNwZWFraW5nLCBteSBleHBlcmllbmNlIHdpdGggQ0dOIHdpdGggSVB2 NCBpbiB0ZWxjb3MgaXMgdGhhdCBpdCBpcyBxdWl0ZSBlZmZlY3RpdmUuJm5ic3A7IEZpcmV3YWxs IHZlbmRvcnMgaGF2ZSBzcGVudCBhIGRlY2FkZQ0KIGZpeGluZyBpdCBhbmQgaW1wbGVtZW50aW5n IGV2ZXJ5IHNvcnQgb2YgdmFyaWFudCBzdWNoIGFzIE5BVC1ULCBOQVQtUE1QLCBOQVQgZm9yIFJQ QywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+Jmd0OyBJbiBhIHBlcmZl Y3Qgd29ybGQsIHlvdSBoYXZlIHN1Y2ggZ29vZCBmaWx0ZXJzIHRoYXQgeW91IGNhbiB0cmFuc3Bh cmVudGx5IHByb3ZpZGUgdGhlIHJlYWwgYWRkcmVzc2VzIGFuZCBwb3J0cyBmcm9tIGNsaWVudHMg dG8gdGhlIHJlc3Qgb2YgdGhlIEludGVybmV0DQo8bzpwPjwvbzpwPjwvcD4NCjxwPkl0J3Mgc291 bmRpbmcgbGlrZSB5b3UncmUgbm90IHVwIHRvIGRhdGUgd2l0aCBJUHY2IGZpcmV3YWxsaW5nIGNh cGFiaWxpdGllcyBpbiBkZXZpY2VzLCBhbmQgdGhlcmVmb3JlIG1pZ2h0IGJlIGFzc3VtaW5nIHRo YXQgbm9uZSBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwPkFyZSB5b3UgYXdhcmUgZm9yIGV4YW1w bGUgdGhhdCBXaW5kb3dzIGhhcyBoYWQgYSBzdGF0ZWZ1bCBJUHY2IGZpcmV3YWxsLCBlbmFibGVk IGJ5IGRlZmF1bHQsIHNpbmNlIFdpbmRvd3MgWFAgc2VydmljZSBwYWNrIDIsIHJlbGVhc2VkIG1v cmUgdGhhbiBhIGRlY2FkZSBhZ28/PG86cD48L286cD48L3A+DQo8cD5JJ3ZlIGJlZW4gdXNpbmcg SVB2NiB1bmRlciBMaW51eCB0byBhY2Nlc3MgdGhlIEludGVybmV0IGVpdGhlciB2aWEgdHVubmVs cyBvciBuYXRpdmVseSBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlLCB1c2luZyB0aGUgc3RhdGVmdWwg SVB2NiBmaXJld2FsbCB0aGF0IGhhcyBiZWVuIHBhcnQgb2YgdGhlIExpbnV4IGtlcm5lbCBmb3Ig YXQgbGVhc3QgdGhhdCBsb25nLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBBbmRyb2lkIHBob25l IGhhcyBuYXRpdmUgYW5kIHB1YmxpYyBJUHY2IGFkZHJlc3NlcyBhbmQgaXMgbm90IGJlaGluZCBh bnkgc29ydCBvZiBJUHY2IE5BVC4gSXQncyBiZWhpbmQgYSBkZXZpY2UgdGhhdCBjYW4gcGVyZm9y bSBJUHY2IHN0YXRlZnVsIGZpcmV3YWxsaW5nLCBob3dldmVyIEkgdGhpbmsgSSd2ZSB0dXJuZWQg aXQgb2ZmLCBiZWNhdXNlIEkgdHJ1c3QgdGhhdCBhcyBHb29nbGUgY2FuJ3QgdHJ1c3QgdGhlcmUg aXMgYSBuZXR3b3JrDQogZmlyZXdhbGwgdXBzdHJlYW0gb2YgbXkgcGhvbmUsIHRoZXkgZW5zdXJl IG15IHBob25lIGlzICZxdW90O0ludGVybmV0IHByb29mJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0K PHA+VGhlICZxdW90O3BlcmZlY3QmcXVvdDsgd29ybGQgeW91J3JlIHJlZmVycmluZyB0byBpcyBh bmQgaGFzIGJlZW4gcmVhbGl0eSBmb3IgYSBsb25nIHRpbWUgZm9yIGEgbG90IG9mIHBlb3BsZS48 bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBzb3JyeSwgSSBkbyBub3QgdGhpbmsgYnJpbmdpbmcgdGhlIGRpc2N1c3Npb24gb24gYSBwZXJz b25hbCBsZXZlbCBpcyB1c2VmdWwgdG8gdGhlIGRpc2N1c3Npb24uJm5ic3A7IElmIHRoaXMgaXMg aW50ZXJlc3RpbmcsIEkgYW0gYXdhcmUgdGhhdCBXaW5kb3dzIGhhcyBJUHY2IGFuZCBhIGZpcmV3 YWxsLiZuYnNwOw0KIFRoaXMgaXMgbm90IGEgZGVtb25zdHJhdGlvbiB0aGF0IElQdjYgZmlsdGVy cyBhcmUgbmVhciBhcyBnb29kIGFzIElQdjQgb25lcy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PbiByZXNpZGVudGlhbCByb3V0ZXJzLCB0aGUgbXl0aCB0aGF0IElQdjYgd2lsbCBjb21lIGFu ZCBzb2x2ZSBhbGwgb2YgdGhlIE5BVCBwcm9ibGVtcyBpcywgYW5kIGFsbG93IHViaXF1aXRvdXMg YW5kIHNlY3VyZSBhY2Nlc3MgdG8gYWxsIHRoZSBkZXZpY2VzIGlzLCBpbiBmYWN0LCBhIG15dGgu Jm5ic3A7DQogSVB2NiBicmVha3MgcHJvdG9jb2xzIGFzIG11Y2ggKGlmIG5vdCBtb3JlKSB0aGFu IElQdjQgTkFULiZuYnNwOyBUaGUgbW9zdCB1c2VkIHJlc2lkZW50aWFsIHJvdXRlcnMgaW4gR2Vy bWFueSAoYW5kIHByb3VkbHkgR2VybWFuIGVuZ2luZWVyZWQgcHJvZHVjdCkgcmVxdWlyZXMg4oCc YWR2YW5jZWQgdmlld+KAnSBlbmFibGVkIGp1c3QgdG8gZW5hYmxlIGl0OyBpdCBwcm92aWRlcyBV TEFzIHZpYSBESENQdjYsIGFuZCBwZXJmb3JtcyB0cmFuc2xhdGlvbiB0byByb3V0YWJsZQ0KIElQ djYgYWRkcmVzc2VzLiZuYnNwOyBXaGlsZSBJUHY0IE5BVCBuZWVkcyB0byBwZXJmb3JtIHN0YXRl ZnVsIHRyYW5zbGF0aW9uIG9mIElQcyBhbmQgcG9ydHMsIHJlc2lkZW50aWFsIHJvdXRlcnMgb24g SVB2NiBvbmx5IHRyYW5zbGF0ZSBJUHMg4oCTIGJ1dCB0aGF0IGlzIG5vdCBpbXByb3ZpbmcgYSBs b3QuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdG9wIG9mIGl0LCBub3QgdG8gYnJlYWsg Y2VydGFpbiwgbW9yZSBjb21wbGV4IHByb3RvY29scyB0byB3b3JrIChzdWNoIGFzIEJpdFRvcnJl bnQgb2YgRlRQKSwgdGhleSBuZWVkIHRvIGFjdHVhbGx5IHVuZGVyc3RhbmQgdGhlbSBhdCBMYXll ci03IGxldmVsIHRvIG1ha2UgdGhlbSB3b3JrDQogdGhyb3VnaCB0aGUgdHJhbnNsYXRpb24g4oCT IGFuZCBndWVzcyB3aGF0LCBOQVQgaXMgbXVjaCBtb3JlIHRlc3RlZC4mbmJzcDsgTXkgYWN0dWFs IGNvbXBhbnkgaGFzIHRvIHJlcXVpcmUgdGhlaXIgZW1wbG95ZWVzIHRvIHJlcXVlc3QgSVB2NCBp ZiB0aGV5IHdhbnQgdG8gd29yayBmcm9tIGhvbWUgYW5kIGhhdmUgdGhlaXIgc29mdCBwaG9uZSB3 b3JrIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZmFtb3VzIHZlbmRvciBv ZiBwZXJzb25hbCBjb21wdXRlciB3aGljaCBhbHNvIHByb3ZpZGVzIOKAnFRW4oCdIGFuZCDigJxQ aG9uZeKAnSB2ZXJzaW9uIG9mIHRoZWlyIE9TLCB1c2VzIE5BVCB0byBpbXBsZW1lbnQgdGhlaXIg YXBwbGljYXRpb24gZmlsdGVyaW5nLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgdGhlcmUNCiBpcyBu byBsYXllci03IHN0YXRlZnVsIGZpbHRlciB3aXRob3V0IE5BVCAoc28gZmFyKS48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DZXJ0YWluIGZpcmV3YWxsIHZlbmRvcnMgKEkgYW0gc29ycnksIGFn YWluLCBJIGNhbm5vdCBtYWtlIG5hbWVzLCBidXQgdGhleSBjYW4gYmUgZm91bmQgZWFzaWx5KSBj b21lIHdpdGggSVB2NiBkaXNhYmxlZCBhbmQgd2lsbCBzaW1wbHkgKmlnbm9yZSogYW5kICpsZXQg Y29tZSB0aHJvdWdoKg0KIElQdjYgdHJhZmZpYyBhcnJpdmluZyBvbiB0aGVpciBpbnRlcmZhY2Vz ICpieSBkZWZhdWx0Ki4mbmJzcDsgQW5kIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQg4oCccGVyc29u YWwgZmlyZXdhbGxz4oCdLCBidXQgb2YgTkFTREFRLXF1b3RlZCDigJxuZXh0IGdlbmVyYXRpb27i gJ0gZW50ZXJwcmlzZSB2ZW5kb3Igb2YgYXBwbGlhbmNlcyDigJxHYXJ0bmVyIGxlYWRlciBhZ2Fp bi4gQWdhaW4u4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByYWN0aWNhbGx5IHNwZWFr aW5nLCB0byBicmluZyBJUHY2IHRvIGEgc3RhdGUgd2hlcmUgdGhlIGhvc3RzIGFyZSBhcyBzZWN1 cmUgYXMgdGhleSBhcmUgdG9kYXkgb24gSVB2NCBvbiBsb2NhbCBuZXR3b3JrcyBiZWhpbmQgTkFU LCB5b3UgbmVlZCB3ZWxsLXRob3VnaHQgZmlyZXdhbGwgc2V0dXBzLA0KIG11Y2ggYmV0dGVyIGRl ZmF1bHQsIGltcHJvdmVkIHNvZnR3YXJlIHN0YWNrIGFuZCBhcHBsaWNhdGlvbi11bmRlcnN0YW5k aW5nIGxheWVyLTcgZmlsdGVycy4mbmJzcDsgVGhpcyBpcyBub3QgdGhlIGFjdHVhbCBjYXNlIGdl bmVyYWxseSBvbiBJUHY2IG5ldHdvcmtzIGFuZCBOQVQgZG9lcyBwcm92aWRlIGEgcG9vci1tYW4g 4oCcaGFja+KAnSB0byBhdCBsZWFzdCBwcmV2ZW50IGVhc3kgYWNjZXNzIHRvIHlvdXIgbmV0d29y ay1lbmFibGVkIHJlZnJpZ2VyYXRvcg0KIGFuZCBtaWNyb3dhdmUgYXQgaG9tZSBmcm9tIGludHJ1 ZGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwPiZndDstIGhvd2V2ZXIgd2UgZG9uJ3QgbGl2ZSBpbiBzdWNoIHdvcmxk LCB0aGVyZWZvcmUgaGlkaW5nIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2YgcHJvdGVj dGlvbiBpbiB0aGUgJnF1b3Q7ZGVmZW5jZSBpbiBkZXB0aCZxdW90OyBhcHByb2FjaC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgZmFjdCB0aGF0IHRoaXMgJnF1b3Q7aGlkaW5nJnF1b3Q7IGFjdHVh bGx5IGhpbmRlcnMgdGhlIGRlcGxveW1lbnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFrZXMgbGlm ZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4gbWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3BpYyBvbiB3 aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDotKTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBh bHNvIGNhc2VzIHdoZXJlIE5BVCBvZmZlcnMgYmV0dGVyIChvciBhdCBsZWFzdCBzaW1wbGVyKSBw cm90ZWN0aW9uIHRoYW4gZmlsdGVycy4mbmJzcDsgRm9yIGluc3RhbmNlLCB0aGVyZSBhcmUga25v d24gJnF1b3Q7b3ZlcmJpbGxpbmcgYXR0YWNrcyZxdW90OyBwZXJmb3JtZWQgaW4gdGVsY28gbmV0 d29ya3MsIHdoZXJlIG1vYmlsZSB0ZXJtaW5hbHMgYXJlIHNlbnQgd2l0aCBVRFAgcGFja2V0cyB0 byBrZWVwIHRoZW0gYWxpdmUgZXZlbiBpZiB3b3VsZA0KIGFjdHVhbGx5IGRpc2Nvbm5lY3QsIGNh dXNpbmcgdGhlbSB0byBiZSBleGNlc3NpdmVseSBiaWxsZWQuJm5ic3A7IEZpbHRlcnMgZm9yIHRo b3NlIHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGljYXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0 YW5kIHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcgb3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUg dGVybWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRmb3J3YXJkIHByb3RlY3Rpb24sIGluc3Rl YWQuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlcmUgaXMgbm8gbmVlZCB0byBwZXJm b3JtIF9hZGRyZXNzIHRyYW5zbGF0aW9uXyB0byBwZXJmb3JtIHRoaXMgcHJvdGVjdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUg aXMgbm8gdGhlb3JldGljYWwgbmVlZCwgYnV0IHRoaXMgaXMgd2hhdCB3b3Jrcy48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPkNvbnRpbnVpbmcgdG8gc2F5IE5BVCBpbiB0aGVzZSBl eGFtcGxlcyBpcyBhIGJpdCBsaWtlIHNheWluZyAmcXVvdDtJIG5lZWQgbXkgdG9vbGJveCB0byBi YW5nIGluIG5haWxzJnF1b3Q7LiBZb3UgbmVlZCB5b3VyIHRvb2xib3ggYmVjYXVzZSB0aGF0IGlz IHdoZXJlIHlvdXIgaGFtbWVyIGlzLCBob3dldmVyIGl0IGlzIGFjdHVhbGx5IHlvdXIgaGFtbWVy IHRoYXQgeW91IHVzZSB0byBiYW5nIGluIG5haWxzLjxvOnA+PC9vOnA+PC9wPg0KPHA+TkFUIGlz IGFkZHJlc3MgdHJhbnNsYXRpb24gJiM0Mzsgc3RhdGVmdWwgZmlsdGVyaW5nIGluaGVyZW50IGlu IHRoZSBvcGVyYXRpb24gb2YgYWRkcmVzcyB0cmFuc2xhdGlvbi4gUGVvcGxlIHdobyBvYmplY3Qg dG8gTkFUIGluIElQdjYgYXJlIG9iamVjdGluZyB0byB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhh dCBpdCBpcyBuZWNlc3NhcnkgdG8gcGVyZm9ybSBhZGRyZXNzIHRyYW5zbGF0aW9uIHRvIGFjaGll dmUgc3RhdGVmdWwgZmlsdGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGVvcGxlIHdobyBhZHZv Y2F0ZSBOQVQgZm9yIElQdjYgZm9yIHNlY3VyaXR5IHB1cnBvc2VzIGRvbid0IHNlZW0gdG8gdW5k ZXJzdGFuZCB0aGF0IGFkZHJlc3MgdHJhbnNsYXRpb24gaXMgKm5vdCogcmVxdWlyZWQgdG8gYmUg YWJsZSB0byBwZXJmb3JtIHN0YXRlZnVsIGZpbHRlcmluZyAtIG9yIHRoZXkncmUgdXNpbmcgdGhl IHRlcm0gJnF1b3Q7TkFUJnF1b3Q7IHdoZW4gdGhleSBzaG91bGQgcmVhbGx5IGJlIHVzaW5nIHRo ZSB0ZXJtICZxdW90O3N0YXRlZnVsIGZpbHRlcmluZyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxw PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWFyY28g RXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSwgYnV0IG5vIG9uZSBp cyBhZHZvY2F0aW5nIGZvciBOQVQg4oCTIG5vdCBtZSwgY2VydGFpbmx5LiZuYnNwOyBBZ2Fpbiwg SSBhbSBzb3JyeSwgYnV0IEkgYmVsaWV2ZSB0aGVyZSBhcmUgcGVvcGxlIHdobyBhcmUgb3Zlci1z ZW5zaWJsZSBhYm91dCB0aGlzIHRvcGljIGFuZCBoYXZlbuKAmXQgZ290DQogbXkgYXJndW1lbnQg cHJvcGVybHkuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cD4mZ3Q7IFBTLiBJIGFtIGF3YXJlIHRoYXQgbWFqb3IgZmlyZXdh bGwgdmVuZG9ycyBpbXBsZW1lbnQgZmlsdGVycyBhZ2FpbnN0IG92ZXJiaWxsaW5nIGF0dGFja3M7 IEkgd2FzIG9ubHkgbWFraW5nIGFuIG9iamVjdGlvbiB0byB0aGUgc2VtYW50aWMgb2YgdGhlIHNl bnRlbmNlOiBOQVQgKnByb3ZpZGVzKiBzZWN1cml0eSwgc2F5aW5nIHRoZSBjb250cmFyeSBpcyBu b3QgY29ycmVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90O1NlY3VyaXR5IGFnYWlu c3Qgd2hhdCZxdW90OyBpcyB0aGUga2V5IHF1ZXN0aW9uLiBZb3UgY2FuJ3QgYWN0dWFsbHkgc2F5 IE5BVCBwcm92aWRlcyBzZWN1cml0eSB3aXRob3V0IGRlZmluaW5nIHRoZSB0aHJlYXQgb3IgY29u dGV4dC4gSWYgeW91IGRvbid0IGRlZmluZSB0aGUgdGhyZWF0LCB0aGUgaW1wbGljYXRpb24gb2Yg c3VjaCBhIHN0YXRlbWVudCBpcyB0aGF0IGl0IHByb3ZpZGVzIHNlY3VyaXR5IGFnYWluc3QgbGl0 ZXJhbGx5IGV2ZXJ5IHRocmVhdC48bzpwPjwvbzpwPjwvcD4NCjxwPklmIGEgYmFuayBpbXBsZW1l bnRzIE5BVCBvbiB0aGVpciBkYXRhIG5ldHdvcmssIGFyZSB0aGV5IG5vdyBzZWN1cmVkIGFnYWlu c3QgYmFuayByb2JiZXJzIGNvbWluZyBpbnRvIGEgYnJhbmNoIHdpdGggZ3Vucz8gT2J2aW91c2x5 IG5vdC48bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90O05BVCAqcHJvdmlkZXMqIHNlY3VyaXR5JnF1 b3Q7IGlzIGdvaW5nIHRvIGJlIHdyb25nIGluIG1hbnkgY2FzZXMgYmVjYXVzZSBOQVQgaXMgYW4g ZW50aXJlbHkgaW5lZmZlY3RpdmUgbWVhc3VyZSBmb3IgYSBsYXJnZSBzZXQgb2YgdGhyZWF0cy48 bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBk byBub3QgYmVsaWV2ZSBzby4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgb24gcHJhY3RpY2FsIGltcGxl bWVudGF0aW9uLCBOQVQgaXMgbXVjaCBzYWZlciB0aGFuIHRoZSBjdXJyZW50IElQdjYgZmlsdGVy cy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD4m Z3Q7IFdoZXRoZXIgdGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiBzb21lIG90aGVyIHdheXMgaXMg YW5vdGhlciBtYXR0ZXIuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgaXMgdGhlICpl eGFjdCogbWF0dGVyIGhlcmUuPG86cD48L286cD48L3A+DQo8cD5OQVQgaXMgYmVpbmcgYXNzZXJ0 ZWQgYXMgdGhlIHNlY3VyaXR5IG1lYXN1cmUgdGhhdCBzaG91bGQgYnkgdXNlZCBpbiBJUHY2LCBi ZWNhdXNlIGl0IGhhcyBiZWVuIHVzZWQgaW4gSVB2NCAoYW5kIG5vdCBuZWNlc3NhcmlseSBleGNs dXNpdmVseSBiZWNhdXNlIG9mIHNlY3VyaXR5IC0gbGFjayBvZiBJUHY0IGFkZHJlc3NlcyBpcyBh bm90aGVyIHJlYXNvbiksIHdpdGhvdXQgYW55IGNvbnNpZGVyYXRpb24gb2YgaXRzIGRyYXdiYWNr cyBvciBhbHRlcm5hdGl2ZXMNCiB0aGF0IGRvbid0IGhhdmUgdGhvc2UgZHJhd2JhY2tzIGUuZy4g dGhvc2UgZGVzY3JpYmVkIGluIFJGQzQ4NjQuPG86cD48L286cD48L3A+DQo8cD48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0NCjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGFzc2VydGluZyB0aGF0IE5BVCBzaG91 bGQgYmUgdXNlZCBpbiBJUHY2IChub3Qgc3VyZSBpZiB0aGlzIGlzIHJlZmVycmVkIHRvIG1lKS48 L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSB0aGUg ZmFjdCB0aGF0IGl0IGlzIG5vdCBkZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNl IGlzIGFub3RoZXIgdG9waWMsIGluIHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxl YXN0IGZvciA5OSUgb2YgdXNlIGNhc2VzIDstKSk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSSBkb24ndCBzZWUgYSBuZWVkIHRvIGRlcGxveSBOQVQgd2l0aCBJUHY2IGFzIHdoYXQgaGFz IGJlZW4gYWNoaWV2ZWQgd2l0aCBJUHY0IE5BVCBjYW4gYmUgYWNoaWV2ZWQgaW4gSVB2NiB3aXRo b3V0IHRoZSBkcmF3YmFja3Mgb2YgTkFULjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbWVhbiB0aGUg c2FtZSBhcyB5b3UgZG8sIEkgd291bGQganVzdCBwaHJhc2UgaXQgYXMgJnF1b3Q7dGhlIHBvb3Ig SVNQcyB3aGljaCBzdGlsbCBkbyB0aGF0LCBzaG91bGQgY29uc2lkZXIgbWlncmF0aW5nIHRoZWly IGFyY2hpdGVjdHVyZSB0byBiZXR0ZXIgb3B0aW9ucyZxdW90Oy48YnI+DQomZ3Q7PG86cD48L286 cD48L3A+DQo8cD5UaGUgY29zdCBvZiBDR04gY2FwYWNpdHkgdG8gTkFUIHZpZGVvIHRyYWZmaWMg dm9sdW1lcyBmcm9tIHBvcHVsYXIgdmlkZW8gc2l0ZXMgaXMgbGlrZWx5IGdvaW5nIHRvIG1ha2Ug ZGVwbG95aW5nIG5hdGl2ZSBJUHY2IGEgY2hlYXBlciBhbHRlcm5hdGl2ZSB2ZXJ5IHF1aWNrbHku DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCmb3IgaXQgaXMgZ29pbmcgdG8gYm91bmNlIGJhY2sgb25jZSB0aGUgdXN1YWwgSVB2NiBwcm9i bGVtcyBhcmlzZSDigJMgc3RpY2tpbmcgcHVyZWx5IHRvIHRoZSBleGFtcGxlIHlvdSBtYWRlLCBz ZWUgcmVjZW50bHkgaG93IE5ldEZsaXggaGFkIHRvIGJsb2NrIGNlcnRhaW4gSVB2NiBhY2Nlc3Nl cw0KIGJlY2F1c2UgaXQgY2Fu4oCZdCBhcHBseSBpdHMgb3JpZ2luIGZpbHRlcnMuPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+UmVnYXJkcyw8YnI+ DQpNYXJrLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7PGJyPg0KJmd0OyBS ZWdhcmRzLDxicj4NCiZndDsgTWFyY288YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7ICZndDtNYXJrLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyDigIvigIvigIvigIvigIs8YnI+DQomZ3Q7 ICZndDsgTWFyY28gRXJtaW5pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENJU1NQLCBD SVNBLCBDSVNNLCBDRUgsIElUSUwsIE1DUCwgUGhEPGJyPg0KJmd0OyAmZ3Q7IFNlbmlvciBJVCBT ZWN1cml0eSBBbmFseXN0PGJyPg0KJmd0OyAmZ3Q7IEQmbmJzcDsmIzQzOzQ5ICgwKTg5OSA5MDEg MTUyMyAmbmJzcDtNJm5ic3A7JiM0Mzs0OSAoMCkxNzUgNDM5IDU2NDI8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgUmVzTWVkIEdlcm1hbnkgSW5jPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IE1hcmsgU21pdGggW21haWx0bzo8YSBocmVmPSJt YWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbSI+bWFya3p6enNtaXRoQGdtYWlsLmNvbTwvYT5d PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDExOjQzIEFNPGJy Pg0KJmd0OyAmZ3Q7IFRvOiBNYXJjbyBFcm1pbmk8YnI+DQomZ3Q7ICZndDsgQ2M6IEJyaWFuIEUg Q2FycGVudGVyOyBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSk7IDxhIGhyZWY9Im1h aWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20iPg0KZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3JnIj5vcHNlY0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3Bz ZWMtdjZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bGlua2VkaW5AeG4tLWRlYnJuLW52 YS5kZSI+bGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTwvYT47DQo8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBbT1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNl Yy12Ni0wODxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAxNiBKdW5lIDIwMTYgYXQg MTk6MTUsIE1hcmNvIEVybWluaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmNvLkVybWluaUByZXNt ZWQuY29tIj5NYXJjby5Fcm1pbmlAcmVzbWVkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg Jmd0OyAmZ3Q7IFdlbGwsIGFjdHVhbGx5LCBpbmZyYXN0cnVjdHVyZSBoaWRpbmcgSVMgcGFydCBv ZiBzZWN1cml0eS4mbmJzcDsgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBp bmNvcnJlY3QgdG8gc2F5IHRoYXQgaXQgaXMgbm90Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgSSBwZXJzb25hbGx5IGRvbid0IHN5bXBhdGhpemUgb24gTkFULWhhdGVy cy4mbmJzcDsgTkFUIGhhcyBpdHMgcmVhc29ucyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBlc3BlY2lh bGx5IGZvciBjYXJyaWVyLWdyYWRlIE5BVDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBD R04gaXNuJ3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHByb2JsZW0gb2Yg SVNQcyBydW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJm5ic3A7YW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5hcmlvLCBhbmQg eWVzLCBpdCBkb2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFnYWluLCBub3Qg dGhlIGNvbXBsZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5BVCBpcyBub3QgbmVjZXNzYXJ5IGluIElQdjYu IFRoZSBlcXVpdmFsZW50IG9mIE5BVCdzIHBlcmNlaXZlZCBzZWN1cml0eSBjYW4gYmUgcHJvdmlk ZWQgdmlhIGFsdGVybmF0aXZlIG1ldGhvZHMsIGFzIGRlc2NyaWJlZCBpbiBSRkM0ODY0Ljxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBIGZ1cnRoZXIgdGVjaG5pcXVlIHRvIGhpZGUgdG9w b2xvZ3kgdGhhdCBpc24ndCBtZW50aW9uZWQgaW4gUkZDNDg2NCBpcyB0byB1c2Ugc29tZXRoaW5n IGxpa2UgSVNBVEFQIG9yIHNpbWlsYXIsIHRvIGNyZWF0ZSBhIHNpbmdsZSAvNjQgc3VibmV0IG92 ZXIgdGhlIHRvcCBvZiBtdWx0aXBsZSBJUHY0IHN1Ym5ldHMuIEV4dGVybmFsbHksIGFsbCBob3N0 cyB3aWxsIGFwcGVhciB0byBiZWxvbmcgdG8gYSBzaW5nbGUgSVB2NiBzdWJuZXQsIGhpZGluZw0K IHRoZSBpbnRlcm5hbCB0b3BvbG9neS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYg eW91IHRydWx5IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNu J3QgZG8gZW5vdWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFz IHRoZXJlIGFyZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNl bGYgc3VwcGxpZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkg aG9zdHMgZS5nLiBIVFRQIGNvb2tpZXMuDQogJnF1b3Q7QSBUZWNobmlxdWUgZm9yIENvdW50aW5n IE5BVHRlZCBIb3N0cyZxdW90Ozxicj4NCiZndDsgJmd0OyAoPGEgaHJlZj0iaHR0cHM6Ly93d3cu Y3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRmIj5odHRwczovL3d3dy5jcy5jb2x1 bWJpYS5lZHUvfnNtYi9wYXBlcnMvZm5hdC5wZGY8L2E+KSBzaG93ZWQgaG93IGEgZmllbGQgd2l0 aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBhY3Jvc3MgYSBOQVQgd2FzIGFibGUgdG8g YmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg SWYgeW91IHRydWx5IHdhbnQgdG8gaGlkZSBhIGhvc3QgZnJvbSB0aGUgSW50ZXJuZXQsIHlldCBz dGlsbCBhbGxvdyBpdCB0byBhY2Nlc3MgdGhpbmdzIG9uIHRoZSBJbnRlcm5ldCwgdW5kZXIgSVB2 NiB5b3VyIG5ldHdvcmsgd291bGQgdXNlIFVMQSBhZGRyZXNzaW5nLCBhbmQgaGF2ZSBhIHBlci1h cHBsaWNhdGlvbiBwcm90b2NvbCBwcm94eSBzZXJ2ZXIgdGhhdCBtYWtlcyBhbGwgcmVxdWVzdHMg bG9vayBsaWtlIHRoZXkndmUgZW50aXJlbHkNCiBvcmlnaW5hdGVkIGZyb20gdGhlIGFwcGxpY2F0 aW9uIHByb3h5IHNlcnZlciBpdHNlbGYuIFRvIHRoZSBJbnRlcm5ldCBzZXJ2ZXIsIHRoZSBhcHBs aWNhdGlvbiBwcm94eSBzZXJ2ZXIgd291bGQgYXBwZWFyIHRvIGJlIHRoZSBhcHBsaWNhdGlvbiBl bmQgaG9zdCBtYWtpbmcgdGhlIHJlcXVlc3RzLCBwcmV2ZW50aW5nIGFueSBpbnRlcm5hbCBob3N0 IGlkZW50aWZpZXJzIG9yIG90aGVyIGF0dHJpYnV0ZXMgZnJvbSBsZWFraW5nLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0 OyBNYXJrLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IE1hcmNvIEVybWluaTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgQ0lTU1AsIENJU0EsIENJU00sIENFSCwgSVRJTCwgTUNQLCBQaEQgU2VuaW9yIElU IFNlY3VyaXR5IEFuYWx5c3QgRDxicj4NCiZndDsgJmd0OyAmZ3Q7ICYjNDM7NDkgKDApODk5IDkw MSAxNTIzJm5ic3A7IE0gJiM0Mzs0OSAoMCkxNzUgNDM5IDU2NDI8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlc01lZCBHZXJtYW55IEluYzxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IE9QU0VDIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmciPm9wc2VjLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgQnJpYW4gRTxicj4NCiZndDsgJmd0OyAmZ3Q7IENhcnBlbnRl cjxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDE6NDUg QU08YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5j a2UpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpmZ29udEBzaTZuZXR3 b3Jrcy5jb20iPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHNl Y0BpZXRmLm9yZyI+DQpvcHNlY0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsaW5rZWRp bkB4bi0tZGVicm4tbnZhLmRlIj5saW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlPC9hPjs8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1Ympl Y3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZjxicj4NCiZndDsg Jmd0OyAmZ3Q7IGRyYWZ0LWlldGYtb3BzZWMtdjYtMDg8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZl IGZvciBteSB0YXN0ZXMuJm5ic3A7IFdlIG5lZWQgdG8gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsgYWJsZSB0byBzYXkgdGhhdCBVTEEmIzQzO0lQdjYgTkFUIGlzIE5PVCBSRUNPTU1FTkRFRCBi eSB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgaGF2 ZSBzdHJvbmcgc3ltcGF0aHkgd2l0aCB0aGF0IHN0YXRlbWVudCwgYnV0IEkgZG9uJ3QgdGhpbmsg dGhpcyBpcyB0aGUgZG9jdW1lbnQgdG8gZG8gaXQ7IHRoZSBwb2ludCBpcyBtYWRlIGluIFJGQzQ4 NjQgdG9vLiBXaGF0IHdlIHNob3VsZCBkbyBoZXJlIGlzIHVuZGVybGluZSB0aGF0IE5BVCAhPSBz ZWN1cml0eS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoaWxlIEkn bSBoZXJlLCBzb21lIG90aGVyIHBvaW50czo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZxdW90OzIuMi4mbmJzcDsgRXh0ZW5zaW9uIEhlYWRlcnM8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBUQkQsIGEgc2hvcnQgc2Vj dGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5hbmRvJ3MgSS1EICZhbXA7IFJGQy4mcXVvdDs8YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYXQncyBub3QgdGhlIHdob2xl IHN0b3J5IDstKS4gRmlyc3RseSwgUkZDIDcwNDUgaGFzIGEgbG90IG9mPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgcmVsZXZhbmNlIHRvIHNlY3VyaXR5IGFzcGVjdHMuIFNlY29uZCwgdGhlcmUgaXMgbm8g cmVhc29uIHRvIHJlZmVyIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbW9zdCBvZiB0aGUgbWF0ZXJp YWwgKEZlcm5hbmRvJ3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSByZWxldmFudDxicj4N CiZndDsgJmd0OyAmZ3Q7IHRvIG9wc2VjLiBJIHRoaW5rIHRoZSByZWZlcmVuY2UgaXMgZHJhZnQt aWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBidXQgb25s eSBpZiB0aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7Mi4zLjMuJm5ic3A7IE5EL1JBIFJhdGUgTGltaXRp bmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAuLi48YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgVGhlIGZvbGxvd2luZyBkcmFmdHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0 bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyByYXRlIGxpbWl0IFJBcyBhbmQgb3Ro ZXIgTkQgbWVzc2FnZXMgb24gd2lmaSBuZXR3b3JrcyBpbiBvcmRlciB0bzxicj4NCiZndDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBhZGRyZXNzIHRoaXMgaXNzdWU6PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBbSS1ELnRodWJlcnQt c2F2aS1yYS10aHJvdHRsZXJdPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBbSS1ELmNoYWtyYWJhcnRpLW5vcmRtYXJrLTZtYW4tZWZm aWNpZW50LW5kXSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg TmVpdGhlciBvZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEy IGFuZCAyMDE1IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRo ZSByZWFkZXIsIElNSE8uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm cXVvdDs0LjIuJm5ic3A7IFRyYW5zaXRpb24gTWVjaGFuaXNtPGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgU1Agd2lsbCB0eXBpY2FsbHkgdXNlIHRy YW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBFLCBNQVAsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7IERTLUxpdGUgd2hpY2ggaGF2ZSBiZWVuIGFuYWx5emVkIGluIHRo ZSB0cmFuc2l0aW9uIFNlY3Rpb24gMi43LjI8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgc2VjdGlvbi4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IFNob3VsZG4ndCB5b3UgYWRkIFJGQzY4NzcgNDY0WExBVCBub3c/PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBGaW5hbGx5LCBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBh IFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IFJnZHM8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7QnJpYW48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyBTZWN0aW9uIDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhlIFNB Vkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxsLiZuYnNwOyBXZTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyBzaG91bGQsIGluIG15IG9waW5pb24sIG1ha2UgaXQgcGFpbmZ1bGx5IGNsZWFyIHRoYXQg REhDUCAob2YgYW55PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IHByb3RvY29sKSBpbiB0aGUgYWJz ZW5jZSBvZiBsaW5rLWxheWVyIHNlY3VyaXR5L2F1ZGl0YWJpbGl0eSBmZWF0dXJlczxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICZx dW90O3RvIGVuc3VyZSBhdWRpYmlsaXR5IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB0cmFj ZWFiaWxpdHkmcXVvdDsgW1NlY3Rpb24gMi4xLjZdLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT1BTRUMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOk9QU0VDQGlldGYu b3JnIj5PUFNFQ0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_-- From nobody Fri Jun 17 06:17:04 2016 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 9281F12D531; Fri, 17 Jun 2016 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 1wR86jomkrYa; Fri, 17 Jun 2016 06:16:58 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id A021C12D59D; Fri, 17 Jun 2016 06:16:57 -0700 (PDT) Received: from [85.158.136.67] by server-3.bemta-5.messagelabs.com id 36/70-01940-848F3675; Fri, 17 Jun 2016 13:16:56 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRWlGSWpSXmKPExsVy+JUil67Hj+R wg7WT9C2e7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y+fcC4wFrfwVk/sWMjYw vuHrYuTiEBJYzyhxftN3ZghnD6PEpXOX2LsYOTnYBHQk/i/fBWaLCChKnGj4xgZSxCwwk0niz osLbCAJYQEvif17W5khirwltt7YzAhhO0mcfn+OFcRmEVCVuH1tApjNK+Assev4VqhtTcwSh7 d9BtvAKaAvseT3MzCbUUBW4kvjarChzALiEreezGcCsSUEBCSW7DnPDGGLSrx8/I8VwlaUuPx 7CksXIwdQvabE+l36EK2KElO6H7JD7BWUODnzCQuILSSgItG+YBlUa7BE78F1LBMYxWYh2TYL YdIsJJNmIZm0gJFlFaNGcWpRWWqRrqGRXlJRZnpGSW5iZo6uoYGpXm5qcXFiempOYlKxXnJ+7 iZGYHQxAMEOxr5ZzocYJTmYlER5555LDhfiS8pPqcxILM6ILyrNSS0+xCjDwaEkwavzHSgnWJ SanlqRlpkDjHOYtAQHj5IIrx5Imre4IDG3ODMdInWK0ZLjzuIba5k4bj17ACQ/TThwjEmIJS8 /L1VKnNccpEEApCGjNA9uHCwVXWKUlRLmZQQ6UIinILUoN7MEVf4VozgHo5IwbxDIFJ7MvBK4 ra+ADmICOkhzHthBJYkIKakGxpm7vVxZPp0XS13gus995asPm9rfPOZSz5B+GyY1N7F8KYOTa dc8FaHvCpOYDHY8/J5TvGmdoKpE3fYXi12+/Xi7KSz4WuRXk8knXkic9ghn3xvTn/zC1G3XtX NmB/c7LNR8eqEr/k8Nf2xc0csLsxQ2PyiqX1mtJbKj2krJif/8nC/mbzUfLlViKc5INNRiLip OBAAvb5CIQAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-15.tower-207.messagelabs.com!1466169416!12213373!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14786 invoked from network); 17 Jun 2016 13:16:56 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-15.tower-207.messagelabs.com with SMTP; 17 Jun 2016 13:16:56 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 15:16:56 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 15:16:56 +0200 From: Marco Ermini To: Gert Doering Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx7OSZDWt19w1D06Dzoga8sHTvZ/r20RAgAGP3gCAADo8kA== Date: Fri, 17 Jun 2016 13:16:55 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <20160617114732.GK79185@Space.Net> In-Reply-To: <20160617114732.GK79185@Space.Net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 13:16:56.0282 (UTC) FILETIME=[859FDBA0:01D1C89A] Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , Mark Smith , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:16:59 -0000 VG8gYWNjZXNzIElQdjQtb25seSBlbmFibGVkIGhvc3RzPw0KDQoNClJlZ2FyZHMsDQrigIvigIvi gIvigIvigIsNCk1hcmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBN Q1AsIFBoRA0KU2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1 MjMgwqBNwqArNDkgKDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR2VydCBEb2VyaW5nIFttYWlsdG86Z2VydEBz cGFjZS5uZXRdIA0KU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDE6NDggUE0NClRvOiBNYXJj byBFcm1pbmkNCkNjOiBNYXJrIFNtaXRoOyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNl Yy12NkBpZXRmLm9yZzsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1kZWJybi1udmEuZGU7 IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KU3ViamVjdDogUmU6IFt2Nm9wc10gW09QU0VDXSBBc2tp bmcgZm9yIGEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzZWMtdjYtMDgNCg0KSGksDQoNCk9uIFRo dSwgSnVuIDE2LCAyMDE2IGF0IDEwOjAzOjI1QU0gKzAwMDAsIE1hcmNvIEVybWluaSB3cm90ZToN Cj4gTkFUIGNhbiBiZSBzdGlsbCBuZWNlc3NhcnkgaW4gSVB2NiBpbiBkdWFsLXN0YWNrIHNjZW5h cmlvLCBmb3IgaW5zdGFuY2UsIHdoZXJlIGV2ZXJ5IGhvc3QgaXMgYXNzaWduZWQgYm90aCBhIElQ djQgYW5kIElQdjYgYWRkcmVzc2VzIGFuZCB0aGUgQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUg dGhlbSBkaWZmZXJlbnRseS4gIFVuZm9ydHVuYXRlbHkgUkZDIDQ4NjQgZG9lcyBub3QgbWVudGlv biBzdWNoIGNhc2UsIEFGQUlLLg0KDQpXaHkgd291bGQgYW55b25lIHJvdXRlIHRoZWlyIElQdjYg dHJhZmZpYyB0byB0aGUgSVB2NCBDR04gYm94Pw0KDQpDR04gYm94ZXMgYXJlIHdheSBleHBlbnNp dmUsIHNvIGFueW9uZSB3aXRoIGEgY2FsY3VsYXRvciB3b3VsZCByb3V0ZSBldmVyeXRoaW5nIHRo YXQgZG9lcyBub3QgbmVlZCBOQVQgYXJvdW5kIHRoZSBDR04gYm94Lg0KDQpHZXJ0IERvZXJpbmcN CiAgICAgICAgLS0gTmV0TWFzdGVyDQotLQ0KaGF2ZSB5b3UgZW5hYmxlZCBJUHY2IG9uIHNvbWV0 aGluZyB0b2RheS4uLj8NCg0KU3BhY2VOZXQgQUcgICAgICAgICAgICAgICAgICAgICAgICBWb3Jz dGFuZDogU2ViYXN0aWFuIHYuIEJvbWhhcmQNCkpvc2VwaC1Eb2xsaW5nZXItQm9nZW4gMTQgICAg ICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBBLiBHcnVuZG5lci1DdWxlbWFubg0KRC04MDgwNyBN dWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQpUZWw6 ICs0OSAoMCk4OS8zMjM1Ni00NDQgICAgICAgICAgIFVTdC1JZE5yLjogREU4MTMxODUyNzkNCg== From nobody Fri Jun 17 08:10:16 2016 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 A649112D6A2 for ; Fri, 17 Jun 2016 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 iff1ZWxM-4mw for ; Fri, 17 Jun 2016 08:10:14 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B99C12D697 for ; Fri, 17 Jun 2016 08:10:13 -0700 (PDT) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E4BE261C9D for ; Fri, 17 Jun 2016 17:10:08 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9F531602FD; Fri, 17 Jun 2016 17:10:08 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8E09734CE6; Fri, 17 Jun 2016 17:10:08 +0200 (CEST) Date: Fri, 17 Jun 2016 17:10:08 +0200 From: Gert Doering To: Marco Ermini Message-ID: <20160617151008.GS79185@Space.Net> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <20160617114732.GK79185@Space.Net> <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HQGUecSJzcpn1lKh" Content-Disposition: inline In-Reply-To: <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , Mark Smith , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:10:15 -0000 --HQGUecSJzcpn1lKh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jun 17, 2016 at 01:16:55PM +0000, Marco Ermini wrote: > To access IPv4-only enabled hosts? You wouldn't send IPv*6* packets to an IPv4-only host in a dual-stack client situation. CGN for IPv4 is not NAT64. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --HQGUecSJzcpn1lKh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXZBLPAAoJEN9WwGXkzn/FTLsQAJIhnNVZSts3JnLzMW5el2uC OFrV2nFUxZ36t3JDYRskODY6klc8BnxiOQQ1pKKGm+6H9WZd9Bds6sCL9BBV+web OP2H6NjD2Z2NFP5smrnst/VZZTkAwCvxZaO4HpVd7Pyfp/61/gAf2ZsUAChVEvkg iNcKQ6AN6JK7jJdNKUalFy+QRkPJIRoobGqj8tTupRE3Ij73zICx661yyQdg5ZFU oog7pzdS/RhtHvvj/autjlitZ+k894DaCs1yvFoNO7ctF7I22uU48ELryE7pywmK en/FmxpQC3xzjiEcVnEJt+hyjHnhJ5dckpQRmoVlc2v+poWE6IVK8Rf7LoIUP30Q b8YdNCj1sxokxAUSejtcircRKJ58KPGGUo62pTX5Y+c64niKvk+tYLNFF1LEeQ6V IOi/nDf1b5UmlN5VSme+xN46PSReLnzYltlJM+t/eWr0yoWsxPG9lkTi6mrL1JuR ipcAI98q8RaoRzYM8wX1LSrsBdPmIliDb/5iYX1F2uU4MtCfcSqGchp4YLoIrCHV fIDji8L0e+wyIoJHtUwGixlInF83e4F0NCrKTP2fZaU268WlZjBw2VleA/XC/eBj yvRk1+WY2S5CqsVXHyC2XVs6HNz+OeSmJ7nY+zmFGncCk62zc3NkR0IgnJQiu2Eu SkSZXVICwdOgX49qljbF =0aAF -----END PGP SIGNATURE----- --HQGUecSJzcpn1lKh-- From nobody Fri Jun 17 13:14:49 2016 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 D4A0C12D112; Fri, 17 Jun 2016 13:14:43 -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 IffnKXeaLpQU; Fri, 17 Jun 2016 13:14:42 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 8318112DAAB; Fri, 17 Jun 2016 13:14:41 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c2so33843729pfa.2; Fri, 17 Jun 2016 13:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=k58vCRAygyXHmWeOMPHIWr6RNXxFVX8zErJ6gNGyPzs=; b=ZVnWxXMKagph+KAKb9qP5NK5Ic7FSG7F58Pu5gRNv5fWNr+9h8M0su/I6/UX8AeWTx l5LTPVlwrM/Vz7Ght5GjYK4s5XFE5BHRCZAlhNjQ3sZGrP5ZEGKk7Li6GVd4IxkSUteM vn1CY5ATNiqAwoWigC4ZIIqJ3LgwU1ItRdApyqa8dSaYoChnQwI9FO6X2GsPOOZqKwUf WY27iKdRRRgQq74ojT8OGkdSiZNFJl9TbjAgEpfqKP7GXSVLnHHKUQwenut0pGBj/FRN B8nu0LdScsLRyuTsnYKzIlEniUz8Ga74ysU/J3fT/qTaCzx1pK/OFecThiZMzVwrchW8 KD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=k58vCRAygyXHmWeOMPHIWr6RNXxFVX8zErJ6gNGyPzs=; b=nGCw6LY/IVWTkjCudWK6i6XAXevvJtA+FLDPYs12CGPztwUTG7h8oAOtl6rG6aIqj/ cFjx/CVFeW5n9WJ+jKsQSNnEObABNCCjN1ijk67m9aN01yDI1ICVVck3/3HohAUb6J01 YBQvczBqJPIHTvNOgH462UPOBJUiDc+FsjPwFLaAmRLpNfDrim9U5dHMwL97G/Q0kRF3 0tHmk9gEMde7v7yXlTM2gMevQYJ65x56MKeV/OYvtuYkR/feGZpUzLleupyth/nd9W2I eTWacHrhSHe84evvgxdb6eeQTFCrasCnnKtJVqQwYHh7V6tN2eGfGwsbhjeaiEUsZstX OnWA== X-Gm-Message-State: ALyK8tK5cNI2toa0ABonXB7vchXpzZpPUd3G/FL91RKcUGkTSNcSmDn3UiUJhzcg4ybmuQ== X-Received: by 10.98.103.198 with SMTP id t67mr4200582pfj.158.1466194480933; Fri, 17 Jun 2016 13:14:40 -0700 (PDT) Received: from [192.168.178.23] ([118.148.67.217]) by smtp.gmail.com with ESMTPSA id an13sm70368752pac.42.2016.06.17.13.14.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2016 13:14:40 -0700 (PDT) To: Marco Ermini , Erik Kline , "Eric Vyncke (evyncke)" References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: <26aa8d79-7f3c-d05b-15ea-dc11b240a19c@gmail.com> Date: Sat, 18 Jun 2016 08:14:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:14:44 -0000 So, can we agree on "NAT is not required to provide security in IPv6 (see= for example [RFC4864])." I agree that this aspect of IPv6, including the appropriate use of ULAs, is definitely hard to explain to people brought up on common IPv4 practic= e. Regards Brian On 17/06/2016 23:29, Marco Ermini wrote: > I am sorry Brian, I don't think you understood my argument. I am not a= rguing about you mention. I am arguing against the semantic of a phrase = that says "NAT does not provide security". This sentence is semantically= wrong, and usually comes from a priori NAT-haters (I have met a few). >=20 > I am only against stating such sentence in the RFC, not against the fac= t that we don't need NAT. I hope this is clearer now. >=20 > Anyway, I have made my point sufficiently, I believe. >=20 >=20 > Regards, > Marco. >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Friday, June 17, 2016 3:40 AM > To: Marco Ermini; Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; d= raft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16/06/2016 21:15, Marco Ermini wrote: >> Well, actually, infrastructure hiding IS part of security. It is not = the full picture, but it is incorrect to say that it is not. >=20 > Have you read RFC4864 recently? Section 4.4 is all about how you don't = need NAT to hide infrastructure topology in IPv6. >=20 >> I personally don't sympathize on NAT-haters. NAT has its reasons, esp= ecially for carrier-grade NAT and especially in the telco scenario, and y= es, it does provide some level of security - again, not the complete pict= ure, but it does. >=20 > That's IPv4. This is IPv6. >=20 > Brian >=20 >> >> >> Regards, >> =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B >> Marco Ermini >> >> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D=20 >> +49 (0)899 901 1523 M +49 (0)175 439 5642 >> >> ResMed Germany Inc >> >> >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E=20 >> Carpenter >> Sent: Thursday, June 16, 2016 1:45 AM >> To: Erik Kline; Eric Vyncke (evyncke) >> Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; = >> draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org >> Subject: Re: [OPSEC] [v6ops] Asking for a review of=20 >> draft-ietf-opsec-v6-08 >> >> On 16/06/2016 07:45, Erik Kline wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be=20 >>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I have strong sympathy with that statement, but I don't think this is = the document to do it; the point is made in RFC4864 too. What we should d= o here is underline that NAT !=3D security. >> >> While I'm here, some other points: >> >> "2.2. Extension Headers >> >> TBD, a short section referring to all Fernando's I-D & RFC." >> >> That's not the whole story ;-). Firstly, RFC 7045 has a lot of=20 >> relevance to security aspects. Second, there is no reason to refer to = >> most of the material (Fernando's or not) unless it's directly relevant= =20 >> to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,= >> but only if that document is going anywhere. >> >> "2.3.3. ND/RA Rate Limiting >> ... >> The following drafts are actively discussing methods to >> rate limit RAs and other ND messages on wifi networks in order to >> address this issue: >> >> o [I-D.thubert-savi-ra-throttler] >> >> o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >> >> Neither of those drafts is in the least active (from 2012 and 2015 res= pectively). Dead drafts are of no help to the reader, IMHO. >> >> "4.2. Transition Mechanism >> >> SP will typically use transition mechanisms such as 6rd, 6PE, MAP, >> DS-Lite which have been analyzed in the transition Section 2.7.2 >> section." >> >> Shouldn't you add RFC6877 464XLAT now? >> >> Finally, I think there should be a Privacy Considerations section. >> >> Rgds >> Brian >> >>> >>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We= =20 >>> should, in my opinion, make it painfully clear that DHCP (of any >>> protocol) in the absence of link-layer security/auditability features= =20 >>> does not provide any satisfactory way "to ensure audibility and=20 >>> traceability" [Section 2.1.6]. >>> >>> _______________________________________________ >>> 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 >> >=20 From nobody Fri Jun 17 15:13:41 2016 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 BFE5812DBC5; Fri, 17 Jun 2016 15:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 haPAOX8pgazh; Fri, 17 Jun 2016 15:13:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 3C77712DBC3; Fri, 17 Jun 2016 15:13:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 43AF01FCAB8; Fri, 17 Jun 2016 22:13:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1F798160055; Fri, 17 Jun 2016 22:13:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D36C160076; Fri, 17 Jun 2016 22:13:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o-Cz0GieMFGn; Fri, 17 Jun 2016 22:13:24 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 80558160055; Fri, 17 Jun 2016 22:13:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8EF854BB29DF; Sat, 18 Jun 2016 08:13:22 +1000 (EST) To: Marco Ermini From: Mark Andrews References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> In-reply-to: Your message of "Fri, 17 Jun 2016 13:12:09 +0000." <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> Date: Sat, 18 Jun 2016 08:13:22 +1000 Message-Id: <20160617221322.8EF854BB29DF@rock.dv.isc.org> Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , Mark Smith , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 22:13:36 -0000 In message <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004>, Marco Ermini writes: > On residential routers, the myth that IPv6 will come and solve all of the > NAT problems is, and allow ubiquitous and secure access to all the > devices is, in fact, a myth. IPv6 breaks protocols as much (if not more) > than IPv4 NAT. The most used residential routers in Germany (and proudly > German engineered product) requires advanced view enabled just to enable > it; it provides ULAs via DHCPv6, and performs translation to routable > IPv6 addresses. While IPv4 NAT needs to perform stateful translation of > IPs and ports, residential routers on IPv6 only translate IPs but that > is not improving a lot. This sounds like the ISP or CPE vendor has not listened to +15 years of advice on how to deploy IPv6. You should be getting a prefix delegation from the ISP which is then redistributed to the inside network. The PD should be at least a /56 and preferably a /48. The prefix delegation can be delivered via 6RD if there isn't native IPv6. ULA is a additional prefix that provides stable internal addressing. NAT66 is not recommended and has even published several RFC that states exactly that opinion. RFC6296 For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. Where translation is implemented, however, this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful Network Address Translator in an IPv6 environment. It also provides a useful alternative to the complexities and costs imposed by multihoming using provider- independent addressing and the routing and network management issues of overlaid ISP address space. Some problems remain, however. The reader should consider the alternatives suggested in [RFC4864] and the considerations of [RFC5902] for improved approaches. If someone thinks NAT66 provides any effective security they need their head read. Internal addresses leak all over the place and once you have one all the internal machines are addressable. The only thing NAT66 provides is the ability to have a single IPv6 address per machine vs multiple IPv6 address internally which comes at a cost of requiring external equipement to be able to determine the effective GUA the machine has and more complicated software at the application level to work around the NAT. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 17 15:32:32 2016 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 1219412DBFC; Fri, 17 Jun 2016 15:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 4Ovb3yV5DZPW; Fri, 17 Jun 2016 15:32:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9413D12DBFB; Fri, 17 Jun 2016 15:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1466202748; x=1467412348; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uYO2xMeWPqEl5O8QFyfiGYJRSIDliwUty0PCV7/Tl0E=; b=hfObx0avZoDtz4F/oPcmF7lqVUe5wULPPFs84LX1mbOakoA3tYArdG19 7sPx4pzeuVFXPvj/vB33svrZ7IW6s3YjyOIsNjXHqBfZ+v76lS5rRIJ8Q l7SCv//h8/8DvZyKky8EfNfxOXBt4y5RhvkeNC22SJ/Jxgv8qeDg2BM7z I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDAeWRX/5RdJa1dgz6BUwaCUwsEr?= =?us-ascii?q?DWJc4IPgXqGFwKBJTgUAQEBAQEBAWUnhEsBAQEDAXkFCwIBCBguIRElAgQOBQ6?= =?us-ascii?q?ICAMPCL0HDYNeAQEBAQEBAQEBAQEBAQEBAQEBARAOiB6CVoJDgU8RAQaDQoIvB?= =?us-ascii?q?ZhBNAGDLYFqhxiBeoFTjU+ICodsAR42g3BuiRM2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,485,1459814400"; d="asc'?scan'208";a="116317886" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 22:32:27 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5HMWRRk006087 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 22:32:27 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 17:32:26 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 17:32:26 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRyOggeDyqZS3K60Gt+g5HwDkDsw== Date: Fri, 17 Jun 2016 22:32:26 +0000 Message-ID: References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.125] Content-Type: multipart/signed; boundary="Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , Erik Kline , "fgont@si6networks.com" , Brian E Carpenter Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 22:32:30 -0000 --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Jun 16, 2016, at 2:43 AM, Mark Smith wrote: > > If you truly want to hide a host from the Internet, yet still allow it > to access things on the Internet, under IPv6 your network would use > ULA addressing, and have a per-application protocol proxy server that > makes all requests look like they've entirely originated from the > application proxy server itself. To the Internet server, the > application proxy server would appear to be the application end host > making the requests, preventing any internal host identifiers or other > attributes from leaking. Even there, beware the email header. --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D 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 iQIVAwUBV2R6eUayAOS/EQ8MAQIfxxAAx1kxl9FIIKM7XJx0J3m0uOv+snjElwrE v0OyfiJgoYWCyEu4AYonSt+MnmsmSG7CeCmWcKygaYtA9d4mdJE/DD56CjeDhNFY xKAMsN3Pr7QF2rFO95vahudlcm6PMz/0Mr2sdMhOvk6xZgB67D/yx/O950RmaGms VctXAdU51PTfdl3nvGbG2NcrAY+G+aomTl2dFlmnIAULIy2WpYL0QtCRwhP67a7c zFDD4R++HWbOio1E3pQI55SEyzN1Zl0BgQcoo6d8ANPG7kRJYVdCC2k8/VrgK5Qi /WwRU8Fgw6oUJfU7Wu+BO5GWisSFzOsvlWhP+sR8FDTk/pzeBWecKNTLLBREuOGA baHf9nduwAUS9r/LW2tp/ha/eNP34ZRc/J8WLSheHnGncJ5aXm9Ag5E71ZJygmKi 76jHVAG8ZrRkXQi3wWuYZA575DsuFOgkNjHmnaCdDZwefMEVg7sE16GlzScM/jIB TaAGe2q1Y4hTd86H3v6cJtXmEq3Q2jvUxSV1EFy3lSIXkPtNPuMDlOHFfAvVHCpw pUryZvff9T0RoIGhoNqGTqPS3pHmIUF3efgFo8rw/ILEWHHhHvXpXR0aRV1T+SsF qIUMm4jS94nk/2oJdDg63ixgAFXXPuNmW+lXeRlPCWJ3DJyA0uo3rKWaRMXgW9hj GagE4wE2C3M= =eafK -----END PGP SIGNATURE----- --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D-- From nobody Mon Jun 20 01:53:20 2016 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 B94FA12B026 for ; Mon, 20 Jun 2016 01:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtTPgSbC6Vsz for ; Mon, 20 Jun 2016 01:53:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B16D312D54D for ; Mon, 20 Jun 2016 01:53:14 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BA0C9415F7119 for ; Mon, 20 Jun 2016 08:53:10 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5K8rCZ8017418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2016 08:53:12 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5K8r7e8031365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jun 2016 10:53:12 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.53]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 10:53:08 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: "opsec@ietf.org" Thread-Topic: One month out from IETF 96 - Submit your OPSEC drafts Thread-Index: AQHRytEqIapeISYWfUiTGrQ+NvaI2g== Date: Mon, 20 Jun 2016 08:53:07 +0000 Message-ID: <5399459C-0476-4D65-A8E6-F7CAD020CCE2@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_5399459C04764D65A8E6F7CAD020CCE2alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: [OPSEC] One month out from IETF 96 - Submit your OPSEC drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 08:53:18 -0000 --_000_5399459C04764D65A8E6F7CAD020CCE2alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJdCdzIHRoYXQgdGltZSBhZ2Fpbi4gd2UncmUgb25lIG1vbnRoIG91dCBmcm9t IElFVEYgOTYuDQpUaGUgZHJhZnQgc3VibWlzc2lvbiBkZWFkbGluZSAod2hpY2ggaXMgMjAxNi0w Ny0wOCkgYW5kIHN0YXJ0IG9mIHRoZSBkcmFmdCBhZ2VuZGFzIChzYW1lIGRhdGUpLg0KUGxlYXNl IHN1Ym1pdCB5b3VyIG5ldyBhbmQgdXBkYXRlZCBkcmFmdHMgYXMgcXVpY2tseSBhcyBwb3NzaWJs ZSwgZm9yIGJlc3QgY29tbXVuaXR5IGRpc2N1c3Npb24gb24gdGhlIGVtYWlsIGFsaWFzLg0KRHVl IHRvIHRoZSBob2xpZGF5IHNlYXNvbiBhcHByb2FjaGluZyB0aGlzIHdvdWxkIGJlIGJlbmVmaWNp YWwgdG8gYWxsb3cgbW9yZSBwZW9wbGUgdG8gZGlzY3VzcyB0aGUgZHJhZnRzLg0KDQpQcmVsaW1p bmFyeSBBZ2VuZGEgaXMgcHVibGlzaGVkIDE4IEp1bmUuDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvOTYvYWdlbmRhLmh0bWwNCg0KT25lIHRoaW5nIHRoYXQgbWF5IGJlIG9m IGludGVyZXN0IGlzIHRoZSBtYW55IEJPRnMgc2NoZWR1bGVkIGZvciB0aGlzDQptZWV0aW5nLA0K DQpodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvDQoNClNJUEJSQU5EWQ0KTEVE R0VSDQpNVEdWRU5VRQ0KSU1URw0KTFBXQU4NCklUUw0KQkFCRUwNCkxVUksNClNQQVNNDQpMNFMN ClFVSUMNClBMVVMNCg0KRmluYWxseSwgV2VkbmVzZGF5LCBKdW5lIDIyIDIwMTYgYXQgMjM6NTkg VVRDIGlzIHRoZSBEZWFkbGluZSBmb3INCnZvbHVudGVlcmluZyB0byBzZXJ2ZSBvbiB0aGUgbm9t Y29tLiBJbXBvcnRhbnRseSB5b3Ugc2hvdWxkIHByb2JhYmx5IG5vdA0Kdm9sdW50ZWVyIGlmIHlv dSBhcmUgaW50ZXJlc3RlZCBpbiBzZXJ2aW5nIGluIHRoZSBzb29uIHRvIGJlIHZhY2FudA0KT3Bl cmF0aW9ucyBBRCBTZWF0LiBTb21ldGltZSBhZnRlciBJRVRGIDk2IHRoZSB0aW1lbGluZSBmb3Ig dm9sdW50ZWVyaW5nDQpiZWdpbnMgZm9yIHRoZSAyIHllYXIgdGVybSBiZWdpbm5pbmcgd2l0aCB0 aGUgTWFyY2ggMjAxNyBJRVRGIDk4IG1lZXRpbmcNCmluIENoaWNhZ28uDQoNCklmIHlvdSB3b3Vs ZCBsaWtlIHRvIHRhbGsgdG8gdGhlIE9wZXJhdGlvbmFsIEFEcyBhYm91dCB0aGUgcm9sZSBvZiBB RCBvciB0aGUgY3VycmVudA0KcmVzcG9uc2liaWxpdGllcy93b3JrbG9hZC9JRVNHIGFjdGl2aXR5 LCB0aGUgT1BTIEFEcyBhcmUgaGFwcHkgdG8gZG8gc28uDQoNCktpbmQgUmVnYXJkcywNCkd1bnRl ciAmIEVyaWMNCg0KKE5vdGU6IHBhcnRzIG9mIHRoZSB0ZXh0IGFib3ZlIGhhcyBiZWVuIHJlbGF5 ZWQgZnJvbSBKb2VsIEphZWdnbGkpDQoNCg0KDQoNCg== --_000_5399459C04764D65A8E6F7CAD020CCE2alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbCw8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh Ij5JdCdzIHRoYXQgdGltZSBhZ2Fpbi4gd2UncmUgb25lIG1vbnRoIG91dCBmcm9tIElFVEYgOTYu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhl IGRyYWZ0IHN1Ym1pc3Npb24gZGVhZGxpbmUgKHdoaWNoIGlzIDIwMTYtMDctMDgpIGFuZCBzdGFy dCBvZiB0aGUgZHJhZnQgYWdlbmRhcyAoc2FtZSBkYXRlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+UGxlYXNlIHN1Ym1pdCB5b3VyIG5ldyBhbmQg dXBkYXRlZCBkcmFmdHMgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSwgZm9yIGJlc3QgY29tbXVuaXR5 IGRpc2N1c3Npb24gb24gdGhlIGVtYWlsIGFsaWFzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5EdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIGFwcHJv YWNoaW5nIHRoaXMgd291bGQgYmUgYmVuZWZpY2lhbCB0byBhbGxvdyBtb3JlIHBlb3BsZSB0byBk aXNjdXNzIHRoZSBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhIj5QcmVsaW1pbmFyeSBBZ2VuZGEgaXMgcHVibGlzaGVkIDE4IEp1bmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEuaHRtbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMzODZFRkYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy85Ni9hZ2VuZGEuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PbmUgdGhpbmcgdGhhdCBtYXkgYmUgb2YgaW50ZXJl c3QgaXMgdGhlIG1hbnkgQk9GcyBzY2hlZHVsZWQgZm9yIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+bWVldGluZyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxhIGhyZWY9Imh0dHBzOi8vdHJh Yy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg2RUZGIj5o dHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPlNJUEJSQU5EWTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5MRURHRVI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+TVRHVkVOVUU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+SU1URzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5MUFdBTjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JVFM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+QkFCRUw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+TFVSSzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5TUEFTTTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5MNFM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+UVVJQzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5QTFVTPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5GaW5hbGx5LCBXZWRu ZXNkYXksIEp1bmUgMjIgMjAxNiBhdCAyMzo1OSBVVEMgaXMgdGhlIERlYWRsaW5lIGZvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj52b2x1bnRlZXJp bmcgdG8gc2VydmUgb24gdGhlIG5vbWNvbS4gSW1wb3J0YW50bHkgeW91IHNob3VsZCBwcm9iYWJs eSBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+ dm9sdW50ZWVyIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBzZXJ2aW5nIGluIHRoZSBzb29uIHRv IGJlIHZhY2FudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhIj5PcGVyYXRpb25zIEFEIFNlYXQuIFNvbWV0aW1lIGFmdGVyIElFVEYgOTYgdGhlIHRpbWVs aW5lIGZvciB2b2x1bnRlZXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkhlbHZldGljYSI+YmVnaW5zIGZvciB0aGUgMiB5ZWFyIHRlcm0gYmVnaW5uaW5nIHdpdGgg dGhlIE1hcmNoIDIwMTcgSUVURiA5OCBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPmluIENoaWNhZ28uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JZiB5b3Ugd291bGQgbGlrZSB0byB0YWxr IHRvIHRoZSBPcGVyYXRpb25hbCBBRHMgYWJvdXQgdGhlIHJvbGUgb2YgQUQgb3IgdGhlIGN1cnJl bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+cmVz cG9uc2liaWxpdGllcy93b3JrbG9hZC9JRVNHIGFjdGl2aXR5LCB0aGUgT1BTIEFEcyBhcmUgaGFw cHkgdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EiPkd1bnRlciAmYW1wOyBFcmljPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4oTm90ZTogcGFydHMgb2YgdGhlIHRleHQgYWJv dmUgaGFzIGJlZW4gcmVsYXllZCBmcm9tIEpvZWwgSmFlZ2dsaSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5399459C04764D65A8E6F7CAD020CCE2alcatellucentcom_-- From nobody Mon Jun 20 01:57:26 2016 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 DBFDE12D54D for ; Mon, 20 Jun 2016 01:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuSw--c0wQdD for ; Mon, 20 Jun 2016 01:57:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 205C412B026 for ; Mon, 20 Jun 2016 01:57:24 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 22B814BBAD0AB for ; Mon, 20 Jun 2016 08:57:20 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5K8vL3G022893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2016 08:57:22 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5K8v2Zd009296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jun 2016 10:57:21 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.53]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 10:57:12 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: "opsec@ietf.org" Thread-Topic: IETF96 - Update your drafts & slots requests Thread-Index: AQHRytG7eT6F/QUtmkuguCtn2/UXGA== Date: Mon, 20 Jun 2016 08:57:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E16BEE490CC64E2BA3A4BCDF917DCC37alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: [OPSEC] IETF96 - Update your drafts & slots requests X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 08:57:26 -0000 --_000_E16BEE490CC64E2BA3A4BCDF917DCC37alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJRVRGOTYgaXMgYXBwcm9hY2hpbmcgZmFzdC4gRmlyc3QgaW1wb3J0YW50IGRh dGUgaXMgRnJpZGF5IDggSnVseSwgYnkgd2hpY2ggZHJhZnRzIG5lZWQgdG8gYmUgdXBkYXRlZCBm b3IgY29uc3VtcHRpb24gZHVyaW5nIElFVEY5NiBhY2NvcmRpbmc6DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tZWV0aW5nL2ltcG9ydGFudC1kYXRlcy0yMDE2Lmh0bWwjaWV0Zjk2DQoNClRvIGhlbHAg cGxhbiBmb3IgdGhlIElFVEY5NiBPUFNFQyBzbG90IGFnZW5kYSwgY2FuIHdlIGFzayBpZiB5b3Ug d2FudCB0byBkaXNjdXNzIGEgdG9waWMgb3IgZHJhZnQgZHVyaW5nIHRoZSBPUFNFQyBXRyBtZWV0 aW5nLg0KDQpLaW5kIFJlZ2FyZHMsDQpHdW50ZXIgJiBFcmljDQoNCg0KDQo= --_000_E16BEE490CC64E2BA3A4BCDF917DCC37alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+SGkg QWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPklFVEY5NiBpcyBhcHByb2FjaGluZyBmYXN0LiBG aXJzdCBpbXBvcnRhbnQgZGF0ZSBpcyBGcmlkYXkgOCBKdWx5LCBieSB3aGljaCBkcmFmdHMgbmVl ZCB0byBiZSB1cGRhdGVkIGZvciBjb25zdW1wdGlvbiBkdXJpbmcgSUVURjk2IGFjY29yZGluZzo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nL2ltcG9ydGFudC1kYXRlcy0yMDE2 Lmh0bWwjaWV0Zjk2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+VG8gaGVscCBwbGFuIGZvciB0aGUg SUVURjk2IE9QU0VDIHNsb3QgYWdlbmRhLCBjYW4gd2UgYXNrIGlmIHlvdSB3YW50IHRvIGRpc2N1 c3MgYSB0b3BpYyBvciBkcmFmdCBkdXJpbmcgdGhlIE9QU0VDIFdHIG1lZXRpbmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+S2luZCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+R3VudGVyICZhbXA7IEVyaWM8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E16BEE490CC64E2BA3A4BCDF917DCC37alcatellucentcom_-- From nobody Fri Jun 24 09:01:28 2016 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 342C012DBE7; Fri, 24 Jun 2016 09:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160039.10933.37164.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:39 -0700 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] opsec - Requested session has been scheduled for IETF 96 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:39 -0000 Dear Gunter Van de Velde, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. opsec Session 1 (1:30:00) Wednesday, Afternoon Session I 1400-1530 Room Name: Bellevue size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Gunter Van de Velde Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: sidr v6ops 6man opsawg homenet Special Requests: --------------------------------------------------------- From nobody Thu Jun 30 23:39:22 2016 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 DEA2E12D106 for ; Thu, 30 Jun 2016 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 yRdLjQJz66AE for ; Thu, 30 Jun 2016 23:39:17 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id BD01612B031 for ; Thu, 30 Jun 2016 23:39:17 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id AD234D65 for ; Fri, 1 Jul 2016 15:39:15 +0900 (JST) Received: from naist-wavenet125-010.naist.jp (naist-wavenet125-010.naist.jp [163.221.125.10]) by mailpost22.naist.jp (Postfix) with ESMTPSA id 969A7D64 for ; Fri, 1 Jul 2016 15:39:15 +0900 (JST) From: Marius Georgescu Content-Type: multipart/alternative; boundary="Apple-Mail=_7B6DBD59-924A-41AB-9AB4-42D1CD00D426" Message-Id: <03FBBCCE-0C05-42D5-BFF5-EA60B3C4344F@is.naist.jp> Date: Fri, 1 Jul 2016 15:39:15 +0900 To: opsec@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-22424.005 X-TM-AS-Result: No--0.921-5.0-31-10 X-imss-scan-details: No--0.921-5.0-31-10 X-TMASE-MatchedRID: vwD78yC1kfRITndh1lLRAco3MPo0IsVYRdLx1X9BVkDFl42goXCkIds1 CHzkaGoixAlB/Unww9vGsL5WCP9QGCAiNWreb6wwtT4jIeGRd/VcLdb1f78IiDyMVj6Ai0IjB7e 08gChx+UNaogSex9N1fd2aF2QFzbrSpUvxzuMUkYuRh8P8N2Qss1ifwukL7OfUNzg/KvQ9bAmcG wDr00+6jmSkgKMDxhG95xmrtlvofY/UOKwpH97lGg4D2QV/2zL6r3HCixfuKcML9Wb3Qh/hZFtq KECZLB3BBpBXZf7YnXy35i3dH4IqxQw0kr1znQQzr16YOzjZ13KIGMaZvT027QfSLTfZUi83SlE gVuyN9tvuYnoduGWEYAy6p60ZV620u+wqOGzSV3P/MyuVlT/C0tIkhusciGXoz8VuEzoU/aTiLu bGPBChfYaTuMh3Ep9TodM9he58CvfPYQq/g0nteg2uFMA8A4stjGz03lcNS2lRWC2lf7Hd7JdL5 1H2r0L4LS7TT0cZuSRe3tnl0jyR/laQGdhK9peNdT8ul95sTLgiP7BrQG5fV8nlxGpv2zV6UeoW 79euXNWQFObwcWj74RnruIQsuLGN62OXQXR7lpLhb8xGEnVfg== Archived-At: Subject: [OPSEC] A Threat Model for IPv6 Transition Technologies X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 06:39:20 -0000 --Apple-Mail=_7B6DBD59-924A-41AB-9AB4-42D1CD00D426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear OPSEC Members, Following the presentation in SAAG from IETF94 = (https://www.ietf.org/proceedings/94/slides/slides-94-saag-3.pdf), I've = written the following draft attempting to describe a threat model for = IPv6 transition technologies. The draft is at its second iteration, and if possible I would like to = discuss it in the next OPSEC session.=20 = https://tools.ietf.org/html/draft-georgescu-opsec-ipv6-trans-tech-threat-m= odel-01 = As an overview of the changes: *following Joel Jaeggli=E2=80=99s comment=20 +added a reference to the STRIDE threat model=20 *following a discussion with Fernando Gont=20 +redefined the Data Flow Diagram elements definitions=20 If time allows, your feedback would be very appreciated. Best regards, Marius Georgescu =E3=80=80(=E3=83=9E=E3=83=AA=E3=82=A6=E3=82=B9 = =E3=82=B8=E3=83=A7=E3=83=AB=E3=82=B8=E3=82=A7=E3=82=B9=E3=82=AF) Internet Engineering Laboratory=20 Nara Institute of Science and Technology=20 IPv6NET Project: http://www.ipv6net.ro/ --Apple-Mail=_7B6DBD59-924A-41AB-9AB4-42D1CD00D426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear OPSEC Members,

Following the presentation in = SAAG from IETF94 (https://www.ietf.org/proceedings/94/slides/slides-94-saag-3.pdf= ), I've written the following draft attempting to describe a threat = model for IPv6 transition technologies.
The draft is at its second = iteration, and if possible I would like to discuss it in the next OPSEC = session. 
https://tools.ietf.org/html/draft-georgescu-opsec-ipv6-trans-te= ch-threat-model-01
As an overview of the changes:

*following Joel Jaeggli=E2=80=99s= comment 
+added a = reference to the STRIDE threat model 
*following a discussion with = Fernando Gont 
= +redefined the Data Flow Diagram elements = definitions 

If time = allows, your feedback would be very appreciated.

Best regards,
Marius Georgescu = =E3=80=80(=E3=83=9E=E3=83=AA=E3=82=A6=E3=82=B9 = =E3=82=B8=E3=83=A7=E3=83=AB=E3=82=B8=E3=82=A7=E3=82=B9=E3=82=AF)
Internet Engineering = Laboratory 
Nara = Institute of Science and Technology 
IPv6NET Project: http://www.ipv6net.ro/



= --Apple-Mail=_7B6DBD59-924A-41AB-9AB4-42D1CD00D426--