From nobody Thu Mar 9 07:39:35 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC012965E for ; Thu, 9 Mar 2017 07:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hEk_GKmj35Ox for ; Thu, 9 Mar 2017 07:39:33 -0800 (PST) Received: from out.west.exch081.serverdata.net (cas081-co-7.exch081.serverdata.net [199.193.204.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB4112949E for ; Thu, 9 Mar 2017 07:39:32 -0800 (PST) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-2 (10.224.129.85) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 07:39:31 -0800 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 07:39:31 -0800 From: Jeff Ahrenholz To: Tom Henderson , Gonzalo Camarillo , HIP Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 Thread-Index: AQHSfUUiMmMxzUu5xUyi7rZbLtB96aFxEnMAgBvJsoA= Date: Thu, 9 Mar 2017 15:39:31 +0000 Message-ID: <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <662F36C61B231A4FAFD83B321FCCA7FD@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:39:34 -0000 PiAzKSBJbiBzZWN0aW9uIDQuMTAgKE5BVCBrZWVwYWxpdmVzKSwgaXQgc3RhdGVzOg0KPiAgICAN Cj4gICAgICAgIEJvdGggYSByZWdpc3RlcmVkIGNsaWVudCBhbmQgcmVsYXkgc2VydmVyIFNIT1VM RA0KPiAgICAgICAgc2VuZCBhIEhJUCBOT1RJRlkgcGFja2V0cyB0byBlYWNoIG90aGVyIGV2ZXJ5 IDE1IHNlY29uZHMgKHRoZSBzby0NCj4gICAgICAgIGNhbGxlZCBUciB2YWx1ZSBpbiBJQ0UpIHVu bGVzcyB0aGV5IGhhdmUgZXhjaGFuZ2Ugc29tZSBvdGhlciB0cmFmZmljDQo+ICAgICAgICBvdmVy IHRoZSB1c2VkIFVEUCBwb3J0cy4NCj4gICAgDQo+ICAgIEhvd2V2ZXIsIEkgY291bGRuJ3QgZmlu ZCBhbiBleHBsYW5hdGlvbiBhbnl3aGVyZSAoYWxzbyBpbiBSRkMgNTc3MCkgYWJvdXQNCj4gaG93 IHRvIGNvZGUgdGhpcyBOT1RJRlkuICBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGRlZmluZSBhbHNv IGEgIk5BVF9LRUVQQUxJVkUiDQo+IE5PVElGWSBtZXNzYWdlIHR5cGUgZm9yIHRoaXMgcHVycG9z ZT8NCg0KVG9tIGhhcyBhIGdvb2QgcG9pbnQgaGVyZSwgYWJvdXQgaG93IHRvIGNvZGUgdGhlIE5P VElGWSBrZWVwYWxpdmUuDQoNCkkgaGF2ZSBhIG1vcmUgZ2VuZXJhbCBxdWVzdGlvbiBhYm91dCBO QVQga2VlcGFsaXZlcyBiYXNlZCBvbiBzb21lIHJlY2VudCBleHBlcmllbmNlcyB3aXRoIGltcGxl bWVudGluZy9maWVsZGluZyB0aGlzIGFwcHJvYWNoLg0KKE15IGNvbW1lbnRzIGJlbG93IHNob3Vs ZG7igJl0IGhvbGQgdXAgdGhlIHB1Ymxpc2hpbmcgb2YgdGhpcyBkcmFmdC4uLikNCg0KSGF2ZSB3 ZSBjb25zaWRlcmVkIHVzaW5nIFVQREFURSBwYWNrZXRzIHZlcnN1cyBOT1RJRlk/DQpXaGF0IGFy ZSB0aGUgdHJhZGVvZmZzPw0KDQpJIHdhcyB0aGlua2luZyBhYm91dCB0aGUgZm9sbG93aW5nIGFk dmFudGFnZXMgb2YgdGhlIFVQREFURToNCi0gU0VRIHByb3RlY3RzIGFnYWluc3QgcGFja2V0IHJl cGxheXMNCi0gaW5zdGVhZCBvZiBlYWNoIGVuZHBvaW50IHBlcmlvZGljYWxseSB0eCBOT1RJRlks IG9uZSBzaWRlIGNvdWxkIHNlbmQgYW4gVVBEQVRFIGFuZCByZXF1ZXN0IGFja25vd2xlZGdlbWVu dCAoYSBiaS1kaXJlY3Rpb25hbCBjaGVjaykNCi0geW91IGNvdWxkIHNlbmQgYW4gVVBEQVRFIG9y IGFuIFVQREFURSBhY2tub3dsZWRnZW1lbnQgZXZlcnkgMTUgc2Vjb25kcyAobm8gbmVlZCBmb3Ig Ym90aCkNCi0gaWYgeW914oCZcmUgbm90IHNlbmRpbmcgZGF0YSwgYnV0IG9ubHkgcmVjZWl2aW5n LCB5b3UgY2FuIHN0aWxsIGRvIGEgYmktZGlyZWN0aW9uYWwgY2hlY2sgdG8gZW5zdXJlIGxpdmVu ZXNzIChhbmQgdmljZSB2ZXJzYSkNCi0geW91IGNhbiBpbmNsdWRlIEVTUF9JTkZPIHdpdGggU1BJ IG51bWJlciAob2xkIFNQSSA9PSBuZXcgU1BJKSwgd2hpY2ggd2lsbCBoZWxwIEhJUCBtaWRkbGVi b3hlcywgYW5kIHdpbGwgaGVscCBlbmRwb2ludHMga25vdyB3aGljaCBTQSBpcyBiZWluZyBrZXB0 IGFsaXZlDQotIE5PVElGWSBzaG91bGQgbm90IGJlIHVzZWQgdG8gY2hhbmdlIHN0YXRlIChSRkMg NzQwMSkNCg0KV2hhdCBoYXBwZW5zIGlmIHlvdSBkb27igJl0IHJlY2VpdmUga2VlcGFsaXZlcz8N Ci0gaWYgeW91ciBVUERBVEUgZ29lcyB1bmFja25vd2xlZGdlZCwgZG8gc29tZXRoaW5nIC0tIHJl dHJhbnNtaXQsIG9yIHN0YXJ0IGFuIGFkZHJlc3MgY2hlY2ssIHJla2V5LCBvciB0ZWFyZG93biBw cm9jZWR1cmUNCg0KUG90ZW50aWFsIGRyYXdiYWNrczoNCi0gaXMgVVBEQVRFIGNvbnNpZGVyZWQg dG9vIGhlYXZ5d2VpZ2h0Pw0KLSBVUERBVEUgZG9lc27igJl0IGhhdmUgYSBwdXJwb3NlIGNvZGUs IGlzIHRoZSBzd2lzcyBhcm15IGtuaWZlIG9mIEhJUCBwYWNrZXRzIChyZWtleSwgcmVhZGRyZXNz LCBhZGRyZXNzIGNoZWNrLCBldGMuKQ0KLSBVUERBVEUgcmVxdWlyZXMgZXN0YWJsaXNoZWQgc3Rh dGU7IE5PVElGWSBkb2VzIG5vdA0KDQp0aGFua3MsDQotSmVmZg0KDQo= From nobody Thu Mar 9 08:02:06 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9D1293FC for ; Thu, 9 Mar 2017 08:02:05 -0800 (PST) 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_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 QIKwvpefOmMZ for ; Thu, 9 Mar 2017 08:02:03 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A110129407 for ; Thu, 9 Mar 2017 08:02:03 -0800 (PST) X-AuditID: c1b4fb30-84e7298000007a5b-e7-58c17c79710c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id AF.3A.31323.97C71C85; Thu, 9 Mar 2017 17:02:01 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Thu, 9 Mar 2017 17:01:57 +0100 To: Jeff Ahrenholz , Tom Henderson , Gonzalo Camarillo , HIP References: <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com> From: Miika Komu Organization: Ericsson AB Message-ID: <6c9e9624-537d-3355-772f-23212543c9d9@ericsson.com> Date: Thu, 9 Mar 2017 18:01:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7t25lzcEIgzv9chZTF01mtmidcpPZ Yub5g2wOzB5Llvxk8ti6p5PFo+V6TABzFJdNSmpOZllqkb5dAldG18UupoLlkhUtS46xNzC+ E+5i5OSQEDCR+PlsOksXIxeHkMA6Rond3xexQTirGSWazz9iBakSFnCSmNP/nhEkIQJSNXfS TqiqvYwSt3csYAOpYhPQklh15zoziM0vICmxoWE3mM0rYC/xaMtZJhCbRUBFYvffLWBxUYEI iflPVzFB1AhKnJz5BOgODg5OAQ+J3jWyIGFmAQuJmfPPM0LY2hLLFr5mBikRAhpz8VjwBEaB WUiaZyHpmIWkYwEj8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwFA9uOW3wQ7Gl88dDzEK cDAq8fB+yD0YIcSaWFZcmXuIUYKDWUmEV7sSKMSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9 cCGB9MSS1OzU1ILUIpgsEwenVAOjltqcRu7usOttTCsMX6/u2brEkmNt0sJJflYmOseSL9QV LCmrv7F84tkgg41zb8zWPam37ZJqUnNM2WNd5Tz7yIVq/8zLph08pbS+db5/j79ej9sfxdWN BxlEl++wuym57vltbVf+fPGJ6xzlKw+VLeM/s1OaLX7WpJy7axtqdm1n+RUTeOOAEktxRqKh FnNRcSIA27yFlFECAAA= Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:02:05 -0000 Hi Jeff, On 03/09/2017 05:39 PM, Jeff Ahrenholz wrote: >> 3) In section 4.10 (NAT keepalives), it states: >> >> Both a registered client and relay server SHOULD >> send a HIP NOTIFY packets to each other every 15 seconds (the s= o- >> called Tr value in ICE) unless they have exchange some other tr= affic >> over the used UDP ports. >> >> However, I couldn't find an explanation anywhere (also in RFC 5770)= about >> how to code this NOTIFY. Would it make sense to define also a "NAT_KE= EPALIVE" >> NOTIFY message type for this purpose? > > Tom has a good point here, about how to code the NOTIFY keepalive. yes, I agree. The document lists also another option: 4.10. NAT Keepalives Likewise, if a host has not sent any data to another host it has established a host association in the ICE-HIP_UDP mode within 15 seconds, it MUST send either a HIP NOTIFY packet or, alternatively, an ICMPv6 echo request inside the related ESP tunnel. Actually ICMPv6 would be my personal choice as a implementer instead of=20 NOTIFY. You can also detect connectivity problems at the data plane this = way and trigger a LOCATOR UPDATE. (ICMPv6 is not a control plane keepalive, but since the control and data = plane share the same port, this does not matter.) > I have a more general question about NAT keepalives based on some recen= t experiences with implementing/fielding this approach. > (My comments below shouldn=E2=80=99t hold up the publishing of this dra= ft...) > > Have we considered using UPDATE packets versus NOTIFY? > What are the tradeoffs? This is possible, but probably three options is too much? > I was thinking about the following advantages of the UPDATE: > - SEQ protects against packet replays > - instead of each endpoint periodically tx NOTIFY, one side could send = an UPDATE and request acknowledgement (a bi-directional check) > - you could send an UPDATE or an UPDATE acknowledgement every 15 second= s (no need for both) > - if you=E2=80=99re not sending data, but only receiving, you can still= do a bi-directional check to ensure liveness (and vice versa) > - you can include ESP_INFO with SPI number (old SPI =3D=3D new SPI), wh= ich will help HIP middleboxes, and will help endpoints know which SA is b= eing kept alive > - NOTIFY should not be used to change state (RFC 7401) Only one side sending the UPDATE is possible because the CONTROLLED role = remains throughout the session. > What happens if you don=E2=80=99t receive keepalives? > - if your UPDATE goes unacknowledged, do something -- retransmit, or st= art an address check, rekey, or teardown procedure Good point. > Potential drawbacks: > - is UPDATE considered too heavyweight? > - UPDATE doesn=E2=80=99t have a purpose code, is the swiss army knife o= f HIP packets (rekey, readdress, address check, etc.) > - UPDATE requires established state; NOTIFY does not UPDATE is certainly more heavy-weight especially since it occurs every=20 15 seconds. We have three choices of which we could select just one or=20 two (probably three is too much): 1. ICMPv6 2. NOTIFY 3. UPDATE What do you think? From nobody Thu Mar 9 08:23:13 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670A012969F for ; Thu, 9 Mar 2017 08:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 iDsWpCNDxW_T for ; Thu, 9 Mar 2017 08:23:11 -0800 (PST) Received: from out.west.exch081.serverdata.net (cas081-co-4.exch081.serverdata.net [199.193.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617AE129430 for ; Thu, 9 Mar 2017 08:23:11 -0800 (PST) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 08:23:09 -0800 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 08:23:09 -0800 From: Jeff Ahrenholz To: Miika Komu , Tom Henderson , Gonzalo Camarillo , HIP Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 Thread-Index: AQHSfUUiMmMxzUu5xUyi7rZbLtB96aFxEnMAgBvJsoCAAIxTgP//f96A Date: Thu, 9 Mar 2017 16:23:09 +0000 Message-ID: References: <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com> <6c9e9624-537d-3355-772f-23212543c9d9@ericsson.com> In-Reply-To: <6c9e9624-537d-3355-772f-23212543c9d9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <89ACB3A95F488449B6F1A0D7CAB87E46@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:23:12 -0000 PiBBY3R1YWxseSBJQ01QdjYgd291bGQgYmUgbXkgcGVyc29uYWwgY2hvaWNlIGFzIGEgaW1wbGVt ZW50ZXIgaW5zdGVhZCBvZiANCj4gTk9USUZZLiBZb3UgY2FuIGFsc28gZGV0ZWN0IGNvbm5lY3Rp dml0eSBwcm9ibGVtcyBhdCB0aGUgZGF0YSBwbGFuZSB0aGlzIA0KPiB3YXkgYW5kIHRyaWdnZXIg YSBMT0NBVE9SIFVQREFURS4NCj4gICAgDQo+IChJQ01QdjYgaXMgbm90IGEgY29udHJvbCBwbGFu ZSBrZWVwYWxpdmUsIGJ1dCBzaW5jZSB0aGUgY29udHJvbCBhbmQgZGF0YSANCj4gcGxhbmUgc2hh cmUgdGhlIHNhbWUgcG9ydCwgdGhpcyBkb2VzIG5vdCBtYXR0ZXIuKQ0KDQpJIGZvcmdvdCBhYm91 dCB0aGF0IOKAmHBpbmc2IGRlc3RpbmF0aW9uLUhJVOKAmSBpbnNpZGUtdGhlLXR1bm5lbCBvcHRp b24uDQoNCkNlcnRhaW5seSwgdGhpcyB3b3VsZCBiZSBhIGdvb2QgdGVzdCBvZiB0dW5uZWwgbGl2 ZWxpbmVzcy4NCiANCknigJltIGEgbGl0dGxlIGNvbmNlcm5lZCBhYm91dCBpbXBsZW1lbnRhdGlv biBvZiB0aGlzIC0tIGlmIHlvdSB0aGluayBhYm91dCB0aGUgY29udHJvbCBwbGFuZSBkaWZmZXJp bmcgZnJvbSB0aGUgZGF0YSBwbGFuZSAoaS5lLiBtYXliZSB1c2Vyc3BhY2UgY29udHJvbCBkYWVt b24gbWFuYWdpbmcga2VybmVsIElQc2VjIHN0YXRlLikgVGhlIGNvbnRyb2wgcGxhbmUgd291bGQg YmUgcmVhY2hpbmcgaW50byB0aGUgZGF0YSBwbGFuZS4gV2hhdCBpZiBzeXNhZG1pbiBhZG1pbmlz dHJhdGl2ZWx5IHR1cm5lZCBvZmYgcGluZzYgZWNobyByZXBsaWVzLCBsb2NhbCBmaXJld2FsbCBi bG9ja3MsIGV0Yy4/DQoNCj4gT25seSBvbmUgc2lkZSBzZW5kaW5nIHRoZSBVUERBVEUgaXMgcG9z c2libGUgYmVjYXVzZSB0aGUgQ09OVFJPTExFRCByb2xlDQo+IHJlbWFpbnMgdGhyb3VnaG91dCB0 aGUgc2Vzc2lvbi4NCg0KT0ssIHRoaXMgbWFrZXMgc2Vuc2UuIFRoZSBjb250cm9sbGVyIFtob3N0 IGhhdmluZyB0aGUgbGFyZ2VyIEhJVF0gY2FuIHNlbmQgdGhlIFVQREFURXMuDQogICAgDQo+PiBX aGF0IGhhcHBlbnMgaWYgeW91IGRvbuKAmXQgcmVjZWl2ZSBrZWVwYWxpdmVzPw0KPj4gLSBpZiB5 b3VyIFVQREFURSBnb2VzIHVuYWNrbm93bGVkZ2VkLCBkbyBzb21ldGhpbmcgLS0gcmV0cmFuc21p dCwgb3Igc3RhcnQgYW4gYWRkcmVzcyBjaGVjaywgcmVrZXksIG9yIHRlYXJkb3duIHByb2NlZHVy ZQ0KPiAgICANCj4gR29vZCBwb2ludC4NCg0KTm90ZSB0aGF0IGp1c3QgdXNpbmcgTk9USUZZLCB3 ZeKAmXJlIE5PVCBzdXBwb3NlZCB0byBjaGFuZ2Ugc3RhdGUgKFJGQyA3NDAxIHNlY3Rpb24gNS4y LjE5KS4NClNvIEkgZ3Vlc3MgcmVhY3RpbmcgdG8gbG9zdCBOT1RJRlkta2VlcGFsaXZlcyBpcyBm b3JiaWRkZW4gKD8pLg0KDQo+IFVQREFURSBpcyBjZXJ0YWlubHkgbW9yZSBoZWF2eS13ZWlnaHQg ZXNwZWNpYWxseSBzaW5jZSBpdCBvY2N1cnMgZXZlcnkgDQo+IDE1IHNlY29uZHMuIFdlIGhhdmUg dGhyZWUgY2hvaWNlcyBvZiB3aGljaCB3ZSBjb3VsZCBzZWxlY3QganVzdCBvbmUgb3IgDQo+IHR3 byAocHJvYmFibHkgdGhyZWUgaXMgdG9vIG11Y2gpOg0KPiAgICANCj4gICAxLiBJQ01QdjYNCj4g ICAyLiBOT1RJRlkNCj4gICAzLiBVUERBVEUNCj4gICAgDQo+IFdoYXQgZG8geW91IHRoaW5rPw0K DQpNYXliZSB3ZSBjb3VsZCBsZWF2ZSB0aGUgZG9vciBvcGVuIGZvciBpbXBsZW1lbnRhdGlvbiBm bGV4aWJpbGl0eT8NCg0KV2hpbGUgdGhyZWUgb3B0aW9ucyBpcyBhIGJpdCBtdWNoLCBpdCBzZWVt cyB2ZXJ5IGZsZXhpYmxlIHRvIGFsbG93IGZvciAxLCAyLCBhbmQvb3IgMy4NCg0KKOKAnFRocmVl IHNoYWxsIGJlIHRoZSBudW1iZXIgb2YgdGhlIGNvdW50aW5nIGFuZCB0aGUgbnVtYmVyIG9mIHRo ZSBjb3VudGluZyBzaGFsbCBiZSB0aHJlZS7igJ0pDQoNCi1KZWZmDQogICAgDQoNCg== From nobody Tue Mar 14 01:53:50 2017 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE112952C; Tue, 14 Mar 2017 01:53:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148948161855.12733.73716147041261789@ietfa.amsl.com> Date: Tue, 14 Mar 2017 01:53:38 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-18.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:53:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan MelĂ©n Miika Komu Filename : draft-ietf-hip-native-nat-traversal-18.txt Pages : 52 Date : 2017-03-13 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 14 02:19:37 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A359129531 for ; Tue, 14 Mar 2017 02:19:36 -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_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 ryoNuZ5aMxob for ; Tue, 14 Mar 2017 02:19:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693FF129524 for ; Tue, 14 Mar 2017 02:19:33 -0700 (PDT) X-AuditID: c1b4fb30-25b3698000007738-41-58c7b5a349d0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 41.4E.30520.3A5B7C85; Tue, 14 Mar 2017 10:19:31 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Mar 2017 10:19:28 +0100 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: Date: Tue, 14 Mar 2017 11:19:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7h+7irccjDH51KVhMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGQcbrzMWzOeouP9+D0sD4122LkZODgkBE4kJiy8zgthCAusY JTp/m3QxcgHZa4Ds73uYQRLCAk4Sc/rfgxWJCIhKTPlwGijOAVTkKbFymhZImE1AS2LVnetg 5fwCkhIbGnaD2bwC9hKf7rSD2SwCqhK9G9eAjREViJCY/3QVE0SNoMTJmU9YQGxOAS+Je7vP soOMZwbqfbC1DCTMLCAvsf3tHKitKhIXjwVPYBSYhaR5FkLDLCQNCxiZVzGKFqcWJ+WmGxnp pRZlJhcX5+fp5aWWbGIEht7BLb8NdjC+fO54iFGAg1GJh/fD5mMRQqyJZcWVuYcYJTiYlUR4 /648HiHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD44YJ 3if0N0YelRB6cVK9+tLUwxp+R+dmMatLPj255Mu9j9dXLTo/gX+mm0vN++qj3+ZN1j/JpPM1 vPjm/bqKfue7pb+0rsxgu1eewzdHMkwtLrCQweO6ipio+96meW3LTn//Me0X67P0yz5sqlGL yn5rnXvsy1P/c4d5ktra/aVBT/Qf3At8oajEUpyRaKjFXFScCADkSfLqOQIAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:19:36 -0000 Hi Tom, On 02/19/2017 05:18 PM, Tom Henderson wrote: > Hello, I have read the latest (-17) draft and sent some purely editorial > comments to Miika. I had a few non-editorial questions and comments. thanks for the feedback. I fixed the editorial issues in version 18: There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-18 I did not fix these (because I would prefer to keep the artwork small): * Figure acronym un-abbreviations were not included * ISPI and OSPI acronyms remain (Also, if we use long parameter names in figures, I think all names should be long, not just mobility related) A couple of fixes for me to edit: * Appendix B: normative vs non-normative terminology * Alex Elsayed reported imbalanced parentheses in one picture These and the non-editorial comments from Tom and Jeff will be resolved in the next version. From nobody Tue Mar 14 11:20:34 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D4127149 for ; Tue, 14 Mar 2017 11:20:33 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BZVQ5k7wrkPZ for ; Tue, 14 Mar 2017 11:20:31 -0700 (PDT) Received: from mxout23.cac.washington.edu (mxout23.cac.washington.edu [140.142.32.140]) (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 A8B0F12700C for ; Tue, 14 Mar 2017 11:20:29 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout23.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id v2EIJ57D011250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:19:05 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id v2EIIvSs029674; Tue, 14 Mar 2017 11:18:57 -0700 Received: from localhost (Unknown UID 5340@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id v2EIIv81029668; Tue, 14 Mar 2017 11:18:57 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Tue, 14 Mar 2017 11:18:57 PDT Date: Tue, 14 Mar 2017 11:18:57 -0700 (PDT) From: Tom Henderson To: Miika Komu cc: hipsec@ietf.org In-Reply-To: Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.14.181217 X-PMX-Server: mxout23.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:20:33 -0000 On Tue, 14 Mar 2017, Miika Komu wrote: > Hi Tom, > > On 02/19/2017 05:18 PM, Tom Henderson wrote: >> Hello, I have read the latest (-17) draft and sent some purely editorial >> comments to Miika. I had a few non-editorial questions and comments. > > thanks for the feedback. I fixed the editorial issues in version 18: > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-18 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-18 > > I did not fix these (because I would prefer to keep the artwork small): > > * Figure acronym un-abbreviations were not included > * ISPI and OSPI acronyms remain > > (Also, if we use long parameter names in figures, I think all names should be > long, not just mobility related) Miika, as I was preparing those editorial comments and I read onward, I realized that addressing some of my comments might raise some internal consistency issues, or cause some more significant editing, so I am fine if you decide that they are too disruptive. - Tom From nobody Tue Mar 14 11:32:26 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635E12997F for ; Tue, 14 Mar 2017 11:32:24 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OZWU1KENSQ3j for ; Tue, 14 Mar 2017 11:32:23 -0700 (PDT) Received: from mxout23.cac.washington.edu (mxout23.cac.washington.edu [140.142.32.140]) (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 659C112E799 for ; Tue, 14 Mar 2017 11:32:22 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout23.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id v2EITrqn014337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:29:54 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id v2EITqBQ023064; Tue, 14 Mar 2017 11:29:52 -0700 Received: from localhost (Unknown UID 5340@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id v2EITqm2023036; Tue, 14 Mar 2017 11:29:52 -0700 X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Tue, 14 Mar 2017 11:29:52 PDT Date: Tue, 14 Mar 2017 11:29:52 -0700 (PDT) From: Tom Henderson To: Jeff Ahrenholz cc: Miika Komu , Gonzalo Camarillo , HIP In-Reply-To: Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409400-9170010-1489516192=:27473" X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.14.182117 X-PMX-Server: mxout23.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:32:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1903409400-9170010-1489516192=:27473 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-7 Content-Transfer-Encoding: 8BIT On Thu, 9 Mar 2017, Jeff Ahrenholz wrote: >> Actually ICMPv6 would be my personal choice as a implementer instead of >> NOTIFY. You can also detect connectivity problems at the data plane this >> way and trigger a LOCATOR UPDATE. >> >> (ICMPv6 is not a control plane keepalive, but since the control and data >> plane share the same port, this does not matter.) > > I forgot about that ˇping6 destination-HIT˘ inside-the-tunnel option. > > Certainly, this would be a good test of tunnel liveliness. > > I˘m a little concerned about implementation of this -- if you think about the control plane differing from the data plane (i.e. maybe userspace control daemon managing kernel IPsec state.) The control plane would be reaching into the data plane. What if sysadmin administratively turned off ping6 echo replies, local firewall blocks, etc.? > >> Only one side sending the UPDATE is possible because the CONTROLLED role >> remains throughout the session. > > OK, this makes sense. The controller [host having the larger HIT] can send the UPDATEs. > >>> What happens if you don˘t receive keepalives? >>> - if your UPDATE goes unacknowledged, do something -- retransmit, or start an address check, rekey, or teardown procedure >> >> Good point. > > Note that just using NOTIFY, we˘re NOT supposed to change state (RFC 7401 section 5.2.19). > So I guess reacting to lost NOTIFY-keepalives is forbidden (?). > >> UPDATE is certainly more heavy-weight especially since it occurs every >> 15 seconds. We have three choices of which we could select just one or >> two (probably three is too much): >> >> 1. ICMPv6 >> 2. NOTIFY >> 3. UPDATE >> >> What do you think? > > Maybe we could leave the door open for implementation flexibility? I might suggest to recommend NOTIFY (and define the keepalive) and state that other messages including ICMPv6 or UPDATE may be substituted. If there is a need for bi-directional connectivity checking, recommend to use UPDATE; if there are specific known scenarios where an ICMPv6 is recommended instead, state those scenarios. - Tom ---1903409400-9170010-1489516192=:27473-- From nobody Wed Mar 15 06:11:14 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EC6131493 for ; Wed, 15 Mar 2017 06:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKsK3HRZH28n for ; Wed, 15 Mar 2017 06:11:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 67283131492 for ; Wed, 15 Mar 2017 06:11:11 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-d3-58c93d6d74c0 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 37.4E.24979.D6D39C85; Wed, 15 Mar 2017 14:11:09 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 14:10:19 +0100 From: Miika Komu To: Tom Henderson , Jeff Ahrenholz CC: HIP Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 Thread-Index: AQHSfUUiv8rMzViTdEKgMh/yMEwd8qFwe5MAgBxPz4CAACe9gP//5HSAgAf/DwCAAT2T0A== Date: Wed, 15 Mar 2017 13:10:18 +0000 Message-ID: <7110ABD9BA66454293AEE83D6D37016617B30AA9@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006C_01D29D9E.415FD9C0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7hG6u7ckIg+4fJhZTF01mtmidcpPZ Yub5g2wOzB5Llvxk8ti6p5PFo+V6TABzFJdNSmpOZllqkb5dAlfG4f5FTAWnkir+bj7D2MB4 P6qLkZNDQsBEYmX/G8YuRi4OIYF1jBLtX9ZDOYsZJV7uWcQKUsUmoCWx6s51ZhBbRCBRYvOG 2WwgNrOApMTyTb/AbGEBJ4n5808zQtQ4S7x5dp4Jwg6TWLv7BVgNi4CqxM9zZ8Bm8gr4Sqy+ eY8ZYlk7o8T+Oz/BFnAKeEl8OzcNrIhRQFZi5eZ/zBDLxCVuPZnPBHG2iMTDi6fZIGxRiZeP /7FC2IoSV6cvZwIZyizQyyixqHkXE8Q2QYmTM5+wTGAUmYVk1ixkdbOQ1EEUGUjM2z4TypaX 2P52DjOEbS0x49dBNghbUWJK90N2CNtU4vXRj4wLGDlWMYoWpxYX56YbGeulFmUmFxfn5+nl pZZsYgRG4sEtv3V3MK5+7XiIUYCDUYmHt4D1RIQQa2JZcWXuIUYVoDmPNqy+wCjFkpefl6ok wvuaASjNm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDo/fT k74NJWIcAYe5ao/r9UTuumZofS9Cp1frya8STasJHGbna0/2NLvFzbvjsVolj1NPW7Px/KSO rwseZP+yMNMrLPEKvdVUMK+Zo70r7J9NSk3Jlpv6BRt3MJff+uw3J0B8kqaZiUxGnKFkorxF 0jn2SYkZmV/TzM/XPhSfOjOYuc+Uf4cSS3FGoqEWc1FxIgCxznxMzAIAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:11:13 -0000 ------=_NextPart_000_006C_01D29D9E.415FD9C0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Hi Tom and Jeff, > -----Original Message----- > From: Tom Henderson [mailto:tomhend@u.washington.edu] > Sent: Tuesday, March 14, 2017 8:30 PM > To: Jeff Ahrenholz > Cc: Miika Komu ; Gonzalo Camarillo > ; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 > > > > > On Thu, 9 Mar 2017, Jeff Ahrenholz wrote: > > >> Actually ICMPv6 would be my personal choice as a implementer instead > >> of NOTIFY. You can also detect connectivity problems at the data > >> plane this way and trigger a LOCATOR UPDATE. > >> > >> (ICMPv6 is not a control plane keepalive, but since the control and > >> data plane share the same port, this does not matter.) > > > > I forgot about that ?ping6 destination-HIT? inside-the-tunnel option. > > > > Certainly, this would be a good test of tunnel liveliness. > > > > I?m a little concerned about implementation of this -- if you think about the > control plane differing from the data plane (i.e. maybe userspace control > daemon managing kernel IPsec state.) The control plane would be reaching > into the data plane. What if sysadmin administratively turned off ping6 echo > replies, local firewall blocks, etc.? Jeff, this would occur *inside* the tunnel, so it would be prevented in the end-host directly (which seems a bit unlikely scenario to me) > >> Only one side sending the UPDATE is possible because the CONTROLLED > >> role remains throughout the session. > > > > OK, this makes sense. The controller [host having the larger HIT] can send > the UPDATEs. thinking about this option further, I think it's probably not a good idea after all to enforce the controlling host send UPDATEs every 15 seconds: 1. A server connected to a large number of clients would get too much unnecessary computational load 2. This option would trump the rest of the options - Detection logic would be become cumbersome (node has to decide based on the other side if e.g. ICMPv6 keepalives are needed) - So it would be easier just to implement controlled host sending UPDATEs (which leads to [1]) > >>> What happens if you don?t receive keepalives? > >>> - if your UPDATE goes unacknowledged, do something -- retransmit, or > >>> start an address check, rekey, or teardown procedure > >> > >> Good point. > > > > Note that just using NOTIFY, we?re NOT supposed to change state (RFC > 7401 section 5.2.19). > > So I guess reacting to lost NOTIFY-keepalives is forbidden (?). NOTIFY messages are not acked anyway. They are sent every 15 secs, so couple of them can be easily lost. (ICE keepalives don't have acknowledgements either) > >> UPDATE is certainly more heavy-weight especially since it occurs > >> every > >> 15 seconds. We have three choices of which we could select just one > >> or two (probably three is too much): > >> > >> 1. ICMPv6 > >> 2. NOTIFY > >> 3. UPDATE > >> > >> What do you think? > > > > Maybe we could leave the door open for implementation flexibility? > > I might suggest to recommend NOTIFY (and define the keepalive) and state > that other messages including ICMPv6 or UPDATE may be substituted. If > there is a need for bi-directional connectivity checking, recommend to use > UPDATE; if there are specific known scenarios where an ICMPv6 is > recommended instead, state those scenarios. Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I think we shouldn't device a new UPDATE mechanism tied to controlled role (sorry for thinking aloud :) Jeff, is this ok for you? ------=_NextPart_000_006C_01D29D9E.415FD9C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVSDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF5TCCA82gAwIBAgIQ CXbYhDs+Bd6DT7LMTmx+xjANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMTUxMjQ0MDFaFw0xNzEy MTUxMjQ0MDBaMGIxETAPBgNVBAoMCEVyaWNzc29uMRMwEQYDVQQDDApNaWlrYSBLb211MSYwJAYJ KoZIhvcNAQkBFhdtaWlrYS5rb211QGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZW1paWtvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALH9qYMGG1V8YcfsML8K0uauerS6BIZwVLG9yRty h2AE430K8sibA35/dGBzJePX1xTkQ7RTtTzwPkAdtsrrIAi4Y4GsHJGJ91wc4qQpcU6tVB8TatNY v0cwaLXa1VmDMj+CprAc7IP76dAbuSo5bT+lQRqXDovI7lXly9dLjYeF6ZwW2hKtrlYmSTh/fpkq 9CBIIeMv5RGSp5SBqXMt75WC+EuFYZvCMfV/CDb3lrkzHaNqHdY/X3RCYLb93IOSjdvofqSN6DfJ +YpL9cbOZGgwmBbpy1JzA4JZHAE/JNXm6i1dI0FDUpbwwgdoazs1RT8hMnG9GTW19QJDk1Z5azcC AwEAAaOCAb0wggG5MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29t L2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcw AYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRy dXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2VyMCIGA1UdEQQb MBmBF21paWthLmtvbXVAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDow OAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BT MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUE5xw4Ol3sTrXWf6jJJ90 BymQlWQwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0G CSqGSIb3DQEBBQUAA4ICAQC0lTA+gv7GWc+N8Cdq/x6fAbQYoKSnOgrl+tL5pM0PLxq8XjWzyZpA uehUnhrRaPOQ7ReescgXe9OE9fI69bR0162vHDT9+6gAWM4Gi2i7ho7anDpxkGP/9GUHyyQXyiZ5 SR1/WQfkBT24cKThZvUDNqEWBbHtBo3PC1d1idIzFDL2QxcmKGXkPrGpPpjm7E0X5Edr7LrgeBJa ODErnQpmaqhVFO4AZqd+htskiS7f7SZSQ5XfnoCST9YF5xpMFtp99xpHMvklS49Akk8su+homz6e 9gIrkf8M/hiGgoENwD1W1l5Ad5XeGr56PjKtruvtqmKYWLJmMCLOUlLIemZ9TkFjSlLW2W7Ns+AC 0GwN6x5p3SPHi3+M+2ajC+lAc60I7pFotOg/Mlezly8/08wa6dbHT6TaQ1UhFprgtHSd0aPFCTi4 jvdSrSysE2Dj1ZYPrutgOb2Deg1ck5wZLM+QqVIlTe8dwwwHI2qzkUJ7XqCMAWjnmXfyWSW6/dNF BDprfWi154fLxWTjse3W9F3HG1juO98jp7fyq/V1+bdpLxUJzUhCN0ZBajNOs/q+VomXfgYRiT0l PNEDTic86BF0+vQ4oYVoRaUoqxQ1egnVEsSqBQ//KiJAdkF7kFBEjdFlAbhsthzriKp8fgSEeXxh bGohRGOaVyx3krwcgG98kzCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3 DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290 IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7K Pv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm +Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzY f1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5n y0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyI QZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQw dro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6Wpji vLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769 om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM 9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcw AYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIw EgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUF BwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8E RDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJh cm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMC AQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM 1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL 1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiP mY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh9 7ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU 8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6I eCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B 7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+w xC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI8 9wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8 c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCAtswggLXAgEBME4wOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEAl22IQ7PgXeg0+y zE5sfsYwCQYFKw4DAhoFAKCCAWIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwMzE1MTMxMDE3WjAjBgkqhkiG9w0BCQQxFgQUBMEX6rU3nO7zrq177N6ZFutir3Aw QwYJKoZIhvcNAQkPMTYwNDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG 9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwDQYJKoZIhvcNAQEBBQAEggEAaN3dHOij 6QNkGdI72HHZihS/RHkR4h1rWjdK//5yemg8g9asOrq3N+O8J+j/cUjdjfjayavEXW5Ppm0vi6Nh ff3q/zR0vjNtqAgtOeQO+H1vZlZq685teQ2rYElUFh4XvM5puncfANTP06QpfV/tqXxojd6VsFoJ ZEZrXBoPW4gVS4ZS0LgkMNFEE9JloAl1j92xe3uUxGObZ9wShKm4xRzTX1KiHXK++Y3LRYFbSAeL fIX27NbP/mxS9sGZeBKRYv8QOeECPZx+segVwLmJZFkbueN0b/g6BzTMlIva9nKKnx4jNQrC6Vcu Ph4VsnQbS47bxDkz+gyDpDlwYyAPyQAAAAAAAA== ------=_NextPart_000_006C_01D29D9E.415FD9C0-- From nobody Wed Mar 15 07:37:41 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEB21315A8 for ; Wed, 15 Mar 2017 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RmE7RgAdmQTY for ; Wed, 15 Mar 2017 07:37:32 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-6.exch081.serverdata.net [199.193.204.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FD913157F for ; Wed, 15 Mar 2017 07:37:31 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Mar 2017 07:37:30 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Wed, 15 Mar 2017 07:37:30 -0700 From: Jeff Ahrenholz To: Miika Komu , Tom Henderson CC: HIP Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 Thread-Index: AQHSfUUiMmMxzUu5xUyi7rZbLtB96aFxEnMAgBvJsoCAAIxTgP//f96AgAh0aQCAATkLAP//owUA Date: Wed, 15 Mar 2017 14:37:30 +0000 Message-ID: References: <7110ABD9BA66454293AEE83D6D37016617B30AA9@ESESSMB109.ericsson.se> In-Reply-To: <7110ABD9BA66454293AEE83D6D37016617B30AA9@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <20263AFBB405FE46A1C017A82A13D7B5@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:37:33 -0000 Pj4gSSBtaWdodCBzdWdnZXN0IHRvIHJlY29tbWVuZCBOT1RJRlkgKGFuZCBkZWZpbmUgdGhlIGtl ZXBhbGl2ZSkgYW5kIHN0YXRlDQo+PiB0aGF0IG90aGVyIG1lc3NhZ2VzIGluY2x1ZGluZyBJQ01Q djYgb3IgVVBEQVRFIG1heSBiZSBzdWJzdGl0dXRlZC4gIElmDQo+PiB0aGVyZSBpcyBhIG5lZWQg Zm9yIGJpLWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eSBjaGVja2luZywgcmVjb21tZW5kIHRvIHVz ZQ0KPj4gVVBEQVRFOyAgaWYgdGhlcmUgYXJlIHNwZWNpZmljIGtub3duIHNjZW5hcmlvcyB3aGVy ZSBhbiBJQ01QdjYgaXMNCj4+IHJlY29tbWVuZGVkIGluc3RlYWQsIHN0YXRlIHRob3NlIHNjZW5h cmlvcy4NCj4gICAgDQo+IFRvbSwgdGhpcyBzb3VuZHMgZmluZSB0byBtZS4gTm9ybWFsIFVQREFU RXMgb3ZlciBVRFAgc2hvdWxkIGJlIGZpbmUsIGJ1dCBJDQo+IHRoaW5rIHdlIHNob3VsZG4ndCBk ZXZpY2UgYSBuZXcgVVBEQVRFIG1lY2hhbmlzbSB0aWVkIHRvIGNvbnRyb2xsZWQgcm9sZQ0KPiAo c29ycnkgZm9yIHRoaW5raW5nIGFsb3VkIDopDQo+ICAgIA0KPiBKZWZmLCBpcyB0aGlzIG9rIGZv ciB5b3U/DQoNClllcywgdGhpcyBzb3VuZHMgZ29vZC4NCg0KdGhhbmtzLA0KLUplZmYNCiAgICAN Cg0K From nobody Thu Mar 16 13:54:08 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A955129A6F for ; Thu, 16 Mar 2017 13:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkmasl-PkdJ2 for ; Thu, 16 Mar 2017 13:54:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 D741F127011 for ; Thu, 16 Mar 2017 13:54:04 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-57-58cafb6a6784 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id DC.AB.24979.A6BFAC85; Thu, 16 Mar 2017 21:54:02 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Mar 2017 21:53:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oA0aLkpobgUlKri5iqr+sBXaXV2ZljuUm3iaX78Xiyo=; b=iIkSguf4rlGYgwCYu+aH4rlVl1ifEXj8d/e+9X9iKjvPSOLKLGnkBrSXOkIg4oi7w9aOpEkIjrBJk1H+L4cqYz0LzYOPrnMfWVpfxayoaBwbQhlaLI92oDY7AdWkKJPQ+3daFKVJQkmqEYijtA+8rJEePfPpM70b3iQZatXSO5U= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; Received: from [192.168.1.40] (81.38.21.163) by DB4PR07MB0639.eurprd07.prod.outlook.com (10.141.43.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 20:53:51 +0000 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= , Tom Henderson References: CC: HIP From: Gonzalo Camarillo Message-ID: Date: Thu, 16 Mar 2017 17:25:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [81.38.21.163] X-ClientProxiedBy: HE1PR0902CA0011.eurprd09.prod.outlook.com (10.171.90.21) To DB4PR07MB0639.eurprd07.prod.outlook.com (10.141.43.154) X-MS-Office365-Filtering-Correlation-Id: 983c6447-d0fc-4a8e-571f-08d46cae8dc6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB0639; X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB0639; 3:Cn4KO0jnyMUHtM0hzVrz09Fb6jAWpKBsNzAOLCGBTDCWyg1HCpE0Tz7uwgAf5NnyUOZyPKnqykZGNv4laJ5RhZk/4VqvojqD2JJPQEk2jB8iBy64WC0ciEgFPgyz0VMByapVzvi7F9k/9qCdv37obW7NR4DEFLKsz5/V0lY8to3QRep82HKVxn3Jt3Mg34JxNz96ps6J73U4D6jJiSqM0Ig4Noo5EyY0w2/NNfmkMt1KVGgeI8tHASAq/LKrlj7IocHYCnUU8ZcK8CmBuWQkjg==; 25:GrJpXd5e2dKKdGLwbbejGJC47xdrZl3cYFD8dRG6opZ0KL1b9CWGQFBAR1Hq+wgRHDVCQWut6dbUjSUt3YblUfx6lRRfQhnIZ9I2sCiPCUf0V4J4RkGVgvMQGF+YhWqShEesggvH3nuhjDFqOfdi+eG2xkeLEWw/0LZLIOfolI0OVDrk5uZdkfh1ers+mbkbofbA0uewTKJrE4eu6DERxGEzKuSrat3uVYjKQWwDkFtPggGzOOR1TEAwkhe57vuorW8BzMQ5yfkIYsqu4K6eHag3YEIVxXg6YgYbyqYc8lU+eWPwSgrrotTbbfVNEHYhSi9dH0cu+f842StPSapXr7wl8SktaaShsReAP/mCppZG53eZ+xDv30wWh1jU0KxLD4fRTcoe2bA6Viwq9GNaFOcunGn8SG3SKOjLZi2iSOPZrjM4o59xJzEke22SgJOQlOtjV5SDZbb2h94JKnyOdw== X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB0639; 31:4pHU5bp9VYNhnw9pt2nyaYuJVuhqyU5Fm6Y4kaYE46FRz/DAOhsJlL9OZa0QNnwHMQ+Yuhd3okuKxDTlrZTS8yOKduYhiS0kK+/O+vL/x3ihQ42n5VWraMpVCEedUx0yIioZlnNdOHEC2lVgbkmZQHvhQnC8qc2JeduMaAaQLLP26ZtsjU4v4YDAnKWZrUvOMCal5xe+klhiVcmEC1qqoW49qULXpKIDUDqhsvxObvPzcSnZdCm8rPB67chGEzNAWr3fFNabKwj4r8RKEBBEqFwiUDM95b60xUkumDlV/8U=; 20:86ZHffQcjhJaDXc48Hlg2MWQWXQ8mjxWC40vPFVJc7BGgd9bmJg+H51XAwZ1zxFx4YkvKGVCkudb17X7Ce3K9qZ4ypdmZgRAISiXVherBAyZDgb+gPY9k9UwY6gvbvdW3PZYJLBeZvuKTYjjiJUTrQaoPaLLsvEv4At/ecIkLTvAnvGRm6cFrVZA4u6hM7a0nW89pShowFyfnHKFN7+uY28OXUG/fyEH8O6NFDrG7fm/XL6OKCeQ3Fcx5h8a/MSqdMin/4fR+yrO2LXPBpgv9rMyCNd+GISJgef4MLy1XtuuSQ2o8z+2Qru8mTF54+flySfmofqZTqRU7/86+AdGbvy7bxkyKd2cv3jiSfCqP07JUU/cJvvvz395SG+B5+/xtUt0T8VJfL75cQ1uqS77daKyUaR1XZdLNZjbgQCJW6fZHnoUpxzZWC6Ibt/NSkdKiAQuf1Rxzn9JUnKZBvzK70KjCU2chTlRDqxCLy1e99AUNxk3F98fAsBfmiV2n7SS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(47954115253988); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:DB4PR07MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB0639; X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB0639; 4:Q9FnQBQTj/+57Nl1plfRVVT4hCmDRKWuh2HSqREoXIxiBuqoKUqFcnbQsNo9L1DRhLh+EXxd2HDpNuG1mnAChf10jKk/ab1Lv3QIAzRpcRDEQZyO+kM7jcFEZVybf7xUhL/GcAB3JRfvrbCdd3Mr1/Qrg5dRMsyNtrlBvfTlRr8YEDrse2u4zQD0WzlJDjrO0wk6dHFX0qSYV4DkmHrJf14/yss2gtb3D6w6v383Mu/UKBZLUiNHv9be3SfIq1Qo6Up4bd2fo+hZowXc0qA+ZiChn3Vlc6IjKfRoQIn8RMZEROAjEub+5GFAbFTqNLkIbpOTtUOVDyd4Ugx3JQu5MpFFI8HrKFm/igtXY6jDRVbvQpAGubj3S0/o408ymIfsmbvhrznNT8lTJg9lfVGdWjufaz0Z55HSiJ1bkR5vhsfscF4ah142Zz6+xVr40UYubcpMvNz4KYSqLXOQQvWe3iIfOqKSO0+N/YJbT6Yq9bZbOiYZ38KExPVylGn+OcGAqltj/61zKxs3luWCt/bu9xrIrU/M5QQUXb+60lxBItYIK7vNUcmkohr14Fhc2hs1t9X+3ra1JXlg6kSdA0NqKCSCZqrBiVoer2tnDlcRxsfSrCWM7Y2aCTeOUXtfQqYZy1o40Bwhaw7ljV8ehk37MA== X-Forefront-PRVS: 024847EE92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6019001)(6049001)(6009001)(39450400003)(269900001)(377424004)(377454003)(24454002)(2950100002)(65956001)(6666003)(25786008)(230783001)(117156001)(90366009)(81166006)(50466002)(66066001)(6306002)(2870700001)(53546008)(8656002)(47776003)(83506001)(229853002)(23676002)(53936002)(77096006)(6486002)(2906002)(36756003)(6246003)(2171002)(189998001)(4001350100001)(6116002)(38730400002)(31686004)(42186005)(86362001)(50986999)(76176999)(65826007)(8676002)(31696002)(7736002)(305945005)(5660300001)(4326008)(33646002)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0639; H:[192.168.1.40]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjRQUjA3TUIwNjM5OzIzOjhvSkxFRm0rQmdRbG5EUHB4Q0o2cEE5eitX?= =?utf-8?B?QmcyN2UwMnM2bUh3bzhBc2ViSS8rMm5XOUlyN0lIZlpnVklYL040OFdzZVE0?= =?utf-8?B?a2pFVTJnZ1g3clNUa2NLRStuaEZtdTBMd1JMZVlJekk5UWpNSnpWWFdIdkgy?= =?utf-8?B?YUZjMFJreXg4QTgxUmFybXc3NHVxVUg0OU13UnR2cVVnakgzY2xpeHdaN01u?= =?utf-8?B?NG5iMkhEM3FjNUlZMGZXUkpLcUZBTVdNR1JURGsxbUFQZm1odC84KzJHcnRn?= =?utf-8?B?Y1JldDMzNVVjZFh6OTlZOEh6c2dHWHRxU0JkUDUyUGRqcE5qRlF4UlhyT1Iw?= =?utf-8?B?VVFnTXZOcGhCcGZDMmtrVS9yMFFjZGpGTVpSak1QMWkxbGVMejJoaHVyT0Rq?= =?utf-8?B?eC9tWVFCTUMxeGM5VkJmbHBFVGJXRHMydWljekV5OXRUcVoxUHFWMXZaR2t2?= =?utf-8?B?SlJmM1N5a1RBY2dWTks1UUNGSnFvVTEzSExZMU8wQmVBTVNpUzM4OCtCM3RO?= =?utf-8?B?alpSUzQvbVY5WTk2VWp5VVBKNWtxZWtjUTNJTGpKYTcvc2JoWHpoZGNQa0xD?= =?utf-8?B?blpKYU9CbkRhRWQ5RWJXQ0c4T040YS96K1NiZnExZjUrZ2lDN0JVU3oxcTVO?= =?utf-8?B?M2QwVXduOXBPckIyM0F5V1NMVmJWVnJVMUxXWitBZ3ZxeHVhV0NPUnlNTVh3?= =?utf-8?B?MUdvdGJPNUZxOUZ0eTZQam1rZnR4QS8yajlyamZOL1pQc1AzN3lhUDkzT3Aw?= =?utf-8?B?Y2pMZUZySlB6VmdkVk0zeHpFR0xGSW95dDBoUWVHNlcyK0F0dkVJKzRQclNy?= =?utf-8?B?bTlUNUlzaFZXY3M4cUxQT01rczYyMm96S3FJUnY4c0NMOWk3OUltNnJ3TW4r?= =?utf-8?B?OU9idEw1eUwzYWVHa2RTRVVVOXRYWGZacUFGbDJjYzBXY01vdUlNdEQ0dCtq?= =?utf-8?B?cmNwK3ZxTjU2QU1LL3R2R1ZlVEFMWHJQaHMrRXdNTWdYSjI1Y3BLY3RmSjli?= =?utf-8?B?YmREelF6NEJ0c2U0T0FpMXFOOUFJN083MWdOUUZnMjAxNDlwTU5iSUsxRmJa?= =?utf-8?B?MG9QYklsanZ1dnBCRFFsc2VWVlF4UjNZWkd3WjdOT0p6V3pXQlQ2Y3orbkYw?= =?utf-8?B?S0lYWWhMMDhwRk56NnZYWVhWWEZsUVV0L2NLVXBHbEI1Q0o2UTJabmt5UnFj?= =?utf-8?B?QW1ZWGk5aDFuRzVHQjFHZFJTQWNGOGxFQVJWc3JkY3lTSWphNTlCcmhHaDR2?= =?utf-8?B?ckVzaDF0bmEyZEtqemlTbDlCSmxzdUljR2F2eFBKbUpWdjRrNVk1cE8zNTlq?= =?utf-8?B?Mml5aWU3RzRkdnFyMFZITzhiUzBTbGJKNkNrNnZHeFlUV083QmF5aVhvT0oz?= =?utf-8?B?c2lZWEZPN1RSaG1uSnhiQkJwQndpWS9sSnB3RDcyQWdEZ3dnU3RDK1JEWk9O?= =?utf-8?B?SkJhcXRwM0FOWHc0Zm82VFQrL3JXOWw2QnNBYjJ4RXhMMkt4VzQvSVBGRVE4?= =?utf-8?B?OHpHTzViTDhRbEV3WmRBRUtpWHFpcCtrUkY3dUlLTDU1NW5kUkRlNDF6OFBM?= =?utf-8?B?STdPakZTNzNDM0tYVlo4Q1JtTFlyckFXenNzWUYyaEJobnllL1VQTnNoSVVO?= =?utf-8?B?Mnp3aG1MVnA5NGVYUE1waHpON2k5ZHdHTUZ3N01aSGt6Q2FXM2NGM1NqWHJJ?= =?utf-8?Q?YVdt9T0IMxdNJzupjVIwTGA8R4tnk3CviaFlNJR?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB0639; 6:GB52MtZlQ/nwXY6t4kmmj9vEoeTVZqWR/JYolqqtORBfgrVOXn+v71m0kPxPEvgXZuH+iAoTqoNm97m22rtydQiWcgSCXHSD16m/uLMQDUijvlvXlV1Z4SPjGywiauGwfiVFAM3/X7Xuxwj7i82Fc78yRuqQi8DuO0WG+kfFygh+xyg4u9t1Hf2GpeoJ4rYT62POfEYfn32yeigUKXw/2eX6H6GaFwPqdOdf77pbBFSyhcAh/2D5GNVpR1b4PFpjRrunqTzuiZBC7Ps+wz7SyKOPOZ7BCB41Ieu47reVAXzL0C3W3YpjK3On3i8++iB8kja0Wyc9QKJBtK8kuKVXjLhYa7ARch57L/JWhmh8nLMXJtTHmo9q0x49kKeAm1fWmVvXNxIq4HJZw4ZhopyxjA==; 5:VxjsZtgV739gS7ERjaeN9jGW5E6PDv9iv+1kH0lbyzDbfvuo45Djn4mnpUQUToLqjeTSX1mBFiUSmlAyKv++XPYc0QQQkYcH0Iw7DMiwLwpY00hbhiqZ+YX0du4xzMXQhXq7H3MHbMVGqd8xg6Gz4A==; 24:Srq1/MSCgpch9fmCQU3eUGMgG2BMKkeGi4RU2gyY4uHiHGb2xmP9roCb4uSLEKi1UmPKnQRuTidEVxsEjmPhin5uM2stkreyhBU2iufb5Hk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB4PR07MB0639; 7:UGxJT4fdcHsCEEEpLEV2h8a++tpNodqM0uVgHdU3RjCcVsPiWbFNywLTXSETuuAVZfdUIOjuJLatUt9lfUEpbAw1L2dOTFV9SUBswXuXsT2JOCM6KvfJrrqrm5hbAvWJgYPpZ48R1Ey+y2U7st7lK0rB3IY9g842zIivlmDNXAozeyiDeN+SiCrM5sNpfOnq0JQHDrVayBbaa2R858Ie0SjwKv5/q0F/SEAZ50wRhqCi+VhLAE/ECdu7Xmhb+wtygLTz1FfsUGQkWL74TbF59vZysGYqYGRpt9A1Dm6G6hzY82NkwAUb7YEKh1ygcOX+lB1R47HOEIcPGMUTyByx/A== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2017 20:53:51.5871 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0639 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGfG3Rjfr96kIg5nd5hZTF01mtnh39DuL xczzB9kcmD12zrrL7rFkyU8mj5brMQHMUVw2Kak5mWWpRfp2CVwZE9eeZyn4p1bxrfkXYwPj LdkuRk4OCQETiSltx9m6GLk4hATWM0p0vHjFCOGcYJR493UpmMMi0MsscXlHPzuIwyjQzSjR 9XY+M0i/kMBvRomPy01AbGEBQ4n2Ke1sILaIQJbEwe7F7BCjjjFK3LjyBizBLCApsXzTLzCb TcBCYsut+ywgNq+AvcS1NT+YQGwWAVWJy/uugcVFBWIkWpZ8YISoEZQ4OfMJWJxTIFDiyNyl QDYH0ExNifW79CHGy0s0b53NDPGbgsS/Q61MIDdICHQwSsz+Ng/qaG2J5c9aWCCKfCU+f/7O CGMf/HubBaJhBZtEx5d1bBDOUzaJ94tPsUFUZUtsePMPyraSmH52E9SKWUwS9xfvZIZwzrBK 3N86D+oQGYk1C49CzV3MKrHo8hJ2CKdTUOLHx7ssExg1ZiF5cBbCU7OQPLWAkXkVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmDqOLjlt+4OxtWvHQ8xCnAwKvHwFqw4FSHEmlhWXJl7iFGC g1lJhJcdJMSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAOj 60EjZa+DnG53Znxmk512PMuOeaLtvKdvbltXLU6oDuPq3MpYKnC/xSnj53tvft2q20c2+20U 7TWozrHcYF64onRHzYcMvwmPuj90Tkm5dN2Utztkm9rj3Ytsa+99zwo5+q9ouslpT1sDxahF 9ZWfY5U9lF7+8NIWK/t0VOOdzvfo+pDKnXxKLMUZiYZazEXFiQBUTrToGQMAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:54:07 -0000 Hi Rene, did you get answers to your questions below and, in general, enough input to finalize the draft? Thanks, Gonzalo On 05/02/2017 11:59 PM, RenĂ© Hummen wrote: > Hi Tom, > > thanks for your review! > > I have addressed most of your comments in the new revision 05 that I > just uploaded before. For your remaining comments, I need additional > input from you and the rest of this group: > > 1) The text from Section 6.3 that you refer to is the same as in RFC5201 > (HIPv1). I agree with you on the endianess. However, I assume that there > was a good reason why the sort() was specified this way in the original > HIP version. I would therefore prefer to keep the text as is. > Concerning the 96 vs. 128 bit issue, the draft defines HITs the same way > as HIPv2, which from my understanding are the full 128bit. > > 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the > full specification here in order to significantly increase the > readability of these sections. When only stating the differences, I > found myself constantly changing between two documents (RFC7401 for the > content and the DEX draft to see if the content was relevant, removed, > or modified). To support those interested in the changes between RFC7401 > and the DEX draft, I specifically call out the main differences at the > end of each section. Does this satisfy your comment? > > 3) If your suggestion for Section 10 is purely cosmetic in nature, I > would prefer to not put additional effort into the IANA section. So, are > these changes cosmetic or mandatory? > > BR > RenĂ© > > 2016-11-20 3:32 GMT+01:00 Tom Henderson >: > > Gonzalo, I have reviewed HIP DEX again and believe it is ready to > publish, although I spotted a few minor items below that can be > handled in the next revision. > > - Tom > > Editorial/minor: > > Section 1: The numbered list is somewhat tersely written and may be > hard to interpret by the newcomer to HIP specifications. Consider > to elaborate more (using fuller sentences and not sentence > fragments). e.g.: > > "Forfeit of Perfect Forward Secrecy with the dropping of an > ephemeral Diffie-Hellman key agreement." could be > "Forfeit of the HIPv2 Perfect Forward Secrecy property due to the > removal of the HIPv2 ephemeral Diffie-Hellman key agreement." > > Section 1.1, spell out 'DoS' first time usage > > Section 4.1: "Note that x and y each constitute half the final > session key material." (change to 'half of the') > > The figure in 4.1 does not have a caption, and also, why is 'mac' > lowercased? > > Sec 4.1.3.1 : "Since only little data is protected > by this SA" (perhaps s/little/a small amount/) > > Sec. 5.2.4: "The following new HIT Suite IDs are defined..." (s/IDs > are/ID is/ because there is only one defined) > > Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network byte order > concatenation of the two HITs... comparison of the two HITs > interpreted as positive (unsigned) 128-bit integers in network byte > order" what does it mean to define a sort on a network byte order > concatenation? It seems perhaps clearer to leave endian issues out > (they are implicit everywhere in a protocol) and just define it as a > comparison on HITs interpreted as unsigned 128-bit integers (and by > the way, is the full 128 bits including prefix included or just the > 96 bits)? > > Sec. 6.5 through 6.8: Unlike much of this draft, these sections do > not just specifically call out the differences from the > corresponding RFC 7401 sections, but instead restate the modified > processing flow, and it is hard to spot what is different here. I > wonder whether it would be clearer to just refer to those processing > steps in RFC 7401 that are changed. > > Sec. 8: Can a MITM reply to I1 with ICMP parameter problem, causing > the true response (coming later) to be ignored because the initiator > already gave up? Maybe clarify here or in sec 5.4 to wait a little > while before accepting the result of an ICMP. > > Sec. 10: Consider to update the IANA section in the style that RFC > 8003 (and others) used, stating the history of the registry and what > exactly is requested to be changed. For example, something like > "RFC 5201 and later RFC 7401 established the following registry > .... This document defines the following new codepoints for that > registry ..." > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > From nobody Tue Mar 21 04:14:19 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE961293F8 for ; Tue, 21 Mar 2017 04:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qza01U2MPaLK for ; Tue, 21 Mar 2017 04:14:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 ADCC0129482 for ; Tue, 21 Mar 2017 04:14:15 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-0f-58d10b057935 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 70.72.11640.50B01D85; Tue, 21 Mar 2017 12:14:13 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 12:14:28 +0100 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: Date: Tue, 21 Mar 2017 13:14:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2J7oC4r98UIg90LzCymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE93uxgLXotXvFn8h7WB8ZpQFyMHh4SAicTfdWFdjFwcQgLr GCXebVjBCOGsYZTYtOYnaxcjJ4ewgJPEnP73jCC2iICoxJQPp5lBmoUEPCVWTtMCCbMJaEms unOdGcTmF5CU2NCwG8zmFbCXeH3oDdgYFgFViQ+3L4LZogIREvOfrmKCqBGUODnzCQuIzSng JXFv91l2kPHMQL0PtpaBhJkF5CW2v50DtVVF4uKx4AmMArOQNM9CaJiFpGEBI/MqRtHi1OKk 3HQjY73Uoszk4uL8PL281JJNjMDQO7jlt+oOxstvHA8xCnAwKvHwFrw7HyHEmlhWXJl7iFGC g1lJhNe170KEEG9KYmVValF+fFFpTmrxIUZpDhYlcV7HfUApgfTEktTs1NSC1CKYLBMHp1QD o67GtsRZ509MOcyXGKUcFjpL7KfQTz1uuW+GgvvOh9prypv+7Jzzyy6V/3ystP+GWzfiJZUf rs11lbn3fuqRqwL/vxot+hq0JP2KBO8UZ42qLVF3JaM/fjkixRwRbjKl8snhyBqhqnndD6ae Tnmp2NItpcFbeGtV7Y2d+RmnD07Q/Gh/aZ7YVCWW4oxEQy3mouJEAEOjmvI5AgAA Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:14:18 -0000 Hi, a preliminary version here: http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt Not yet on IETF site since I missed the cut-off deadline. On 02/19/2017 05:18 PM, Tom Henderson wrote: > Hello, I have read the latest (-17) draft and sent some purely editorial > comments to Miika. I had a few non-editorial questions and comments. > > 1) In appendix D, it states: > > o A minimal implementation would conform only to Section 4.7.1 or > Section 4.7.2, thus merely tunneling HIP control and data traffic > over UDP. The drawback here is that it works only in the limited > cases where the Responder has a public address. > > However, in section 5.4, it states: > > Implementations conforming to this specification MUST implement both > UDP-ENCAPSULATION and ICE-HIP-UDP modes. > > The contradictory text should be resolved. In my opinion, > implementations that want to support only the UDP-ENCAPSULATION mode > (and its restricted set of use cases) should be allowed. However, I > don't know what might need to be done to avoid a situation where a > product claims RFC compliance but only implements one of the two modes. > It could perhaps be avoided by a statement that states "Implementations > that choose to only support the UDP-ENCAPSULATION mode should clarify > this point when any claims of compliance are made." now it says: "Implementations conforming to this specification MUST implement UDP- ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes." I can also add some other wording if it is really necessary (and common in RFC specifications). Btw, while ICE lite is not really the same as ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the specification. > 2) Appendix C states: > > o The considerations on Diffserv Codepoint markings in ICE are not > applicable to HIP since Diffserv is not used in HIP. > > Why wouldn't the same issues arise in HIP as in ICE on this matter? > Should this draft instead copy or reference the RFC 5245 recommendation: > > If the agent is using Diffserv Codepoint markings [RFC2475] in its > media packets, it SHOULD apply those same markings to its > connectivity checks. > > Also, I don't think that the HIP control plane should be excluded from > using diffserv. done. > 3) In section 4.10 (NAT keepalives), it states: > > Both a registered client and relay server SHOULD > send a HIP NOTIFY packets to each other every 15 seconds (the so- > called Tr value in ICE) unless they have exchange some other traffic > over the used UDP ports. > > However, I couldn't find an explanation anywhere (also in RFC 5770) > about how to code this NOTIFY. Would it make sense to define also a > "NAT_KEEPALIVE" NOTIFY message type for this purpose? > > Once these issues are resolved, I think that the draft would be ready to > publish. done. P.S. The new version of the draft also includes some nits from Alex Elsayed. From nobody Tue Mar 21 04:26:09 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC57128CDC for ; Tue, 21 Mar 2017 04:26:07 -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_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 1AEwt61htw34 for ; Tue, 21 Mar 2017 04:26:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 60D611293F9 for ; Tue, 21 Mar 2017 04:26:06 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-4b-58d10dcc86dc Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 64.06.23528.CCD01D85; Tue, 21 Mar 2017 12:26:04 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 12:26:03 +0100 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: <673edf5e-e6b8-39d0-5ee8-1c5ffe500c6d@ericsson.com> Date: Tue, 21 Mar 2017 13:26:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7pe4Z3osRBnMvqllMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGS+nnWAp6GOr2PCtm72B8TlLFyMnh4SAicTS9z9Yuxi5OIQE 1jFKrDw5kR3CWcMocXvLZDaQKmEBJ4k5/e8ZQWwRAVGJKR9OM3cxcgAV1Us0bZYCCbMJaEms unOdGcTmF5CU2NCwG6yEV8Be4swlQ5Awi4CqxJedB8GmiApESMx/uooJxOYVEJQ4OfMJ2D2c Ag4S6643M4G0MgO1PthaBhJmFpCX2P52DtRSFYmLx4InMArMQtI8C6FhFpKGBYzMqxhFi1OL i3PTjYz1Uosyk4uL8/P08lJLNjECQ+/glt+6OxhXv3Y8xCjAwajEw1vw7nyEEGtiWXFl7iFG CQ5mJRFe174LEUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfYBpQTSE0tSs1NTC1KLYLJMHJxS DYxs+9LeeVvP4H3xsX3bK+4rVTm/mePfc6cvmfmVm6vFKiCFV5PJQrLoydR1Hb9PsvYe3aC9 /POV5L2bNTIkdsr+6A6Yku9y2+pD0xfN3hyJ2LSn7r//VZ95U7331YkjHVl12ceWZssGZ7gH KHpH8ys6T6+s+8T73OmfXouNVP6pKQuZY9Xe5SqxFGckGmoxFxUnAgBtdrr0OQIAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:26:08 -0000 Hi Tom, On 03/14/2017 11:19 AM, Miika Komu wrote: [..] > A couple of fixes for me to edit: > > * Appendix B: normative vs non-normative terminology > [...] so the appendix was using normative terminology which was a bit strange. As a quick fix, I thought about moving this appendix to the body, but after reading this extension (that was inherited as a legacy from the earlier specification) I decided to remove it. The section basically suggested allowing source routing via HIP relay for the sake of compatibility with RVS servers. I think this could be exploited in a bad way to DoS other hosts. I think it is more secure if the HIP relay only forwards inbound packets, not outbound. If you disagree with this change, please discuss on the list. From nobody Tue Mar 21 04:38:48 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14D129713 for ; Tue, 21 Mar 2017 04:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0w5W_gbPG6Y for ; Tue, 21 Mar 2017 04:38:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844891296EF for ; Tue, 21 Mar 2017 04:31:02 -0700 (PDT) X-AuditID: c1b4fb30-3efff7000000628e-93-58d10ef4c121 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id A6.2D.25230.4FE01D85; Tue, 21 Mar 2017 12:31:00 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 12:30:59 +0100 To: Jeff Ahrenholz , Tom Henderson References: <7110ABD9BA66454293AEE83D6D37016617B30AA9@ESESSMB109.ericsson.se> CC: HIP From: Miika Komu Organization: Ericsson AB Message-ID: <83997d74-43c4-d5f7-69f7-cc3a0309d47f@ericsson.com> Date: Tue, 21 Mar 2017 13:30:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7tO4XvosRBv/emFtMXTSZ2aJ1yk1m i5nnD7I5MHssWfKTyWPrnk4Wj5brMQHMUVw2Kak5mWWpRfp2CVwZf7pbWQp+8VfsWHmCpYHx JE8XIyeHhICJRP+Cd8xdjFwcQgLrGCUm797ICOGsYZTYuOMeE0iVsICTxJz+94wgtohAosTS bTPYQGwhgU4miY8fwOLMApISyzf9AouzCWhJrLpznRnE5geKb2jYDWbzCthLrLi3GWwmi4Cq xL+nz8FsUYEIiflPVzFB1AhKnJz5hAXE5hTwkHi75RETxHwLiZnzz0PtkpfY/nYO0EwOoBtU JC4eC57AKDgLSfcsJB2zkHQsYGRexShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYwAe3/DbY wfjyueMhRgEORiUe3oJ35yOEWBPLiitzDzFKcDArifBmAsNfiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsbkzx+aK1bOutGzytqoUEOnWDA1KGue8HyP WM+vJzK3n5u073s2772omwVbahPPl1pFtG6PY09YfEZN7u3EdZoxyz3snzy12a0z0/6PjnHE /4f7k9jvuBYcnJG/1FCQvU2/KkPd6cJzr5LfDyJvSxw8wv3s36ttl5iTxZS1RA4yNukwRq3+ 5KzEUpyRaKjFXFScCADoc55BXAIAAA== Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:38:47 -0000 Hi, On 03/15/2017 04:37 PM, Jeff Ahrenholz wrote: >>> I might suggest to recommend NOTIFY (and define the keepalive) and state >>> that other messages including ICMPv6 or UPDATE may be substituted. If >>> there is a need for bi-directional connectivity checking, recommend to use >>> UPDATE; if there are specific known scenarios where an ICMPv6 is >>> recommended instead, state those scenarios. >> >> Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I >> think we shouldn't device a new UPDATE mechanism tied to controlled role >> (sorry for thinking aloud :) >> >> Jeff, is this ok for you? > > Yes, this sounds good. I have reflected this discussion now in section 5.3 of the preliminary version: http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets as specified in [RFC7401] with Notify message type field set to NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification data field. It is worth noting that sending of such a HIP NOTIFY message MAY be omitted if the host is actively (or passively) sending other traffic to the peer host over the UDP tunnel associate with the host association (and IPsec security associations since the same port pair is reused) during the Tr period. For instance, the host MAY actively send ICMPv6 requests (or respond with an ICMPv6 response) inside the ESP tunnel to test the health of the associated IPsec security associations. Alternatively, the host MAY use UPDATE packets as a substitute. A minimal UPDATE packet would consist of a SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve rekeying procedures as specified in section 6.8 in [RFC7402]. It is worth noting that a host actively sending periodic UPDATE packets to a busy server may increase the computational load of the server since it has to verify HMACs and signatures in UPDATE messages. From nobody Sat Mar 25 17:34:17 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57197128896 for ; Sat, 25 Mar 2017 17:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KsWgHjOag9cH for ; Sat, 25 Mar 2017 17:34:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0949A128D3E for ; Sat, 25 Mar 2017 17:34:12 -0700 (PDT) X-AuditID: c1b4fb30-3efff7000000628e-2c-58d70c81c558 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 58.80.25230.18C07D85; Sun, 26 Mar 2017 01:34:11 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Sun, 26 Mar 2017 01:34:09 +0100 From: Christer Holmberg To: "hipsec@ietf.org" Thread-Topic: Comments on draft-hip-native-nat-traversal-19 Thread-Index: AdKlx3D+K+wlmRkFTR6Gys+AEEsX0w== Date: Sun, 26 Mar 2017 00:34:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB2C90B@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB2C90BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7t24zz/UIgwN/eS2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOl9u5gKTkxmrGj7sIK5gbGvqouRk0NCwERi6ZGFzF2MXBxC AusYJXr7trFBOEsYJd5NPgyU4eBgE7CQ6P6nDdIgIqAucbSnmQXEFhYwk/jXc5UJIm4tMeHv YjYIW09i79rpjCA2i4CqxLdeiHpeAV+J3puNYPWMAmIS30+tAbOZBcQlbj2ZzwRxkIDEkj3n mSFsUYmXj/+xQthKEmsPb2eBqM+XODbtABPETEGJkzOfsExgFJyFZNQsJGWzkJRBxHUkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBwX9wy2+D HYwvnzseYhTgYFTi4TXYdy1CiDWxrLgy9xCjBAezkgiv4QGgEG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYz+DmGvvqa8NVz+SPibWfldu0YGhv3H1kp8 +2zP4K+weMOKg9N8i90+nphx7Ejjoey1OxxC3i0Nj7teZXnjnQe/26Vk24iHXq0//K8fuOql NefxNftnD09XTn47r4ep49Uh1thH+ZP3cks+MLmQs9lldxpP8nP/afsTpfndoxPnXrt2Y6u+ UYOZEktxRqKhFnNRcSIA9N5TgnoCAAA= Archived-At: Subject: [Hipsec] Comments on draft-hip-native-nat-traversal-19 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 00:34:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB2C90BESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As co-author for the ICEbis draft, I was asked to review draft-hip-native-n= at-traversal-19. I have not had time to review the whole document. However, many of my comme= nts are generic, and apply to the whole document. I have no knowledge of HIP, so I will not comment on HIP issues like messag= es, parameters etc used. General: =3D=3D=3D=3D=3D=3D=3D QG0: Throughout the document, you use RFC 2119 terminology (SHOULD, MUST etc with capital letters) when you refer to procedures and rules defined elsewhere. I think that is wrong, and it also makes it very difficult what exactly is defined in this document, and what is defined in some other specification. QG1: You say that the mechanism in the draft is based on ICE. I think it would be good to give a name to the mechanism. "HIP-ICE", or something similar. QG2: I would also like to have a dedicated section which on a high-level describes the differences/restrictions between legacy ICE and HI= P-ICE. It helps very much when later reading the details in section 4. That section should at least list the different types of functions (HIP relays etc) are used for gathering candidates, what protocol (HIP messages) is used instead of STUN, what types of candidates are used and how they are retrieved. It would also be good to give a short overview of the HIP messages used for the connectivity checks. It is very useful when later reading the details. QG3: You should use consistent terminology when you talk about endpoints and relays. Sometimes the text says "host", sometimes "HIP relay = server client", sometimes "relay client", sometimes "end-host". Sometimes you say "HIP relay", sometimes "HIP server relay", etc. Sometimes you say "non-relay host", which suggests that the relay is also a host. Section 3: =3D=3D=3D=3D=3D=3D=3D=3D Q30: The text says: "The hosts may use HIP relay servers (or even STUN or TURN servers) for gathering the candidates." This is confusing, as you have earlier said that HIP-ICE doesn't use STUN. (Implementations may of course provide both STUN- and HIP functionality, bu= t that is outside the scope of the document.) Q31: The text says: "To be contacted from behind a NAT, the Responder must be registered with a= HIP relay server reachable on the public Internet, and we assume, as a starting point, that the Initiator= knows both the Responder's Host Identity Tag (HIT) and the address of one of its relay servers" First, when you say "its relay servers", I assume you mean the relay server= s of the Responder? Second, doesn't the Initiator need to know the address of the relay to whic= h the Responder is actually registered, in case there are multiple relays but the Responder is not registered with all of them? Maybe someone = thinks it's obvious, but I think it should be make clear. Could you simply say: "To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet. It is assumed tha= t the Initiator knows the address of the relay server(s) to which the Respond= er is registered." Q32: The section introduces the "base exchange" concept, but it is not clearly defined. Is it something defined in HIP, is it HIP-ICE specific? I think you should add a description/reference somewhere. Q33: The text says: "At the end of the procedure, if successful, the hosts will have establishe= d a UDP-based tunnel that traverses both NATs, with the data flowing directly from NAT to NAT or via a HIP data relay server." What if the responder has only registered to a HIP server relay? The text in the section seems to suggest that it is optional to register to a data relay. The text needs to be more clear on whether the endpoints need to register to a server relay and/or data relay. Section 4.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q421: In general, I think it would be useful to split the section into HIP client procedures and HIP relay server procedures. Q422: I think the following text should be in the beginning of the section: "ICE guidelines for candidate gathering MUST be followed as described in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host candidates (loopback, anycast and others) should excluded as described in section 4.1.1.1 of the ICE specification [I-D.ietf-ice-rfc5245bis]." Q423: The text says: "However, if no data relay is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate" I am not sure what is meant by "as the only host candidate". Q424: The text says: "Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal. It is RECOMMENDED for implementations to support this functionality" If you say SHOULD use, why do you then only say RECOMMEND support? Doesn't the support need to be stronger than the usage? Q425: The text says: "Unlike ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists." This is confusing. What is meant by "unlike ICE"? You are using ICE :) I assume you are referring to ICE usage for non-multiplexed RTP/RTCP? I think you simply need to say that HIP only uses a single UDP flow, using a single component, with a value of 1. Section 4.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q431: The text says: "This section describes the usage of a new non-critical parameter type.= " Shouldn't it say that the section defines a new parameter type? Q432: If I understand correctly, the NAT mode negotiation between an endpoint and a relay takes place during registration. But, when does the NAT mode negotiation between two endpoints (shown in the call flow) take place? During connectivity checks? I think you should clarify that. Section 4.6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q460:The text says: "but UDP encapsulated HIP control messages are used instead of ICE messages." What do you mean by "ICE messages"? STUN? Section 4.6.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q4620: The text says: "The HITs of the two communicating hosts MUST be used as credentials in this protocol (in contrast to ICE which employs username-password fragments)." Again, "contrast to ICE" sounds confusing, because you are using ICE. Maybe you should say "legacy ICE", or something similar, when referring to 5245bis procedures. Section 4.7: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q470: The name of the section ("NAT traversal alternatives") is confusing, because one may think it talks about something else than HIP-ICE= . I would suggest to call it something like "Optimizations". Section 4.9: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q490: I think Mobiliy should be described in a separate main section. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB2C90BESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As co-author for the ICEbis draft, I was asked to re= view draft-hip-native-nat-traversal-19.

 

I have not had time to review the whole document. Ho= wever, many of my comments are generic, and apply to the whole document.

 

I have no knowledge of HIP, so I will not comment on= HIP issues like messages, parameters etc used.

 

General:
=3D=3D=3D=3D=3D=3D=3D

QG0: Throughout the document, you use RFC 2119 terminology (SHOULD,
MUST etc with capital letters) when you refer to procedures and rules
defined elsewhere. I think that is wrong, and it also makes it very
difficult what exactly is defined in this document, and what is
defined in some other specification.

QG1: You say that the mechanism in the draft is based on ICE. I think
it would be good to give a name to the mechanism. "HIP-ICE", or <= br> something similar.

QG2: I would also like to have a dedicated section which on a
high-level describes the differences/restrictions between legacy ICE and HI= P-ICE.
It helps very much when later reading the details in section 4. That
section should at least list the different types of functions (HIP
relays etc) are used for gathering candidates, what protocol (HIP
messages) is used instead of STUN, what types of candidates are used
and how they are retrieved.

It would also be good to give a short overview of the HIP messages
used for the connectivity checks. It is very useful when later reading
the details.

QG3: You should use consistent terminology when you talk about
endpoints and relays. Sometimes the text says "host", sometimes &= quot;HIP relay server client",
sometimes "relay client", sometimes "end-host". Sometim= es you say "HIP
relay", sometimes "HIP server relay", etc. Sometimes you say=
"non-relay host", which suggests that the relay is also a host.
 
Section 3:
=3D=3D=3D=3D=3D=3D=3D=3D

Q30: The text says:

"The hosts may use HIP relay servers (or even STUN or TURN servers) for gathering the candidates."

This is confusing, as you have earlier said that HIP-ICE doesn't use STUN.<= br>
(Implementations may of course provide both STUN- and HIP functionality, bu= t that is outside the scope of the document.)


Q31: The text says:

"To be contacted from behind a NAT, the Responder must be registered w= ith a HIP relay server reachable on
the public Internet, and we assume, as a starting point, that the Initiator= knows both the Responder's Host Identity Tag (HIT) and the
address of one of its relay servers”

First, when you say "its relay servers", I assume you mean the re= lay servers of the Responder?

Second, doesn't the Initiator need to know the address of the relay to whic= h the Responder is actually registered, in case there are multiple
relays but the Responder is not registered with all of them? Maybe someone = thinks it's obvious, but I think it should be make clear.

Could you simply say:

"To be contacted from behind a NAT, the Responder must be registered <= o:p>

with a HIP relay se= rver reachable on the public Internet. It is assumed that

the Initiator knows= the address of the relay server(s) to which the Responder

is registered."= ;

 
Q32: The section introduces the "base exchange" concept, but it i= s not
clearly defined. Is it something defined in HIP, is it HIP-ICE specific? I think you should add a description/reference somewhere.

 
Q33: The text says:

"At the end of= the procedure, if successful, the hosts will have established a

UDP-based tunnel th= at traverses both NATs, with the
data flowing directly from NAT to NAT or via a HIP data relay server."=

What if the responder has only registered to a HIP server relay? The
text in the section seems to suggest that it is optional to register
to a data relay.

The text needs to be more clear on whether the endpoints need to
register to a server relay and/or data relay.

 
Section 4.2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q421: In general, I think it would be useful to split the section into
HIP client procedures and HIP relay server procedures.

 
Q422: I think the following text should be in the beginning of the section:=

    "ICE guidelines for candidate gathering MUST be fol= lowed as described
    in section 4.1.1 in [I-D.ietf-ice-rfc5245bis].  A n= umber of host
    candidates (loopback, anycast and others) should exclude= d as
    described in section 4.1.1.1 of the ICE specification     [I-D.ietf-ice-rfc5245bis]."

 
Q423: The text says:

    "However, if no data relay is used, and the host ha= s only
    a single local IP address to use, the host MAY use the l= ocal address
    as the only host candidate"

I am not sure what is meant by "as the only host candidate".

 
Q424: The text says:

    "Relayed candidates SHOULD be gathered in order to = guarantee
     successful NAT traversal.  It is RECOMME= NDED for
     implementations to support this functionality"

If you say SHOULD u= se, why do you then only say RECOMMEND support?
Doesn't the support need to be stronger than the usage?

 
Q425: The text says:

    "Unlike ICE, this protocol only creates a single UD= P flow between
      the two communicating hosts, so only a = single component exists."

This is confusing. What is meant by "unlike ICE"? You are using I= CE :)
I assume you are referring to ICE usage for non-multiplexed RTP/RTCP?

I think you simply need to say that HIP only uses a single UDP flow,
using a single component, with a value of 1.

 
Section 4.3:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q431: The text says:

    "This section describes the usage of a new non-crit= ical parameter type."

Shouldn't it say that the section defines a new parameter type?

 
Q432: If I understand correctly, the NAT mode negotiation between an
endpoint and a relay takes place during registration.

But, when does the NAT mode negotiation between two endpoints (shown
in the call flow) take place? During connectivity checks? I think you
should clarify that.
 
 
Section 4.6:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q460:The text says:

    "but UDP encapsulated HIP control messages are used= instead of ICE
      messages."

What do you mean by "ICE messages"? STUN?

 
Section 4.6.2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q4620: The text says:

    "The HITs of the two communicating hosts MUST be us= ed as credentials
    in this protocol (in contrast to ICE which employs usern= ame-password
    fragments)."

Again, "contrast to ICE" sounds confusing, because you are using = ICE.
Maybe you should say "legacy ICE", or something similar, when referring to 5245bis procedures.

 
Section 4.7:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q470: The name of the section ("NAT traversal alternatives") is <= br> confusing, because one may think it talks about something else than HIP-ICE= .

I would suggest to = call it something like "Optimizations".


Section 4.9:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Q490: I think Mobiliy should be described in a separate main section.


Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB2C90BESESSMB109erics_-- From nobody Sun Mar 26 10:17:01 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE714129650 for ; Sun, 26 Mar 2017 10:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBwAqA6KPDhb for ; Sun, 26 Mar 2017 10:16:55 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 D482F1270A7 for ; Sun, 26 Mar 2017 10:16:54 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id a5so17974546oth.1 for ; Sun, 26 Mar 2017 10:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oAt92GYxuUDWflvDKZ2AsIxd+zAPWv/2ljE0D1jXGBI=; b=e1Xwhy02+xSqic0sLwrWs2QOZur5fZJaIn8w97ZXknYPlrdMK+AL4/GQ90F9zqEYM/ ngeiiPPXJNXNjY4H1N8Yd64v0Lvhha2/cY75OHAxZy+546nnwqiRZHkTYPaO1KB+I70I 26QddtsEZcoGd5ZeP07WI97OYne+L8pgofFGhRx2JIVE3XLzB0sVbLf1bK8IfmfnHLBb 9GP3SczaGdh26etJV2ggJL+M73zVkgMGtVz/VQpy+f1m3DKRbylDe55D/Q2VEnOsj3Q5 5uKYyyVBuUcXJ+hLXMm7mYONKiA6yWkSIN9dcgGBVTuJQPRbZ2YMkI2E8UcBpF++tbNN XTmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oAt92GYxuUDWflvDKZ2AsIxd+zAPWv/2ljE0D1jXGBI=; b=NBUrLasn/OT7EyWZ2bwdJpPjabOjf7TQSkATmTAZeQXcK4YVDGFCnsOV6k37yOpyFG 84Lx4aSi1JKHozc3il6hxM3Ef0pnMdgMMDHr43VGskJJd6RPndUSK5nqRYqu6JKcWTbr a4Buk4syNqIcITAo45es2wryNkIvyQvncNGkEZ5DEO8uMcN7ukN1Fi9V8YbLqlUBPMvo Mb5BEnR7zKUnok1GHmZVhENzBVBZOEk18qNH6CzLYxdlbyB5DuSx4ey6VYCYxuNGNvvs LP03JodWVjTEF8IoTue+ABe3DBLBDwauh22ak9eg0Ubz5+L3pguEewNfrwlVz9VXcRNj sAmA== X-Gm-Message-State: AFeK/H0J37Pgg76tJ1rFAacS14PGj7/JMiuPG35H2VRPkgZ7XyJtLh3iCytUNm+9vCZlESw6bTtgC9sIX8nzRQ== X-Received: by 10.157.7.13 with SMTP id 13mr4569737ote.60.1490548614299; Sun, 26 Mar 2017 10:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.190.7 with HTTP; Sun, 26 Mar 2017 10:16:53 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= Date: Sun, 26 Mar 2017 19:16:53 +0200 Message-ID: To: Gonzalo Camarillo Cc: Tom Henderson , HIP Content-Type: multipart/alternative; boundary=001a113b0874ad057f054ba5643a Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 17:16:58 -0000 --001a113b0874ad057f054ba5643a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gonzalo, I did not receive any comments indicating the need to make further changes. >From my side, we are ready to finalize the draft. BR Ren=C3=A9 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo : > Hi Rene, > > did you get answers to your questions below and, in general, enough > input to finalize the draft? > > Thanks, > > Gonzalo > > On 05/02/2017 11:59 PM, Ren=C3=A9 Hummen wrote: > > Hi Tom, > > > > thanks for your review! > > > > I have addressed most of your comments in the new revision 05 that I > > just uploaded before. For your remaining comments, I need additional > > input from you and the rest of this group: > > > > 1) The text from Section 6.3 that you refer to is the same as in RFC520= 1 > > (HIPv1). I agree with you on the endianess. However, I assume that ther= e > > was a good reason why the sort() was specified this way in the original > > HIP version. I would therefore prefer to keep the text as is. > > Concerning the 96 vs. 128 bit issue, the draft defines HITs the same wa= y > > as HIPv2, which from my understanding are the full 128bit. > > > > 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the > > full specification here in order to significantly increase the > > readability of these sections. When only stating the differences, I > > found myself constantly changing between two documents (RFC7401 for the > > content and the DEX draft to see if the content was relevant, removed, > > or modified). To support those interested in the changes between RFC740= 1 > > and the DEX draft, I specifically call out the main differences at the > > end of each section. Does this satisfy your comment? > > > > 3) If your suggestion for Section 10 is purely cosmetic in nature, I > > would prefer to not put additional effort into the IANA section. So, ar= e > > these changes cosmetic or mandatory? > > > > BR > > Ren=C3=A9 > > > > 2016-11-20 3:32 GMT+01:00 Tom Henderson > >: > > > > Gonzalo, I have reviewed HIP DEX again and believe it is ready to > > publish, although I spotted a few minor items below that can be > > handled in the next revision. > > > > - Tom > > > > Editorial/minor: > > > > Section 1: The numbered list is somewhat tersely written and may b= e > > hard to interpret by the newcomer to HIP specifications. Consider > > to elaborate more (using fuller sentences and not sentence > > fragments). e.g.: > > > > "Forfeit of Perfect Forward Secrecy with the dropping of an > > ephemeral Diffie-Hellman key agreement." could be > > "Forfeit of the HIPv2 Perfect Forward Secrecy property due to the > > removal of the HIPv2 ephemeral Diffie-Hellman key agreement." > > > > Section 1.1, spell out 'DoS' first time usage > > > > Section 4.1: "Note that x and y each constitute half the final > > session key material." (change to 'half of the') > > > > The figure in 4.1 does not have a caption, and also, why is 'mac' > > lowercased? > > > > Sec 4.1.3.1 : "Since only little data is protected > > by this SA" (perhaps s/little/a small amount/) > > > > Sec. 5.2.4: "The following new HIT Suite IDs are defined..." (s/ID= s > > are/ID is/ because there is only one defined) > > > > Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network byte orde= r > > concatenation of the two HITs... comparison of the two HITs > > interpreted as positive (unsigned) 128-bit integers in network byte > > order" what does it mean to define a sort on a network byte order > > concatenation? It seems perhaps clearer to leave endian issues out > > (they are implicit everywhere in a protocol) and just define it as = a > > comparison on HITs interpreted as unsigned 128-bit integers (and by > > the way, is the full 128 bits including prefix included or just the > > 96 bits)? > > > > Sec. 6.5 through 6.8: Unlike much of this draft, these sections do > > not just specifically call out the differences from the > > corresponding RFC 7401 sections, but instead restate the modified > > processing flow, and it is hard to spot what is different here. I > > wonder whether it would be clearer to just refer to those processin= g > > steps in RFC 7401 that are changed. > > > > Sec. 8: Can a MITM reply to I1 with ICMP parameter problem, causin= g > > the true response (coming later) to be ignored because the initiato= r > > already gave up? Maybe clarify here or in sec 5.4 to wait a little > > while before accepting the result of an ICMP. > > > > Sec. 10: Consider to update the IANA section in the style that RFC > > 8003 (and others) used, stating the history of the registry and wha= t > > exactly is requested to be changed. For example, something like > > "RFC 5201 and later RFC 7401 established the following registry > > .... This document defines the following new codepoints for that > > registry ..." > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > > --001a113b0874ad057f054ba5643a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Gonzalo,
I did not receive any comments indicating the need to make = further changes. From my side, we are ready to finalize the draft.

