From thomas.r.henderson@boeing.com Mon Mar 11 14:14:30 2013 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 5877721F8F08 for ; Mon, 11 Mar 2013 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ksqz6U35k62c for ; Mon, 11 Mar 2013 14:14:29 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0D321F8EEA for ; Mon, 11 Mar 2013 14:14:29 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2BLESmS011185 for ; Mon, 11 Mar 2013 16:14:29 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2BLEQBH011158 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 11 Mar 2013 16:14:28 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 11 Mar 2013 14:14:26 -0700 From: "Henderson, Thomas R" To: HIP Date: Mon, 11 Mar 2013 14:14:26 -0700 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-rfc4843-bis Thread-Index: Ac4T9jzSgzr/f5qiS7y3hQQvAbZMPAKpfvaA Message-ID: <758141CC3D829043A8C3164DD3D593EA2E513280A3@XCH-NW-16V.nw.nos.boeing.com> References: <512C69B1.9010307@ericsson.com> In-Reply-To: <512C69B1.9010307@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "'julien.ietf@gmail.com'" , "'fdupont@isc.org'" Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc4843-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:14:30 -0000 This is a WGLC review of RFC4843-bis. In general, I only found what I regard to be minor issues, listed below. Suggested change to abstract OLD TEXT: They are designed to appear as application layer entities and at the existi= ng IPv6 APIs, but they should not appear in actual IPv6 headers. To make t= hem more like vanilla IPv6 addresses, they are expected to be routable at a= n overlay level. NEW TEXT: They are designed to appear as application layer entities and at the existi= ng IPv6 APIs, but they should not appear in actual IPv6 headers on networks= that route based on IPv6 addresses. Section 2 refers to the OGA ID. In RFC 5201-bis, the term "OGA" is used to= refer to the RFC4843-bis identifier, but in RFC4843-bis, it is called "OGA= ID". Suggest to modify RFC 5201-bis to rename "OGA" to "OGA ID", as appro= priate to align with RFC4843-bis. (Note that this is a proposal to change = RFC5201-bis to align with RFC4843-bis, and no RFC4843-bis action is necessa= ry) I suggest to change Section 3 title from "Routing Considerations" to "Routi= ng and Forwarding Considerations". Also, I suggest to delete the second pa= ragraph; we are no longer talking about experimental, and furthermore, the = MUST NOT clause gets into implementation issues. The first paragraph alrea= dy recommends to handle this via configuration. Perhaps it may also be clearer (in separating routing from forwarding in th= is section) to add a paragraph, after the existing first paragraph, dealing= with routing: "ORCHIDs are not designed for use in IPv6 routing protocols, since such rou= ting protocols are based on the architectural definition of IPv6 addresses.= Future non-IPv6 routing systems, such as overlay routing systems, may be = designed based on ORCHIDs. Any such ORCHID-based routing system is out of = scope of this document." I would suggest to delete the Section 3.1 entirely, as it still refers to t= he RFC4843 experiment and the discussion is out of scope, IMO. Section 4: Could this section be moved to an appendix, or just refer back = to RFC 4843? I also do not agree that the probability of collision is negl= igible; it can happen trivially if a host's keys are reused (consider a cop= ied virtual machine). If this section is retained in some fashion, I rec= ommend to delete the second paragraph, and to provide the caveat that "so l= ong as keys are not reused" to the first paragraph. I also don't recommend= going into a discussion of a node-wide unified database of ORCHIDs, since = it seems out of scope. Nits: Abstract: Cryptographic is misspelled in the abstract. Section 1: suggest to remove the adjective "vanilla", as it is colloquial t= erminology Section 1.2: =20 "Non-routability at the IP layer, by design." By design, or by policy? Section 2: Prefix should be changed from (IANA TBD 2001:11::/28 ?) to perh= aps (IANA TBD 2001:?::/28) References: I suppose it should refer back to 4843 as informative; also RF= C5201-bis is now updated from draft version 9. From thomas.r.henderson@boeing.com Mon Mar 11 14:57:08 2013 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 2075C21F90CA for ; Mon, 11 Mar 2013 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77ZtOG4zHGL2 for ; Mon, 11 Mar 2013 14:57:07 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 795BE21F90C7 for ; Mon, 11 Mar 2013 14:57:07 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2BLv6bY004870 for ; Mon, 11 Mar 2013 14:57:07 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2BLv5o7004862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 11 Mar 2013 14:57:06 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 11 Mar 2013 14:57:05 -0700 From: "Henderson, Thomas R" To: HIP Date: Mon, 11 Mar 2013 14:57:05 -0700 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis Thread-Index: Ac4T9dk+6S6Hees1S8uWgdkLMGYOsQKp7N4Q Message-ID: <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> References: <512C6912.1070206@ericsson.com> In-Reply-To: <512C6912.1070206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "'rgm@icsalabs.com'" Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:57:08 -0000 This is a WGLC review of RFC5202-bis. This draft seems to be close to being ready. There are two areas (more det= ail below) that IMO could be clarified or else left out of scope: 1) handling of simultaneous IPsec and HIP ESP 2) multiple SAs for differentiated services The supported transforms listed in Section 3.3.5 are out of date. The titl= e could be changed to "Supported Ciphers" to match the renaming of HIP_TRAN= SFORM to HIP_CIPHER in RFC5201-bis. SHA1 should be replaced with AES-256-C= BC (see section 5.2.8 of RFC 5201-bis). Section 3.3.5, ESP NULL encryption should be paired with SHA-256 instead of= SHA-1. Section 3.3.7, why is a value of 15 minutes specified for default inactivit= y timeout of 15 minutes? Could we instead avoid a magic number here and st= ate that an implementation SHOULD support a configurable SA timeout value? Section 3.4, third paragraph. I don't know the basis for the assertion tha= t HIP SA processing takes place always before the IPsec processing. Isn't = this implementation dependent? What HIP processing is being referred to he= re, pseudo-header manipulation, or more? Can we delete this paragraph, or = otherwise clarify? =20 Section 5.1: According to Section 5.2 of RFC 5201-bis, the HIP parameter t= ype code range devoted to transform-specific parameters is 2048-4095, so th= e values of 65 and 4095 should be reconsidered (what might be better values= in the allowed range?). Also, from an editorial perspective, the last sen= tence regarding NOTIFY should follow the table of two ESP transport paramet= ers. In section 5.1.1, the second paragraph states that setting up of multiple S= As for multihoming is out of scope. However, the next paragraph discusses = the setting of multiple SAs for differentiated services. It seems to me th= at this is underspecified, particularly how the coordination of selectors b= etween hosts is done and how to manage the KEYMAT and expiry/renewal of mul= tiple SAs. Should this be removed for now and left for further study? Section 5.1.2 crypto choices need alignment with current RFC5201-bis. Valu= e 2 (3DES) should be deprecated. Value 5 should probably be deprecated. A= ll references to HMAC-SHA-2 should be HMAC-SHA-256. Should HMAC-SHA-384 va= riants be encoded? The two mandatory implementations should be the SHA256 = variants. Throughout Section 5.1, the draft should be updated to substitute NOTIFICAT= ION for NOTIFY when referring to the parameter (this is to align with a cha= nge in RFC5201-bis). Section 5.2.1.1 should replace HMAC-SHA1 with HMAC-SHA256. The same change= should be made in 5.2.1.2. Section 6 should update the HIP protocol number to 139 (from 253). Do we want to reference the tunneling of ESP over UDP? Nits: section 3, "new" is misspelled as "npew". Perhaps the word "new" is unnece= ssary here and later in this paragraph. Section 3.2 probably should be clarified (qualified) that a standards compl= iant, unmodified IPsec implementation can be used "in conjunction with some= additional transport checksum processing above it, and if IP addresses are= used as indexes to the right host context". =20 Section 3.3.4, "IKE" is used for the first time without expansion, and with= out reference to the RFC. Also, change "partner" to "peer" in the next sen= tence. Section 5.1.1, the first sentence is duplicated. From petri.jokela@nomadiclab.com Tue Mar 26 04:18:15 2013 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 480D721F8A38 for ; Tue, 26 Mar 2013 04:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n2v6Sv4DpjK for ; Tue, 26 Mar 2013 04:18:14 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9F21F883A for ; Tue, 26 Mar 2013 04:18:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id DA7A04E6F7; Tue, 26 Mar 2013 13:18:12 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG9p1adsgfgU; Tue, 26 Mar 2013 13:18:12 +0200 (EET) Received: from [IPv6:::1] (inside.nomadiclab.com [10.0.0.2]) by gw.nomadiclab.com (Postfix) with ESMTP id C54EE4E6F5; Tue, 26 Mar 2013 13:18:11 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Petri Jokela In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> Date: Tue, 26 Mar 2013 13:18:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B2FF585-29CF-453F-A4B0-5C3A090AB990@nomadiclab.com> References: <512C6912.1070206@ericsson.com> <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1283) Cc: HIP , "'rgm@icsalabs.com'" Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2013 11:18:15 -0000 Hi,=20 Comments and questions follow. If I haven't commented, I have just = changed it in the draft.=20 The current version can be found from: http://jokela.org/ietf/draft-ietf-hip-rfc5202-bis-02-pre1.txt > The supported transforms listed in Section 3.3.5 are out of date. The = title could be changed to "Supported Ciphers" to match the renaming of = HIP_TRANSFORM to HIP_CIPHER in RFC5201-bis. SHA1 should be replaced = with AES-256-CBC (see section 5.2.8 of RFC 5201-bis). >=20 > Section 3.3.5, ESP NULL encryption should be paired with SHA-256 = instead of SHA-1. >=20 > Section 3.3.7, why is a value of 15 minutes specified for default = inactivity timeout of 15 minutes? Could we instead avoid a magic number = here and state that an implementation SHOULD support a configurable SA = timeout value? >=20 > Section 3.4, third paragraph. I don't know the basis for the = assertion that HIP SA processing takes place always before the IPsec = processing. Isn't this implementation dependent? What HIP processing = is being referred to here, pseudo-header manipulation, or more? Can we = delete this paragraph, or otherwise clarify? =20 I think there was a reason to do this, but I have no idea what it was. = Does it make any sense, or shall we delete it? > Section 5.1: According to Section 5.2 of RFC 5201-bis, the HIP = parameter type code range devoted to transform-specific parameters is = 2048-4095, so the values of 65 and 4095 should be reconsidered (what = might be better values in the allowed range?). Also, from an editorial = perspective, the last sentence regarding NOTIFY should follow the table = of two ESP transport parameters. Should the first value be from the beginning of the area and the second = one from somewhere in the middle? I don't know if it does matter, but = originally they were selected with that principle. So, 2049 and 3072 = perhaps? I moved the last sentence to follow the table.=20 >=20 > In section 5.1.1, the second paragraph states that setting up of = multiple SAs for multihoming is out of scope. However, the next = paragraph discusses the setting of multiple SAs for differentiated = services. It seems to me that this is underspecified, particularly how = the coordination of selectors between hosts is done and how to manage = the KEYMAT and expiry/renewal of multiple SAs. Should this be removed = for now and left for further study? I removed the paragraph.=20 > Section 5.1.2 crypto choices need alignment with current RFC5201-bis. = Value 2 (3DES) should be deprecated. Value 5 should probably be = deprecated. All references to HMAC-SHA-2 should be HMAC-SHA-256. = Should HMAC-SHA-384 variants be encoded? The two mandatory = implementations should be the SHA256 variants. Listed the following as mandatory: Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL with HMAC-SHA-256. >=20 > Throughout Section 5.1, the draft should be updated to substitute = NOTIFICATION for NOTIFY when referring to the parameter (this is to = align with a change in RFC5201-bis). I hope I changed them correctly everywhere.=20 >=20 > Section 5.2.1.1 should replace HMAC-SHA1 with HMAC-SHA256. The same = change should be made in 5.2.1.2. Changed now to AES-128-CBC + HMAC-SHA-256. Or should it be AES-256-CBC? >=20 > Section 6 should update the HIP protocol number to 139 (from 253). >=20 > Do we want to reference the tunneling of ESP over UDP? Here I cannot say anything. Any opinions from others? >=20 > Nits: > section 3, "new" is misspelled as "npew". Perhaps the word "new" is = unnecessary here and later in this paragraph. >=20 > Section 3.2 probably should be clarified (qualified) that a standards = compliant, unmodified IPsec implementation can be used "in conjunction = with some additional transport checksum processing above it, and if IP = addresses are used as indexes to the right host context". >=20 > Section 3.3.4, "IKE" is used for the first time without expansion, and = without reference to the RFC. Also, change "partner" to "peer" in the = next sentence. >=20 > Section 5.1.1, the first sentence is duplicated. Petri --=20 Petri Jokela Senior researcher NomadicLab, Ericsson Research Oy L M Ericsson Ab =20 E-mail: petri.jokela@ericsson.com Mobile: +358 44 299 2413 From mkomu@cs.hut.fi Tue Mar 26 06:44:25 2013 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 83BD421F8B45 for ; Tue, 26 Mar 2013 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6WejvSo+u20 for ; Tue, 26 Mar 2013 06:44:25 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id D910821F8AD6 for ; Tue, 26 Mar 2013 06:44:24 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id A2F28308486; Tue, 26 Mar 2013 15:44:22 +0200 (EET) Message-ID: <5151A635.3040405@cs.hut.fi> Date: Tue, 26 Mar 2013 15:44:21 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Petri Jokela , HIP References: <512C6912.1070206@ericsson.com> <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> <9B2FF585-29CF-453F-A4B0-5C3A090AB990@nomadiclab.com> In-Reply-To: <9B2FF585-29CF-453F-A4B0-5C3A090AB990@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2013 13:44:25 -0000 Hi, On 03/26/2013 01:18 PM, Petri Jokela wrote: >> >Section 6 should update the HIP protocol number to 139 (from 253). >> > >> >Do we want to reference the tunneling of ESP over UDP? > Here I cannot say anything. Any opinions from others? how are the RFCs bundled together for the standards track, or would this create an undesired dependencies? If it creates such a dependency, can it be avoided by referencing NAT specification as informational? From ari.keranen@ericsson.com Thu Mar 28 12:22:44 2013 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 CEE0421F8E99 for ; Thu, 28 Mar 2013 12:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thM15PrHmr+G for ; Thu, 28 Mar 2013 12:22:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D059721F8E5D for ; Thu, 28 Mar 2013 12:22:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-9c-51549882d420 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E1.73.10459.28894515; Thu, 28 Mar 2013 20:22:42 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 28 Mar 2013 20:22:42 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 331412368; Thu, 28 Mar 2013 21:22:42 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 79FF754902; Thu, 28 Mar 2013 21:22:39 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2DDF753147; Thu, 28 Mar 2013 21:22:39 +0200 (EET) Message-ID: <51549880.5030904@ericsson.com> Date: Thu, 28 Mar 2013 21:22:40 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Miika Komu References: <512C6912.1070206@ericsson.com> <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> <9B2FF585-29CF-453F-A4B0-5C3A090AB990@nomadiclab.com> <5151A635.3040405@cs.hut.fi> In-Reply-To: <5151A635.3040405@cs.hut.fi> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrW7TjJBAg+WfrS2mLprMbNG87Tmb xZ2J59kdmD1e9a9l9liy5CeTR+ei6ADmKC6blNSczLLUIn27BK6Mb8dtC/azVTzbdpaxgXEa axcjJ4eEgInEsU9nmCFsMYkL99azgdhCAicZJZ5eF+li5AKyNzBK3N69gx3C2cUocX9hEyOE s5ZR4uK2dcwQznJGibPbVoD18wpoS0x60Qw2l0VAVeLt8mVMIDabgL3EzQnX2UFsUYFkiav/ P7FA1AtKnJz5BMwWEVCQWDX5CJjNLOAqseXPSrBeYQEzic0f9kEtO8EoMav9FlARBwengKbE nS12EPW2EhfmXIfqlZfY/nYO1G9qElfPbWKG+E1V4uq/V4wTGEVnIVk9C0n7LCTtCxiZVzGy 5yZm5qSXG25iBEbCwS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZG+yP3TBYVhte3c7cHsGom3Zzgq6ckNT/xYafkbs7p0cy6NT4bjuSr9ubMfJc6p93r 5QWDo+YVPhxaBst7OqymzH8uYBXAo3l8xc+12Qs+KGRsvyXEFXHLIZTjzEvhvxnhU/nXdiyb qjMroNrWVtfhjW/1ay6jP3wXvNfsu3KFu2e7OtvhdyuUWIozEg21mIuKEwGnbKipUgIAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 19:22:44 -0000 Hi, On 3/26/13 3:44 PM, Miika Komu wrote: > On 03/26/2013 01:18 PM, Petri Jokela wrote: >>> >Section 6 should update the HIP protocol number to 139 (from 253). >>> > >>> >Do we want to reference the tunneling of ESP over UDP? >> Here I cannot say anything. Any opinions from others? > > how are the RFCs bundled together for the standards track, or would this > create an undesired dependencies? If it creates such a dependency, can > it be avoided by referencing NAT specification as informational? I think mentioning this possibility could make sense since "HIP doesn't work through NATs" seems to be one of the biggest misconceptions people have had about HIP. However, I don't see any reason why it should be a normative reference, so informative (and hence not blocking) would be fine. Cheers, Ari From thomas.r.henderson@boeing.com Thu Mar 28 13:26:17 2013 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 92A1121F8FDB for ; Thu, 28 Mar 2013 13:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNHY1Met4ohs for ; Thu, 28 Mar 2013 13:26:17 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8AD21F8A3E for ; Thu, 28 Mar 2013 13:26:17 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2SKQGXf019096 for ; Thu, 28 Mar 2013 15:26:16 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2SKPmOF018755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 28 Mar 2013 15:26:15 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 28 Mar 2013 13:25:59 -0700 From: "Henderson, Thomas R" To: =?iso-8859-1?Q?=27Ari_Ker=E4nen=27?= , Miika Komu Date: Thu, 28 Mar 2013 13:25:57 -0700 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis Thread-Index: Ac4r6aZuvILmYtGUTHC1WcLe6qakIwAB9yyg Message-ID: <758141CC3D829043A8C3164DD3D593EA2E51328164@XCH-NW-16V.nw.nos.boeing.com> References: <512C6912.1070206@ericsson.com> <758141CC3D829043A8C3164DD3D593EA2E513280A6@XCH-NW-16V.nw.nos.boeing.com> <9B2FF585-29CF-453F-A4B0-5C3A090AB990@nomadiclab.com> <5151A635.3040405@cs.hut.fi> <51549880.5030904@ericsson.com> In-Reply-To: <51549880.5030904@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 20:26:17 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Ari Ker=E4nen > Sent: Thursday, March 28, 2013 12:23 PM > To: Miika Komu > Cc: HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis >=20 > Hi, >=20 > On 3/26/13 3:44 PM, Miika Komu wrote: > > On 03/26/2013 01:18 PM, Petri Jokela wrote: > >>> >Section 6 should update the HIP protocol number to 139 (from 253). > >>> > > >>> >Do we want to reference the tunneling of ESP over UDP? > >> Here I cannot say anything. Any opinions from others? > > > > how are the RFCs bundled together for the standards track, or would > > this create an undesired dependencies? If it creates such a > > dependency, can it be avoided by referencing NAT specification as > informational? >=20 > I think mentioning this possibility could make sense since "HIP doesn't > work through NATs" seems to be one of the biggest misconceptions people > have had about HIP. However, I don't see any reason why it should be a > normative reference, so informative (and hence not blocking) would be > fine. >=20 It could be done with reference to published RFCs, just to declare that it = is out of scope of this document and handled elsewhere. e.g. something like this at the end of Introduction, with two informative r= eferences. "HIP and ESP traffic have known issues with middlebox traversal [RFC5207]. = Other specifications exist for operating HIP and ESP over UDP ([RFC5770] i= s an experimental specification, and others are being developed). Middlebo= x traversal is out of scope for this document." From julien.ietf@gmail.com Thu Mar 28 14:01:46 2013 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 7014C21F8F16 for ; Thu, 28 Mar 2013 14:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWdGB1eNF+9y for ; Thu, 28 Mar 2013 14:01:45 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8D12321F8F1F for ; Thu, 28 Mar 2013 14:01:45 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so7024971veb.40 for ; Thu, 28 Mar 2013 14:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PE+HzX+qof5trm4xUB3BCJj+J3AQzEu8gaQWr5YlsHQ=; b=BBYiOA2utrTiFZl9MvLJH11Ui2684mNKwJuAmbg8/NsrMK1BtNc3ojWgU108pyKYAj +OurEkTS0n2ldgCkCy14bijXM5XlJA30KN4Vi+WzL6wNrLzl7s/99FqJPyBZkg9reh3P Kks9n05mZylKhujqUc8a3Kzaih9A4vsTHUE639wzauwfz2QUO8cwP2VOTINbw9liij8M dtKBqZbkxLgyTsDtajtHEN+tVYkg59uLy8SzgpSM0pSP77zsMsCn/+m+g1Hdrm9RfJiv IULwRAwwYvKnXR3UDrjSMBwQFEDcKQ4iAT606QY9aW5gV5i7tRbkWlfxLAr/PJ0pOPuZ T+jw== MIME-Version: 1.0 X-Received: by 10.58.43.169 with SMTP id x9mr121696vel.13.1364504505078; Thu, 28 Mar 2013 14:01:45 -0700 (PDT) Received: by 10.52.17.207 with HTTP; Thu, 28 Mar 2013 14:01:44 -0700 (PDT) In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E513280A3@XCH-NW-16V.nw.nos.boeing.com> References: <512C69B1.9010307@ericsson.com> <758141CC3D829043A8C3164DD3D593EA2E513280A3@XCH-NW-16V.nw.nos.boeing.com> Date: Thu, 28 Mar 2013 14:01:44 -0700 Message-ID: From: Julien Laganier To: "Henderson, Thomas R" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: HIP , "fdupont@isc.org" Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc4843-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 21:01:46 -0000 Hi Tom, Thanks for reviewing the document. My comments inline below: On Mon, Mar 11, 2013 at 2:14 PM, Henderson, Thomas R wrote: > This is a WGLC review of RFC4843-bis. > > In general, I only found what I regard to be minor issues, listed below. > > Suggested change to abstract > OLD TEXT: > They are designed to appear as application layer entities and at the exis= ting IPv6 APIs, but they should not appear in actual IPv6 headers. To make= them more like vanilla IPv6 addresses, they are expected to be routable at= an overlay level. > NEW TEXT: > They are designed to appear as application layer entities and at the exis= ting IPv6 APIs, but they should not appear in actual IPv6 headers on networ= ks that route based on IPv6 addresses. I'd rather not change the statement that they should not appear in actual IPv6 headers as this could become a red herring to our argument that ORCHID allocation is useful and _harmless_. As per your comment below a will replace vanilla by normal or regular. > Section 2 refers to the OGA ID. In RFC 5201-bis, the term "OGA" is used = to refer to the RFC4843-bis identifier, but in RFC4843-bis, it is called "O= GA ID". Suggest to modify RFC 5201-bis to rename "OGA" to "OGA ID", as app= ropriate to align with RFC4843-bis. (Note that this is a proposal to chang= e RFC5201-bis to align with RFC4843-bis, and no RFC4843-bis action is neces= sary) Ok. > I suggest to change Section 3 title from "Routing Considerations" to "Rou= ting and Forwarding Considerations". Also, I suggest to delete the second = paragraph; we are no longer talking about experimental, and furthermore, th= e MUST NOT clause gets into implementation issues. The first paragraph alr= eady recommends to handle this via configuration. While I agree we are no longer talking about experimental, are we sure we want to leave out the recommendation that the ORCHID prefix not be hardcoded into data path? Seems to me it is still valuable. > Perhaps it may also be clearer (in separating routing from forwarding in = this section) to add a paragraph, after the existing first paragraph, deali= ng with routing: > > "ORCHIDs are not designed for use in IPv6 routing protocols, since such r= outing protocols are based on the architectural definition of IPv6 addresse= s. Future non-IPv6 routing systems, such as overlay routing systems, may b= e designed based on ORCHIDs. Any such ORCHID-based routing system is out o= f scope of this document." Ok. > I would suggest to delete the Section 3.1 entirely, as it still refers to= the RFC4843 experiment and the discussion is out of scope, IMO. Ok. > Section 4: Could this section be moved to an appendix, or just refer bac= k to RFC 4843? I also do not agree that the probability of collision is ne= gligible; it can happen trivially if a host's keys are reused (consider a c= opied virtual machine). If this section is retained in some fashion, I r= ecommend to delete the second paragraph, and to provide the caveat that "so= long as keys are not reused" to the first paragraph. I also don't recomme= nd going into a discussion of a node-wide unified database of ORCHIDs, sinc= e it seems out of scope. Ok. Will move to appendix, and add the key reuse caveat, as well as remove the discussion on the node-wide database. > > Nits: > Abstract: Cryptographic is misspelled in the abstract. Ok. > Section 1: suggest to remove the adjective "vanilla", as it is colloquial= terminology Ok. Will replace by normal or regular. > Section 1.2: > "Non-routability at the IP layer, by design." By design, or by policy? I guess by design, since we are not providing the means to route at the IP layer - they do not have prefix on which longest prefix match can occur... > Section 2: Prefix should be changed from (IANA TBD 2001:11::/28 ?) to pe= rhaps (IANA TBD 2001:?::/28) Ok. > References: I suppose it should refer back to 4843 as informative; also = RFC5201-bis is now updated from draft version 9. Ok. --julien From julien.ietf@gmail.com Thu Mar 28 16:36:58 2013 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 899F221F8F7A for ; Thu, 28 Mar 2013 16:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G65c1ObPKW-5 for ; Thu, 28 Mar 2013 16:36:58 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id EB61321F8F0F for ; Thu, 28 Mar 2013 16:36:54 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id kw10so75930vcb.0 for ; Thu, 28 Mar 2013 16:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Xe1W6BLRSYl7CDymXHiKIfpdKsxLiefIcveamkKA6Ik=; b=VumG6EQ92Q+l6mQfsw2cBkW0Opv4JK+8/f/0pyKjHxdZcngQaJc807SEsI2JSNKFZw Zaw9b7Ft3BzjEsvwL9IuLYDkV9+Z6VbXpwwByQ4+viejE93nqKwgXNfFBti/t3fj+tI2 RZ0R7eOkQlKsOqo3VsC+PMrcfYkqw1NJJWGCpsD9Yd2+oVgVzxVNjocJnkMdfCAbi1Ar lM170KEPDYIaAxmaRyOqnFVQS80Jmu2UW9AuuyDKIWLJnVSYVZNX7iWDXXjtBs2YwHuw 9AyfZ+DGryX5ExdButH2IbguYGlhUBuYaPD30eMUcuBseumn3qgiTBKwuwA5wfcw7Emv r4dA== MIME-Version: 1.0 X-Received: by 10.58.43.169 with SMTP id x9mr532329vel.13.1364513814371; Thu, 28 Mar 2013 16:36:54 -0700 (PDT) Received: by 10.52.17.207 with HTTP; Thu, 28 Mar 2013 16:36:54 -0700 (PDT) In-Reply-To: <50B48A1A.1080609@cs.hut.fi> References: <50B48A1A.1080609@cs.hut.fi> Date: Thu, 28 Mar 2013 16:36:54 -0700 Message-ID: From: Julien Laganier To: Miika Komu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: hip WG Subject: Re: [Hipsec] HIP-based anycast X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2013 23:36:58 -0000 Hi, HIP anycast would need a HIT to identify the members of the anycast group, wouldn't it? So why not have a key pair generated for the group, and the HIT derived from the public key be the anycast HIT. One could then use the group anycast key pair to sign authorization certificates granting membership into the group. Similar concept has been explored for IPv6 multicast and anycast group in: CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in ipv6 with cryptographically generated addresses. In The Eighth IEEE Symposium on Computers and Communications (ISCC=922003). --julien On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu wrote: > Hi, > > opportunistic mode with the help of a rendezvous server could be used for > implementing HIP-based anycast. The current RVS specification does not al= low > this: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 > > 4.3.1. Processing Outgoing I1 Packets > > An initiator SHOULD NOT send an opportunistic I1 with a NULL > destination HIT to an IP address that is known to be a rendezvous > server address, unless it wants to establish a HIP association with > the rendezvous server itself and does not know its HIT. > > I think we could specify either a flag in the base exchange or alternativ= ely > a special HIT encoding for the "NULL" destination HIT in the I1. What do = you > think? > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From mkomu@cs.hut.fi Sat Mar 30 12:57:11 2013 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 B2B8C21F8653 for ; Sat, 30 Mar 2013 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj+bkyk7GOCK for ; Sat, 30 Mar 2013 12:57:11 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id F041221F8650 for ; Sat, 30 Mar 2013 12:57:10 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 1557630806F; Sat, 30 Mar 2013 21:57:09 +0200 (EET) Message-ID: <51574394.3070208@cs.hut.fi> Date: Sat, 30 Mar 2013 21:57:08 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Julien Laganier References: <50B48A1A.1080609@cs.hut.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hip WG Subject: Re: [Hipsec] HIP-based anycast X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 30 Mar 2013 19:57:11 -0000 Hi Julien, I'll have to the check the reference in more detail. Surely, shared private keys at the server side are certainly one possibility, but the compromise of a single host would then compromise the entire group? I was originally thinking that the IP address of rendezvous server would identify the group, but admit this can be somewhat limiting. For instance, an additional parameter in the I1 could identify the group. Clearly, multicast is outside of the scope of this WG, but I was considering if the specifications are future proof with such an approach since now the opportunistic base exchange is always terminated at the rendezvous server. P.S. I'll automatically assume this discussion shouldn't affect the specs at all if this topic doesn't gather too much discussion (and it's quite a late in process, anyway). On 03/29/2013 01:36 AM, Julien Laganier wrote: > Hi, > > HIP anycast would need a HIT to identify the members of the anycast > group, wouldn't it? > > So why not have a key pair generated for the group, and the HIT > derived from the public key be the anycast HIT. One could then use the > group anycast key pair to sign authorization certificates granting > membership into the group. Similar concept has been explored for IPv6 > multicast and anycast group in: > > CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in > ipv6 with cryptographically > generated addresses. In The Eighth IEEE Symposium on Computers and > Communications > (ISCC’2003). > > --julien > > > On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu wrote: >> Hi, >> >> opportunistic mode with the help of a rendezvous server could be used for >> implementing HIP-based anycast. The current RVS specification does not allow >> this: >> >> http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 >> >> 4.3.1. Processing Outgoing I1 Packets >> >> An initiator SHOULD NOT send an opportunistic I1 with a NULL >> destination HIT to an IP address that is known to be a rendezvous >> server address, unless it wants to establish a HIP association with >> the rendezvous server itself and does not know its HIT. >> >> I think we could specify either a flag in the base exchange or alternatively >> a special HIT encoding for the "NULL" destination HIT in the I1. What do you >> think? >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > From julien.ietf@gmail.com Sun Mar 31 18:17:10 2013 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 C329021F86BC for ; Sun, 31 Mar 2013 18:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPRXo6-ZoExB for ; Sun, 31 Mar 2013 18:17:09 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7021F869C for ; Sun, 31 Mar 2013 18:17:09 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id db10so2073987veb.9 for ; Sun, 31 Mar 2013 18:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ihJQfiWeTHADPtE7ws9xdNwU2kMhswkqN3ndcvQQ0Yo=; b=XttMhIHiIKURonJUQk+CB/ceMMi/de6Kr3Wg7Vm9wVFsfJy/QydHVECgbTNjCjrevB ONjR6kTDtvWGpjbGA2Nd+kYLvTI+cjWNLl8K56MQ8QYvTG55bn3A+P07JEkMWLWs+UCG F35ar9z6QOW3pDopWYVRxm4JHh97dy3TQyv1Nmozkei91BkN1dRiH2h5j66NSw46vvr7 C0xGZ0GaSai/IEd+gAs4cMJdvb6c8KYcK74TMVLO9VoNh+LzT9RN+4N129hTVSldct7U HfYWwQ2AKXDGAinY4am5tAAsjvY+WMuEwK2MvbrZmkb+O+GuVh0UClMgtJqQyxEbYk1c ViFA== MIME-Version: 1.0 X-Received: by 10.220.76.129 with SMTP id c1mr7784861vck.48.1364779028491; Sun, 31 Mar 2013 18:17:08 -0700 (PDT) Received: by 10.52.17.207 with HTTP; Sun, 31 Mar 2013 18:17:08 -0700 (PDT) In-Reply-To: <51574394.3070208@cs.hut.fi> References: <50B48A1A.1080609@cs.hut.fi> <51574394.3070208@cs.hut.fi> Date: Sun, 31 Mar 2013 18:17:08 -0700 Message-ID: From: Julien Laganier To: Miika Komu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: hip WG Subject: Re: [Hipsec] HIP-based anycast X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2013 01:17:10 -0000 Hi Miika, I don't think we're at a stage where it is feasible to retrofit support for future extensions in the base HIP specifications. As to the group key pair, it isn't shared on the server. The anycast group controller holds the key pair, and uses it to derive the group anycast HIT, and issue authorization certificates to group members who own their own individual key pairs. SPKI authorization certificates can be used for this purpose. --julien On Sat, Mar 30, 2013 at 12:57 PM, Miika Komu wrote: > Hi Julien, > > I'll have to the check the reference in more detail. Surely, shared priva= te > keys at the server side are certainly one possibility, but the compromise= of > a single host would then compromise the entire group? > > I was originally thinking that the IP address of rendezvous server would > identify the group, but admit this can be somewhat limiting. For instance= , > an additional parameter in the I1 could identify the group. Clearly, > multicast is outside of the scope of this WG, but I was considering if th= e > specifications are future proof with such an approach since now the > opportunistic base exchange is always terminated at the rendezvous server= . > > P.S. I'll automatically assume this discussion shouldn't affect the specs= at > all if this topic doesn't gather too much discussion (and it's quite a la= te > in process, anyway). > > > On 03/29/2013 01:36 AM, Julien Laganier wrote: >> >> Hi, >> >> HIP anycast would need a HIT to identify the members of the anycast >> group, wouldn't it? >> >> So why not have a key pair generated for the group, and the HIT >> derived from the public key be the anycast HIT. One could then use the >> group anycast key pair to sign authorization certificates granting >> membership into the group. Similar concept has been explored for IPv6 >> multicast and anycast group in: >> >> CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in >> ipv6 with cryptographically >> generated addresses. In The Eighth IEEE Symposium on Computers and >> Communications >> (ISCC=922003). >> >> --julien >> >> >> On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu wrote: >>> >>> Hi, >>> >>> opportunistic mode with the help of a rendezvous server could be used f= or >>> implementing HIP-based anycast. The current RVS specification does not >>> allow >>> this: >>> >>> http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 >>> >>> 4.3.1. Processing Outgoing I1 Packets >>> >>> An initiator SHOULD NOT send an opportunistic I1 with a NULL >>> destination HIT to an IP address that is known to be a rendezvous >>> server address, unless it wants to establish a HIP association with >>> the rendezvous server itself and does not know its HIT. >>> >>> I think we could specify either a flag in the base exchange or >>> alternatively >>> a special HIT encoding for the "NULL" destination HIT in the I1. What d= o >>> you >>> think? >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> >