BR
= Ren=C3=A9

2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo &= lt;Gonz= alo.Camarillo@ericsson.com>:

On 05/02/2017 11:59 PM, Ren=C3=A9 Hummen wrote:
> Hi Tom,
>
> thanks for your review!
>
> I have addressed most of your comments in the new revision 05 that I > just uploaded before. For your remaining comments, I need additional > input from you and the rest of this group:
>
> 1) The text from Section 6.3 that you refer to is the same as in RFC52= 01
> (HIPv1). I agree with you on the endianess. However, I assume that the= re
> was a good reason why the sort() was specified this way in the origina= l
> HIP version. I would therefore prefer to keep the text as is.
> Concerning the 96 vs. 128 bit issue, the draft defines HITs the same w= ay
> as HIPv2, which from my understanding are the full 128bit.
>
> 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the=
> full specification here in order to significantly increase the
> readability of these sections. When only stating the differences, I > found myself constantly changing between two documents (RFC7401 for th= e
> content and the DEX draft to see if the content was relevant, removed,=
> or modified). To support those interested in the changes between RFC74= 01
> and the DEX draft, I specifically call out the main differences at the=
> end of each section. Does this satisfy your comment?
>
> 3) If your suggestion for Section 10 is purely cosmetic in nature, I > would prefer to not put additional effort into the IANA section. So, a= re
> these changes cosmetic or mandatory?
>
> BR
> Ren=C3=A9
>
> 2016-11-20 3:32 GMT+01:00 Tom Henderson <tomhend@u.washington.edu
> <mailto:tom= hend@u.washington.edu>>:
>
>=C2=A0 =C2=A0 =C2=A0Gonzalo, I have reviewed HIP DEX again and believe = it is ready to
>=C2=A0 =C2=A0 =C2=A0publish, although I spotted a few minor items below= that can be
>=C2=A0 =C2=A0 =C2=A0handled in the next revision.
>
>=C2=A0 =C2=A0 =C2=A0- Tom
>
>=C2=A0 =C2=A0 =C2=A0Editorial/minor:
>
>=C2=A0 =C2=A0 =C2=A0Section 1:=C2=A0 The numbered list is somewhat ters= ely written and may be
>=C2=A0 =C2=A0 =C2=A0hard to interpret by the newcomer to HIP specificat= ions.=C2=A0 Consider
>=C2=A0 =C2=A0 =C2=A0to elaborate more (using fuller sentences and not s= entence
>=C2=A0 =C2=A0 =C2=A0fragments).=C2=A0 e.g.:
>
>=C2=A0 =C2=A0 =C2=A0"Forfeit of Perfect Forward Secrecy with the d= ropping of an
>=C2=A0 =C2=A0 =C2=A0ephemeral Diffie-Hellman key agreement." could= be
>=C2=A0 =C2=A0 =C2=A0"Forfeit of the HIPv2 Perfect Forward Secrecy = property due to the
>=C2=A0 =C2=A0 =C2=A0removal of the HIPv2 ephemeral Diffie-Hellman key a= greement."
>
>=C2=A0 =C2=A0 =C2=A0Section 1.1, spell out 'DoS' first time usa= ge
>
>=C2=A0 =C2=A0 =C2=A0Section 4.1:=C2=A0 "Note that x and y each con= stitute half the final
>=C2=A0 =C2=A0 =C2=A0session key material."=C2=A0 (change to 'h= alf of the')
>
>=C2=A0 =C2=A0 =C2=A0The figure in 4.1 does not have a caption, and also= , why is 'mac'
>=C2=A0 =C2=A0 =C2=A0lowercased?
>
>=C2=A0 =C2=A0 =C2=A0Sec 4.1.3.1 <http://4.1.3.1>:=C2=A0 "Sin= ce only little data is protected
>=C2=A0 =C2=A0 =C2=A0by this SA" (perhaps s/= little/a small amount/)
>
>=C2=A0 =C2=A0 =C2=A0Sec. 5.2.4:=C2=A0 "The following new HIT Suite= IDs are defined..." (s/IDs
>=C2=A0 =C2=A0 =C2=A0are/ID is/ because there is only one defined)
>
>=C2=A0 =C2=A0 =C2=A0Sec. 6.3:=C2=A0 "sort(HIT-I | HIT-R) is define= d as the network byte order
>=C2=A0 =C2=A0 =C2=A0concatenation of the two HITs... comparison of the = two HITs
>=C2=A0 =C2=A0 =C2=A0interpreted as positive (unsigned) 128-bit integers= in network byte
>=C2=A0 =C2=A0 =C2=A0order"=C2=A0 what does it mean to define a sor= t on a network byte order
>=C2=A0 =C2=A0 =C2=A0concatenation?=C2=A0 It seems perhaps clearer to le= ave endian issues out
>=C2=A0 =C2=A0 =C2=A0(they are implicit everywhere in a protocol) and ju= st define it as a
>=C2=A0 =C2=A0 =C2=A0comparison on HITs interpreted as unsigned 128-bit = integers (and by
>=C2=A0 =C2=A0 =C2=A0the way, is the full 128 bits including prefix incl= uded or just the
>=C2=A0 =C2=A0 =C2=A096 bits)?
>
>=C2=A0 =C2=A0 =C2=A0Sec. 6.5 through 6.8:=C2=A0 Unlike much of this dra= ft, these sections do
>=C2=A0 =C2=A0 =C2=A0not just specifically call out the differences from= the
>=C2=A0 =C2=A0 =C2=A0corresponding RFC 7401 sections, but instead restat= e the modified
>=C2=A0 =C2=A0 =C2=A0processing flow, and it is hard to spot what is dif= ferent here.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0wonder whether it would be clearer to just refer to= those processing
>=C2=A0 =C2=A0 =C2=A0steps in RFC 7401 that are changed.
>
>=C2=A0 =C2=A0 =C2=A0Sec. 8:=C2=A0 Can a MITM reply to I1 with ICMP para= meter problem, causing
>=C2=A0 =C2=A0 =C2=A0the true response (coming later) to be ignored beca= use the initiator
>=C2=A0 =C2=A0 =C2=A0already gave up?=C2=A0 Maybe clarify here or in sec= 5.4 to wait a little
>=C2=A0 =C2=A0 =C2=A0while before accepting the result of an ICMP.
>
>=C2=A0 =C2=A0 =C2=A0Sec. 10:=C2=A0 Consider to update the IANA section = in the style that RFC
>=C2=A0 =C2=A0 =C2=A08003 (and others) used, stating the history of the = registry and what
>=C2=A0 =C2=A0 =C2=A0exactly is requested to be changed.=C2=A0 For examp= le, something like
>=C2=A0 =C2=A0 =C2=A0"RFC 5201 and later RFC 7401 established the f= ollowing registry
>=C2=A0 =C2=A0 =C2=A0....=C2=A0 This document defines the following new = codepoints for that
>=C2=A0 =C2=A0 =C2=A0registry ..."
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0Hipsec mailing list
>=C2=A0 =C2=A0 =C2=A0Hips= ec@ietf.org <mailto:Hipsec@ietf.o= rg>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/hipsec
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/hipsec>
>
>

--001a113b0874ad057f054ba5643a-- From nobody Mon Mar 27 00:38:03 2017 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE4126CD8; Mon, 27 Mar 2017 00:37:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149060027598.7984.1316463177816365455@ietfa.amsl.com> Date: Mon, 27 Mar 2017 00:37:56 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 07:37:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-19.txt Pages : 53 Date : 2017-03-27 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19 https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 00:41:30 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97E129484 for ; Mon, 27 Mar 2017 00:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-0XYu3GEcXz for ; Mon, 27 Mar 2017 00:41:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6F801129473 for ; Mon, 27 Mar 2017 00:41:26 -0700 (PDT) X-AuditID: c1b4fb25-ccfff70000002d78-0b-58d8c2230599 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id F3.B5.11640.322C8D85; Mon, 27 Mar 2017 09:41:24 +0200 (CEST) Received: from [100.94.2.54] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.339.0; Mon, 27 Mar 2017 09:41:23 +0200 To: References: <149060027598.7984.1316463177816365455@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> Date: Mon, 27 Mar 2017 10:41:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <149060027598.7984.1316463177816365455@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM2K7lq7KoRsRBhsa5CymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN4lC5kLFghUXLiznKWB8RxPFyMnh4SAicTDG6sYQWwhgfWM Er2vfCHslYwSN67bgdjCAj4Sz49MZQexRQREJaZ8OM0MUeMkcW7HYrA4m4CWxKo718Hi/AKS EhsadoPZvAL2Ege+TwWbzyKgKvHh2EYwW1QgQmL+01VMEDWCEidnPmEBsTkFnCW2PFjMBmIz C1hIzJx/nhHC1pZYtvA10EwOoL0qEhePBU9gFJiFpHsWko5ZSDoWMDKvYhQtTi1Oyk03MtZL LcpMLi7Oz9PLSy3ZxAgMv4NbfqvuYLz8xvEQowAHoxIP7wPLGxFCrIllxZW5hxglOJiVRHh3 swCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYExgdhW5 sW1l/5ZNk9J+fD/Cb+m1OlC+60wU74vVnvf55i838FW6vLfs6VTp/CNztrnPv7dxz5W4zwvn fpA4eTL6rNOhtbP0FaM2XFya+8Pt6f2Ka6zGrZMEPx2ZZXRDpntj0mS3do3nF+0clr6fcCyr rlue+9a9lIUTZGMf3ZM/5GKhnXW+1n2OEktxRqKhFnNRcSIA3KT6hDsCAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 07:41:28 -0000 Hi, the preliminary version is now published as it is (except I had to=20 change publication the date). The suggestions from Christer are not yet=20 here and will require some time to be fixed. On 03/27/2017 10:37 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Native NAT Traversal Mode for the Host Identi= ty Protocol > Authors : Ari Keranen > Jan Mel=C3=A9n > Miika Komu > Filename : draft-ietf-hip-native-nat-traversal-19.txt > Pages : 53 > Date : 2017-03-27 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode i= s > based on the Interactive Connectivity Establishment (ICE) methodolog= y > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19 > https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-travers= al-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal= -19 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Mar 28 08:11:30 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB18129437 for ; Tue, 28 Mar 2017 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 gH2S_YMy5EuO for ; Tue, 28 Mar 2017 08:11:26 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-1.exch081.serverdata.net [199.193.204.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45F3128C83 for ; Tue, 28 Mar 2017 08:11:26 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Mar 2017 08:11:25 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Tue, 28 Mar 2017 08:11:24 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt Thread-Index: AQHSps0fIWTjXIZfMUO5wC1iptd8aaGows0AgAGauQA= Date: Tue, 28 Mar 2017 15:11:24 +0000 Message-ID: <73B2E25D-4444-46ED-8428-D07DBB9F22AC@temperednetworks.com> References: <149060027598.7984.1316463177816365455@ietfa.amsl.com> <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> In-Reply-To: <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: <7987DDA4B833644FBA79B46995C82311@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:11:29 -0000 SGkgTWlpa2EsDQpUaGUgbmV3IHBhcmFncmFwaCBvbiBrZWVwYWxpdmVzIChTZWN0aW9uIDUuMykg bG9va3MgZ29vZC4NCg0KRm9yIHRoZSBOT1RJRlkgY29kZSwgTkFUX0tFRVBBTElWRSB2YWx1ZSAo 4oCcVEJEIGJ5IElBTkE6IDE2Mzg04oCdKSBtYXliZSBzdWdnZXN0IDE2Mzg1PyAuLi5zaW5jZSB3 ZSBhbHJlYWR5IGhhdmUg4oCcSTJfQUNLTk9XTEVER0VNRU5UIDE2Mzg04oCdIGluIFJGQyA1MjAx IGFuZCBSRkMgNzQwMS4NCg0KdGhhbmtzLA0KLUplZmYNCg0KT24gMy8yNy8xNywgMTI6NDEgQU0s ICJIaXBzZWMgb24gYmVoYWxmIG9mIE1paWthIEtvbXUiIDxoaXBzZWMtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgbWlpa2Eua29tdUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgSGks DQogICAgDQogICAgdGhlIHByZWxpbWluYXJ5IHZlcnNpb24gaXMgbm93IHB1Ymxpc2hlZCBhcyBp dCBpcyAoZXhjZXB0IEkgaGFkIHRvIA0KICAgIGNoYW5nZSBwdWJsaWNhdGlvbiB0aGUgZGF0ZSku IFRoZSBzdWdnZXN0aW9ucyBmcm9tIENocmlzdGVyIGFyZSBub3QgeWV0IA0KICAgIGhlcmUgYW5k IHdpbGwgcmVxdWlyZSBzb21lIHRpbWUgdG8gYmUgZml4ZWQuDQogICAgDQogICAgT24gMDMvMjcv MjAxNyAxMDozNyBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4NCiAg ICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wgb2YgdGhlIElFVEYuDQogICAgPg0KICAg ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBOYXRpdmUgTkFUIFRyYXZlcnNhbCBNb2RlIGZv ciB0aGUgSG9zdCBJZGVudGl0eSBQcm90b2NvbA0KICAgID4gICAgICAgICBBdXRob3JzICAgICAg ICAgOiBBcmkgS2VyYW5lbg0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICBKYW4gTWVs w6luDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIE1paWthIEtvbXUNCiAgICA+IAlG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC0xOS50 eHQNCiAgICA+IAlQYWdlcyAgICAgICAgICAgOiA1Mw0KICAgID4gCURhdGUgICAgICAgICAgICA6 IDIwMTctMDMtMjcNCiAgICA+DQogICAgPiBBYnN0cmFjdDoNCiAgICA+ICAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGEgbmV3IE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdG9yIChOQVQpDQogICAg PiAgICB0cmF2ZXJzYWwgbW9kZSBmb3IgdGhlIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wgKEhJUCku ICBUaGUgbmV3IG1vZGUgaXMNCiAgICA+ICAgIGJhc2VkIG9uIHRoZSBJbnRlcmFjdGl2ZSBDb25u ZWN0aXZpdHkgRXN0YWJsaXNobWVudCAoSUNFKSBtZXRob2RvbG9neQ0KICAgID4gICAgYW5kIFVE UCBlbmNhcHN1bGF0aW9uIG9mIGRhdGEgYW5kIHNpZ25hbGluZyB0cmFmZmljLiAgVGhlIG1haW4N CiAgICA+ICAgIGRpZmZlcmVuY2UgZnJvbSB0aGUgcHJldmlvdXNseSBzcGVjaWZpZWQgbW9kZXMg aXMgdGhlIHVzZSBvZiBISVANCiAgICA+ICAgIG1lc3NhZ2VzIGZvciBhbGwgTkFUIHRyYXZlcnNh bCBwcm9jZWR1cmVzLg0KICAgID4NCiAgICA+DQogICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaGlwLW5hdGl2ZS1uYXQtdHJhdmVyc2FsLw0KICAgID4N CiAgICA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAg ICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0 LXRyYXZlcnNhbC0xOQ0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC0xOQ0KICAgID4NCiAgICA+IEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0 LXRyYXZlcnNhbC0xOQ0KICAgID4NCiAgICA+DQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQog ICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KICAgID4NCiAgICA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+IEhpcHNlYyBtYWlsaW5nIGxpc3QNCiAgICA+IEhp cHNlY0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9oaXBzZWMNCiAgICA+DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBIaXBzZWMgbWFpbGluZyBsaXN0DQogICAgSGlwc2VjQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oaXBzZWMN CiAgICANCg0K From nobody Tue Mar 28 09:16:49 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BCE1294A8 for ; Tue, 28 Mar 2017 09:16:47 -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_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 kWfC5ZiLygpI for ; Tue, 28 Mar 2017 09:16:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E447212940E for ; Tue, 28 Mar 2017 09:16:42 -0700 (PDT) X-AuditID: c1b4fb3a-4d72198000003958-68-58da8c69f2eb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id D1.45.14680.96C8AD85; Tue, 28 Mar 2017 18:16:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:16:07 +0200 From: Christer Holmberg To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt Thread-Index: AQHSps0fc4nv8AlHOUOYHVj4pmyJ76GoK+0AgAJDZhA= Date: Tue, 28 Mar 2017 16:16:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB32D46@ESESSMB109.ericsson.se> References: <149060027598.7984.1316463177816365455@ietfa.amsl.com> <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> In-Reply-To: <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7mW5mz60Ig9VrxSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCl7e9gLZslUXD61iLGBcY90FyMnh4SAicScyS+Zuhi5OIQE 1jNKfLtwixnCWcIocerfJvYuRg4ONgELie5/2iANIgK+Ev/X/GYHsYUFfCQ+TZvADhM/u2sb M4RtJfH31AlWEJtFQFVi0tXfLCA2L1DNvlf9jCC2kECFxNfG36wg4zkFHCTOXrMHCTMKiEl8 P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSTQueQI2hllAU2L9Ln2IVkWJKd0P 2SG2CkqcnPmEZQKjyCwkU2chdMxC0jELSccCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWb GIFBf3DLb6sdjAefOx5iFOBgVOLhfSB1M0KINbGsuDL3EKMEB7OSCO83bqAQb0piZVVqUX58 UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjHKcAZtmSaQWPYvkrknX+CCu x8h0eeHSR6dsrt19W/n1dONN94eO8i1bfs1aOD9r38UTR50uWgbo/CqKmJ3+SLChsiAo+LNC vcPsZXnvqzUULAK2iR1ZqKRfvTHiceoCz5izYg32Qar3hSovWt64GaNdeeNewoym6gexRZNi ZDMfLEnrOFnUpcRSnJFoqMVcVJwIAJqa2Wh2AgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:16:48 -0000 SGksDQoNCkFub3RoZXIgY29tbWVudDoNCg0KVGhlIGRyYWZ0IHJlZmVyZW5jZXMgc3BlY2lmaWMg c2VjdGlvbnMgaW4gZHJhZnQtaWNlLTUyNDViaXMuDQoNCk5vdGUgdGhhdCB0aGVyZSBpcyBzb21l IG9uZ29pbmcgcmUtc3RydWN0dXJpbmcgb2YgNTI0NWJpcywgd2hpY2ggbWVhbnMgdGhlIHNlY3Rp b24gbnVtYmVycyBtYXkgY2hhbmdlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGlwc2VjIFttYWlsdG86aGlwc2VjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWlrYSBLb211DQpTZW50OiAyNyBNYXJjaCAyMDE3IDEw OjQxDQpUbzogaGlwc2VjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0hpcHNlY10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1oaXAtbmF0aXZlLW5hdC10cmF2ZXJzYWwtMTkudHh0DQoNCkhpLA0KDQp0 aGUgcHJlbGltaW5hcnkgdmVyc2lvbiBpcyBub3cgcHVibGlzaGVkIGFzIGl0IGlzIChleGNlcHQg SSBoYWQgdG8gY2hhbmdlIHB1YmxpY2F0aW9uIHRoZSBkYXRlKS4gVGhlIHN1Z2dlc3Rpb25zIGZy b20gQ2hyaXN0ZXIgYXJlIG5vdCB5ZXQgaGVyZSBhbmQgd2lsbCByZXF1aXJlIHNvbWUgdGltZSB0 byBiZSBmaXhlZC4NCg0KT24gMDMvMjcvMjAxNyAxMDozNyBBTSwgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIHdyb3RlOg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wgb2YgdGhlIElFVEYu DQo+DQo+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogTmF0aXZlIE5BVCBUcmF2ZXJzYWwgTW9k ZSBmb3IgdGhlIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wNCj4gICAgICAgICBBdXRob3JzICAgICAg ICAgOiBBcmkgS2VyYW5lbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbiBNZWzDqW4N Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNaWlrYSBLb211DQo+IAlGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC0xOS50eHQNCj4gCVBhZ2Vz ICAgICAgICAgICA6IDUzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTAzLTI3DQo+DQo+IEFi c3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBOZXR3b3JrIEFkZHJl c3MgVHJhbnNsYXRvciAoTkFUKQ0KPiAgICB0cmF2ZXJzYWwgbW9kZSBmb3IgdGhlIEhvc3QgSWRl bnRpdHkgUHJvdG9jb2wgKEhJUCkuICBUaGUgbmV3IG1vZGUgaXMNCj4gICAgYmFzZWQgb24gdGhl IEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpIG1ldGhvZG9sb2d5 DQo+ICAgIGFuZCBVRFAgZW5jYXBzdWxhdGlvbiBvZiBkYXRhIGFuZCBzaWduYWxpbmcgdHJhZmZp Yy4gIFRoZSBtYWluDQo+ICAgIGRpZmZlcmVuY2UgZnJvbSB0aGUgcHJldmlvdXNseSBzcGVjaWZp ZWQgbW9kZXMgaXMgdGhlIHVzZSBvZiBISVANCj4gICAgbWVzc2FnZXMgZm9yIGFsbCBOQVQgdHJh dmVyc2FsIHByb2NlZHVyZXMuDQo+DQo+DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC8NCj4NCj4gVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1oaXAtbmF0aXZlLW5hdC10cmF2ZXJzYWwtMTkNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0 LXRyYXZlcg0KPiBzYWwtMTkNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1oaXAtbmF0aXZlLW5hdC10cmF2ZXJzYWwtDQo+IDE5DQo+DQo+DQo+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSGlwc2VjIG1haWxpbmcgbGlzdA0KPiBIaXBzZWNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oaXBzZWMNCj4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkhpcHNlYyBtYWlsaW5n IGxpc3QNCkhpcHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9oaXBzZWMNCg==