From hipsec-bounces@lists.ietf.org Tue Sep 04 12:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISar2-0006bk-AB; Tue, 04 Sep 2007 12:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISar0-0006ZH-Qz for hipsec@ietf.org; Tue, 04 Sep 2007 12:02:14 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaqz-0005XA-Ez for hipsec@ietf.org; Tue, 04 Sep 2007 12:02:14 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l84G23FF027744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Sep 2007 11:02:04 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l84G21kQ024023; Tue, 4 Sep 2007 09:02:01 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l84G1Uks022525; Tue, 4 Sep 2007 09:01:32 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 09:01:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NAT Traversal in HIP Date: Tue, 4 Sep 2007 09:01:31 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049757@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] NAT Traversal in HIP Thread-Index: AcfrljF3HEHkTX8mRqSBGuC5hW2mgQDdP+uQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 04 Sep 2007 16:01:31.0658 (UTC) FILETIME=[DC36E6A0:01C7EF0C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, some responses inline: > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Thursday, August 30, 2007 11:14 PM > To: Henderson, Thomas R > Cc: Pekka Nikander; Gonzalo Camarillo; HIP > Subject: RE: [Hipsec] NAT Traversal in HIP >=20 > On Wed, 29 Aug 2007, Henderson, Thomas R wrote: >=20 > Hi Tom, >=20 > >> Gonzalo, all, > >> > >>> 1) Shall we use the ICE methodology or not? > >> > >> In the long run, I think we should use ICE *methodology*. On the > >> other hand, I think it would be *good* for people to=20 > experiment with > >> lesser functionality very soon, i.e., now. But the latter can be > >> done by the experimenters agreeing on some interim draft=20 > and working > >> from that. The WG doesn't need to be directly involved. > > > > I agree that there should be some experimental work done=20 > before we can > > reach a definitive conclusion. From my perspective, I am=20 > inclined to > > try to take an existing ICE library and modify it as little=20 > as possible > > to make it work with our HIP implementation. >=20 > Yes, it seems tempting implementation wise, but I have=20 > expressed several=20 > concerns on this list which should be addressed first.=20 I am not suggesting that existing ICE library is the answer, but that I would rather look at the existing capabilities first of ICE and also the Cornell NUTSS software to see how much is already there. I guess that my point is that if you start writing the HIP relay server from scratch, you miss the opportunity to learn how existing approaches can be leveraged. That is why I just said that my inclination is to try the existing approaches first and see where the holes may be. > The=20 > major problems=20 > seem to be: >=20 > * HIP Relay server: this is needed for guaranteed NAT traversal. > The relay has to forward HIP control packets which contain=20 > the transport > address candidates. So we can't use STUN servers for this. I think that this is an open question that deserves further study. > * HIP mobility and multihoming: this will get messy with ICE? This may > also reduce code reusability from ICE significantly. This (messiness) is probably true, although code reuse ultimately is not the main goal. >=20 > I have also expressed other concerns, such as security related, in my=20 > earlier emails and won't repeat them here. I hope that people=20 > address the=20 > issues that have been presented on this list on a technical=20 > level. In the=20 > end, we should select single approach to support interoperability. I think I would say the goal is to achieve interoperability, and whether a single or multiple approaches leads to this is for further study. I appreciate that you have already done a lot of work on this and maybe I just need to catch up to your level of understanding. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 05 02:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoN2-0006NZ-QM; Wed, 05 Sep 2007 02:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoN0-0006NT-18 for hipsec@ietf.org; Wed, 05 Sep 2007 02:28:12 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISoMx-0000Vd-8P for hipsec@ietf.org; Wed, 05 Sep 2007 02:28:09 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNV00KW7TXLBD@szxga04-in.huawei.com> for hipsec@ietf.org; Wed, 05 Sep 2007 14:27:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNV00GSMTXKYR@szxga04-in.huawei.com> for hipsec@ietf.org; Wed, 05 Sep 2007 14:27:21 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNV00IHWTXG45@szxml04-in.huawei.com> for hipsec@ietf.org; Wed, 05 Sep 2007 14:27:20 +0800 (CST) Date: Wed, 05 Sep 2007 14:27:13 +0800 From: JiangXingFeng Subject: RE: [Hipsec] Comment on draft-ietf-hip-base-08 In-reply-to: <058F505E-282B-4023-9B77-ACD153F6759E@nomadiclab.com> To: 'Pekka Nikander' , 'Philip Matthews' Message-id: <003901c7ef85$cc1a6840$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfrypBJP6io5FMdQ1+6C7xHg75i0ADufkQA X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, Pekka: There is another question about the computation of the HIP checksum. In order to traverse some middle-boxes, such as NATs, HIP packet will delivered over transport protocol, which means HIP packets will be encapsulated as the payload of the UDP or TCP. This method is suggested in the section 4 of draft-ietf-hip-nat-traversal-02. In this case, how is the HIP checksum computed? Because pseudo header is included in the TCP or UDP checksum, is it necessary for HIP to cover it in the HIP checksum also? If it is, it will be computed twice. Regards! -- > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, August 31, 2007 8:29 PM > To: Philip Matthews > Cc: HIP WG > Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 > > Well, my perhaps faulty understanding is that for both IPv4 and IPv6, > the currently existing UDP checksum implementations include > everything from the pseudo header to the end of the payload. If so, > the logical implication is that if there are further headers beyond > HIP (such as UDP and/or SIP, for example), they will be included in > the checksum. > > The intention in HIP has been to be compatible with UDP, thereby > allowing existing hardware accelerators for updating UDP checksums in > NATs to be trivially reused. However, I am not aware of any vendor > having done an analysis if that is really feasible with the current > design. > > The interpretation of this Section has been a problem in the past in > the interops. Therefore, and based on your comments, I think it > would be very good to clarify it. However, I haven't implemented it > myself. The implementers should speak up. Perhaps someone who has > done this could write a clarifying paragraph or two. > > --Pekka > > On 31 Aug 2007, at 14:13, Philip Matthews wrote: > > > > > Given your comment, I am also guessing that the pseudo-header is > > logically prepended to the HIP header and the checksum is computed > > starting at the first byte of the pseudo-header and going through > > the last byte of the HIP header (including any TLVs). Is there > > anything else included? For IPv4, I am guessing that the actual > > formula is the one described in the UDP specification: > > Checksum is the 16-bit one's complement of the one's complement > > sum of a > > pseudo header of information from the IP header, the UDP header, > > and the > > data, padded with zero octets at the end (if necessary) to > > make a > > multiple of two octets. > > For HIP, I am guessing that there is no need to pad with zero > > octets. Does the following paragraph from the UDP specification > > also apply to HIP? > > If the computed checksum is zero, it is transmitted as all > > ones (the > > equivalent in one's complement arithmetic). An all zero > > transmitted > > checksum value means that the transmitter generated no > > checksum (for > > debugging or for higher level protocols that don't care). > > > > What about IPv6? RFC 2460 does not actually describe a checksum > > formula. Is the same formula used? And since, in IPv6, HIP is > > logically an extension header what exactly is covered by the checksum? > > > > The base spec also describes the possibility that HIP packets might > > in the future be used to carry upper-level data (i.e., the > > NextHeader field might be something other that NoNextHeader). In > > this case, does the checksum cover that upper-level data, or only > > the HIP header? Or is this something that is left "for future > > specification"? > > > > - Philip > > > > On 31-Aug-07, at 02:42 , Pekka Nikander wrote: > > > >> What seems to be missing is explicit notion that for HIP packets > >> carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum > >> algorithm will be used, and for HIP packets carried over IPv4, the > >> RFC 768 UDP checksum algorithm will be used. > >> > >> Would adding that clarify the situation enough, or are you missing > >> something else? Both RFC 2460 and RFC 768 are pretty specific how > >> to do that, and there exists a number of implementations for both. > >> > >> --Pekka > >> > >> On 30 Aug 2007, at 18:08, Philip Matthews wrote: > >> > >>> Section 5.1.1 of this document seems to be the normative > >>> description of the checksum field in the HIP packet. However, to > >>> me this section seems a bit sketchy on how the value of this > >>> field is actually computed. Am I missing something, or is there > >>> some implied knowledge of how the checksum is computed that is > >>> not stated? > >>> > >>> - Philip > >>> > >>> 5.1.1. Checksum > >>> > >>> Since the checksum covers the source and destination addresses > >>> in the > >>> IP header, it must be recomputed on HIP-aware NAT devices. > >>> > >>> If IPv6 is used to carry the HIP packet, the pseudo-header > >>> [RFC2460] > >>> contains the source and destination IPv6 addresses, HIP packet > >>> length > >>> in the pseudo-header length field, a zero field, and the HIP > >>> protocol > >>> number (see Section 4) in the Next Header field. The length > >>> field is > >>> in bytes and can be calculated from the HIP header length > >>> field: (HIP > >>> Header Length + 1) * 8. > >>> > >>> In case of using IPv4, the IPv4 UDP pseudo header format > >>> [RFC0768] is > >>> used. In the pseudo header, the source and destination > >>> addresses are > >>> those used in the IP header, the zero field is obviously zero, > >>> the > >>> protocol is the HIP protocol number (see Section 4), and the > >>> length > >>> is calculated as in the IPv6 case. > >>> > >>> _______________________________________________ > >>> Hipsec mailing list > >>> Hipsec@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/hipsec > >>> > >> > >> > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 05 05:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISrcB-0002mi-51; Wed, 05 Sep 2007 05:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISrc7-0002ki-DJ for hipsec@ietf.org; Wed, 05 Sep 2007 05:55:59 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISrc5-0006HU-Oz for hipsec@ietf.org; Wed, 05 Sep 2007 05:55:59 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1476A2DCD; Wed, 5 Sep 2007 12:55:57 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id CEE002DD0; Wed, 5 Sep 2007 12:55:44 +0300 (EEST) Date: Wed, 5 Sep 2007 12:55:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: JiangXingFeng Subject: RE: [Hipsec] Comment on draft-ietf-hip-base-08 In-Reply-To: <003901c7ef85$cc1a6840$6905a40a@china.huawei.com> Message-ID: References: <003901c7ef85$cc1a6840$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 'HIP WG' , 'Philip Matthews' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 5 Sep 2007, JiangXingFeng wrote: Hi, http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt 4.1. HIP Control Packets The HIP header and parameter follow the conventions [I-D.ietf-hip-base] with the exception that the HIP header checksum MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header contains already a checksum. Second, the checksum definition in [I-D.ietf-hip-base] includes the IP addresses in the checksum calculation. The NATs unaware of HIP cannot recompute the HIP checksum after changing IP addresses. > Hi, Pekka: > > There is another question about the computation of the HIP checksum. In > order to traverse some middle-boxes, such as NATs, HIP packet will delivered > over transport protocol, which means HIP packets will be encapsulated as the > payload of the UDP or TCP. This method is suggested in the section 4 of > draft-ietf-hip-nat-traversal-02. In this case, how is the HIP checksum > computed? Because pseudo header is included in the TCP or UDP checksum, is > it necessary for HIP to cover it in the HIP checksum also? If it is, it will > be computed twice. > > Regards! > -- > >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Friday, August 31, 2007 8:29 PM >> To: Philip Matthews >> Cc: HIP WG >> Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 >> >> Well, my perhaps faulty understanding is that for both IPv4 and IPv6, >> the currently existing UDP checksum implementations include >> everything from the pseudo header to the end of the payload. If so, >> the logical implication is that if there are further headers beyond >> HIP (such as UDP and/or SIP, for example), they will be included in >> the checksum. >> >> The intention in HIP has been to be compatible with UDP, thereby >> allowing existing hardware accelerators for updating UDP checksums in >> NATs to be trivially reused. However, I am not aware of any vendor >> having done an analysis if that is really feasible with the current >> design. >> >> The interpretation of this Section has been a problem in the past in >> the interops. Therefore, and based on your comments, I think it >> would be very good to clarify it. However, I haven't implemented it >> myself. The implementers should speak up. Perhaps someone who has >> done this could write a clarifying paragraph or two. >> >> --Pekka >> >> On 31 Aug 2007, at 14:13, Philip Matthews wrote: >> >>> >>> Given your comment, I am also guessing that the pseudo-header is >>> logically prepended to the HIP header and the checksum is computed >>> starting at the first byte of the pseudo-header and going through >>> the last byte of the HIP header (including any TLVs). Is there >>> anything else included? For IPv4, I am guessing that the actual >>> formula is the one described in the UDP specification: >>> Checksum is the 16-bit one's complement of the one's complement >>> sum of a >>> pseudo header of information from the IP header, the UDP header, >>> and the >>> data, padded with zero octets at the end (if necessary) to >>> make a >>> multiple of two octets. >>> For HIP, I am guessing that there is no need to pad with zero >>> octets. Does the following paragraph from the UDP specification >>> also apply to HIP? >>> If the computed checksum is zero, it is transmitted as all >>> ones (the >>> equivalent in one's complement arithmetic). An all zero >>> transmitted >>> checksum value means that the transmitter generated no >>> checksum (for >>> debugging or for higher level protocols that don't care). >>> >>> What about IPv6? RFC 2460 does not actually describe a checksum >>> formula. Is the same formula used? And since, in IPv6, HIP is >>> logically an extension header what exactly is covered by the checksum? >>> >>> The base spec also describes the possibility that HIP packets might >>> in the future be used to carry upper-level data (i.e., the >>> NextHeader field might be something other that NoNextHeader). In >>> this case, does the checksum cover that upper-level data, or only >>> the HIP header? Or is this something that is left "for future >>> specification"? >>> >>> - Philip >>> >>> On 31-Aug-07, at 02:42 , Pekka Nikander wrote: >>> >>>> What seems to be missing is explicit notion that for HIP packets >>>> carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum >>>> algorithm will be used, and for HIP packets carried over IPv4, the >>>> RFC 768 UDP checksum algorithm will be used. >>>> >>>> Would adding that clarify the situation enough, or are you missing >>>> something else? Both RFC 2460 and RFC 768 are pretty specific how >>>> to do that, and there exists a number of implementations for both. >>>> >>>> --Pekka >>>> >>>> On 30 Aug 2007, at 18:08, Philip Matthews wrote: >>>> >>>>> Section 5.1.1 of this document seems to be the normative >>>>> description of the checksum field in the HIP packet. However, to >>>>> me this section seems a bit sketchy on how the value of this >>>>> field is actually computed. Am I missing something, or is there >>>>> some implied knowledge of how the checksum is computed that is >>>>> not stated? >>>>> >>>>> - Philip >>>>> >>>>> 5.1.1. Checksum >>>>> >>>>> Since the checksum covers the source and destination addresses >>>>> in the >>>>> IP header, it must be recomputed on HIP-aware NAT devices. >>>>> >>>>> If IPv6 is used to carry the HIP packet, the pseudo-header >>>>> [RFC2460] >>>>> contains the source and destination IPv6 addresses, HIP packet >>>>> length >>>>> in the pseudo-header length field, a zero field, and the HIP >>>>> protocol >>>>> number (see Section 4) in the Next Header field. The length >>>>> field is >>>>> in bytes and can be calculated from the HIP header length >>>>> field: (HIP >>>>> Header Length + 1) * 8. >>>>> >>>>> In case of using IPv4, the IPv4 UDP pseudo header format >>>>> [RFC0768] is >>>>> used. In the pseudo header, the source and destination >>>>> addresses are >>>>> those used in the IP header, the zero field is obviously zero, >>>>> the >>>>> protocol is the HIP protocol number (see Section 4), and the >>>>> length >>>>> is calculated as in the IPv6 case. >>>>> >>>>> _______________________________________________ >>>>> Hipsec mailing list >>>>> Hipsec@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/hipsec >>>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 05 09:33:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISv0t-0007T2-7V; Wed, 05 Sep 2007 09:33:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISv0s-0007Sv-3v for hipsec@ietf.org; Wed, 05 Sep 2007 09:33:46 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISv0p-0005ra-OS for hipsec@ietf.org; Wed, 05 Sep 2007 09:33:45 -0400 Received: by nf-out-0910.google.com with SMTP id d3so1937689nfc for ; Wed, 05 Sep 2007 06:33:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=H8R7eMeiv1WVxw8Q5UExz3AZOotKXNLE/NNwvUwfHcM5tmzmeLNcUKHd/zxzWDYZkARArhDuIAfi6D0arqyXiRqNTDIai/KqQ0tdsplQpienBA9HPaAEfZbAVZ3/NA255dQ6BtZzZ/uTU4dse2vbDU7lT1uZQVEXDHN4WH9O4O8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=mx8SxMxBZS2VmC0ztoBvaujajwwiiWyMnF6q6UNxNBR7Rah5oEzkcHaA2Pt/712DLtIuatE+B6tjhzxBlPQtSbWc+rwCQ43t7bankpX1J3xemjM1CD4slEpTtzU/Q3EBCYN2snshTGkwyakZqRxyZaf/A8syIN7RStkPk4qdlhk= Received: by 10.78.81.20 with SMTP id e20mr5200317hub.1188999221761; Wed, 05 Sep 2007 06:33:41 -0700 (PDT) Received: from ?192.168.1.28? ( [212.119.9.178]) by mx.google.com with ESMTPS id e1sm1315045ugf.2007.09.05.06.33.38 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2007 06:33:39 -0700 (PDT) From: Julien Laganier To: draft-ietf-hip-native-api@tools.ietf.org, 'HIP WG' Date: Wed, 5 Sep 2007 15:33:34 +0200 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709051533.34704.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Cc: Subject: [Hipsec] Review of draft-ietf-hip-native-api-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I have reviewed draft-ietf-hip-native-api-02.txt, and I think the documents is in good shape. I have however a couple of comments and suggested changes below that I would like to see addressed before the document is sent to IESG for publication. I had no time to distinguish between editorial and technical ones, sorry. --julien > Native Application Programming Interfaces for SHIM APIs > draft-ietf-hip-native-api-02 The title seems redundant. Shouldn't it be something like: Native Application Programming Interfaces (API) for SHIM Layer Protocols. > Abstract > > This document defines extensions to the current networking APIs s/networking APIs/socket API/ > for protocols based on identifier/locator split. Currently, the s/based on/realizing an/ s/split/split (so called SHIM layers). > document focuses on HIP, but the extensions can be used also by other > protocols implementing identifier locator split. Using the API s/implementing identifier locator/realizing an identifier\/locator/ s/API/socket API/ > extensions, new SHIM aware applications can configure manually SHIM aware should be explained. Maybe reword in: ...extensions, applications aware of the identifier/locator split (SHIM-aware applications) can manually configure... > mappings between upper layer identifiers and the corresponding > locators. Also, the API describes how to handle outbound s/Also, the API/The API also/ > connection establishment where an application is unaware of the peer > identifier but knows the peer locator. Suggest adding '(Opportunistic Mode)' before the period ending the sentence. > 1. Terminology > > +---------+---------------------------------------------------------+ > | Term | Explanation | > +---------+---------------------------------------------------------+ > | ULID | Upper Layer IDentifier equals to the identity part of | > | | the identity/locator split. It is the identifier used | > | | by the application to name a peer for the transport | > | | layer. | > | Locator | Non-routable IPv4 or IPv6 address used at the lower | > | | layers | > | FQDN | Fully Qualified Domain Name | > | HIT | Host Identity Tag, a 100-bit hash of a public key with | > | | a 28 bit prefix | > | LSI | Locally Scope Identifier, a 32-bit local presentation | > | | of a public key | > +---------+---------------------------------------------------------+ s/Locally Scope Identifier/Local Scope Identifier/ > 2. Introduction > > Host Identity Protocol proposes a new cryptographic namespace and a s/Host Identity Protocol/The Host Identity Protocol (HIP)/ > new layer to the TCP/IP architecture. Applications can see these > new changes in the networking stacks with varying degrees of > visibility. [I-D.henderson-hip-applications] discusses the lowest > levels of visibility in which applications are either unaware of HIP. > The HIP- unaware applications use LSIs or HITs instead of IPv4 or IPv6 s/The HIP-unaware/HIP unaware/ > addresses. Such applications may be unaware of the locator bindings. s/the locator/identifier-locator/ > This document discusses about visibility of HIP to HIP-aware s/discusses about/discusses/ > applications. The applications are completely HIP aware and can s/The applications/Such applications/ > control the HIP layer and Host Identifiers. This document defines > C-based sockets API extensions for handling the bindings > explicitly. s/the bindings/identifier-locator bindings/ > The extensions expose the identity-locator split to > SHIM-aware applications and it is up to the application, or a higher SHIM and SHIM-aware are not defined in the introduction. At minimum I would expect the abstract text explaining the HIP focus but larger applicability to other SHIM layers to be duplicated here. > level programming language, to manage the identities and locators. s/the identities and locators/identifier-locator bindings/ > The API extensions introduce a new socket address structure. The > structure requires a new address family, PF_SHIM, for sockets that > use HITs and locators explicitly. Suggest rewording into: The API extensions introduce a new address family, PF_SHIM, and a new socket address structure for sockets using explicits identifier-locator bindings. Also, if we talk about address family, shouldn't we use AF_SHIM instead of PF_SHIM? > An application can also use the family to detect SHIM support in the > local host. Explain how, e.g. "the socket() call will fail (return -1) and set errno to EAFNOSUPPORT if the implementation does not support the specified address family." > Hosts may accept incoming or initiate outgoing communications > without the knowledge of the identity of the peer. s/the identity of the peer/their peer identity/ Also, is "initiate outgoing communications without knowledge of the peer identity" opportunistic mode? If yes it should be spelled out. I don't see how it is possible to accept a HIP incoming communication without knowledge of the peer identity since identity will be in I2... Maybe you refer to initiate outgoing communications without knowing the local identity? > This document describes also how to address this situation using late > binding based on new wildcards. 'late binding' is not defined. We can't expect anyone to understand what it means. > There are two related IETF documents that are define other related > API extensions. Multihoming related APIs are defined in > [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy > attributes and channel bindings are defined in [I-D.ietf-btns-c-api] I disagree with the use of 'other related API extensions' in this context. While this document does indeed defines extensions to the socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api]. > 3. Design Model > > > In this section, the native SHIM API design is described from an s/from an/from a/ > design point of view. We describe the layering and namespace > model. We conclude the discussion with a description of the resolver s/model/models/ > model. > > > 3.1. Layering Model > > > The application layer accesses the transport layer via the socket > interface. The application layer uses the traditional TCP/IP IPv4 > or IPv6 interface, or the new native SHIM API interface provided by > the socket layer. The layering model is illustrated in Figure 1. > For simplicity, the IPsec layer has been excluded from the figure. > > +--------------------------------+ > Application Layer | Application | > +----------+----------+----------+ > Socket Layer | IPv4 API | IPv6 API | SHIM API | > +----------+----+-----+----------+ > Transport Layer | TCP | UDP | > +---------------+----------------+ > SHIM Layer | HIP and other SHIMs | > +---------------+----------------+ > Network Layer | IPv4 | IPv6 | > +---------------+----------------+ > Link Layer | Ethernet | Etc | > +---------------+----------------+ > > Figure 1 > > The SHIM layer is as a shim/wedge layer between the transport and > network layers. The datagrams delivered between the transport and > network layers are intercepted in the SHIM layer to see if the > datagrams are SHIM related and require SHIM intervention. > > > 3.2. Namespace Model > > > The namespace model is shown in Table 2 from SHIM point of view. > The namespace identifiers are described in this section. > > +-------------------+-------------------------+ > | Layer | Identifier | > +-------------------+-------------------------+ > | User Interface | FQDN | > | Application Layer | ULID, port and protocol | > | Transport Layer | ULID, port | > | SHIM Layer | ULID | > | Network Layer | Locator | > +-------------------+-------------------------+ > > Table 2 > > User interfaces input human-readable names and translate them to > machine-readable names. human readable names are not limited to FQDNs, unqualified DNS names can be used too (e.g. thanks to the 'search example.com' line in a /etc/resolv.conf). I'm also not sure about restricting user interfaces to human-readable names (e.g. FQDN), it also happens that IP addresses are entered in user interface, alone or embedded in a URL. > In SHIM API, the ULID is a HIT when the > underlying protocol is HIP. The ULID is present at the > application layer and also transport layer checksum is calculated s/and also/, and/ > based on it. The SHIM layer handles also ULIDs and translates them > locators for the network layer. > > > 3.3. Interaction with the Resolver > > > Before an application can establish network communications, it > must translate a hostname to the corresponding identifier(s). DNS Again, this is IMHO too restrictive. I suggest rewording into: Before an application can establish network communications with the entity named by a given FQDN, it must translate that name into the corresponding identifier(s). DNS... > based hostname-to-identifier translation is illustrated in Figure 2. > The application calls the resolver (step a.) to resolve an FQDN (step > b.). The DNS server responds with ULIDs and a set of locators (step > c.). The resolver may not directly pass the ULIDs and the locators > to the application, but may first inform to the SHIM module (steps d. > and e.). Finally, the resolver passes the ULIDs and locators to the > application (step f.). > > +----------+ > | DNS | > +----------+ > ^ | > b. | | c. > | v > +-------------+ a. +----------+ > | |----------->| | > | > | Application | | Resolver | > | > | |<-----------| | > +-------------+ f. +----------+ > ^ | > e. | | d. > | v > +----------+ > | SHIM | > +----------+ > > Figure 2 > > In practise, the resolver functionality can implemented in s/practise/practice/ > different ways. It may be implemented in existing resolver libraries > or as an DNS proxy. s/an DNS/a DNS/ > 4. API Syntax and Semantics > > > In this section, we describe the native SHIM API using the syntax > of the C programming language and present only the ``external'' > interfaces and data structures that are visible to the applications. I don't think the last part of the sentence is necessary ("present only the ``external''interfaces and data structures that are visible to the applications.") since this is the definition of an API. Suggest deleting it. > We limit the description to those interfaces and data structures that > are either modified or completely new, because the SHIM API is > otherwise identical to the sockets API [POSIX]. In all API definitions that follows, it should be specified which header file should be included to result in the definitions (e.g. PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , or . It would also be good to have a section that recapitulate all new definitions at the end of the document. > 4.1. Socket Family and Address Structure In this section, w.r.t. to usage of SHIM_ANY* macros, I think using _source_ vs. _destination_ (or local vs. peer) to characterize the use of sockaddr_shim structures would be more to the point than referring to client vs. server applications -- sometimes, client applications bind(), and server connect()/sendto(). > We introduce a new protocol family, PF_SHIM, for the sockets API. Suggest completing the sentence into: We introduce a new protocol family, PF_SHIM, and a new address family, AF_SHIM, for the sockets API. > The AF_SHIM constant is an alias for PF_SHIM. The use of the > PF_SHIM constant is mandatory with the socket() function if the SHIM > API is to be used in the application. The PF_SHIM constant is given > as the first argument (domain) to the socket() function. > > The ULIDs and locators are contained in the sockaddr_shim > structure, which is shown in Figure 3. The family of the socket, > shim_family, is set to PF_SHIM. The port number sins_port is two > octets and the sins_ulid is four octets. The ULID value is an IPv6 > address. The locator is an IPv6 address or IPv6-mapped address IPv4 s/IPv6-mapped address/IPv6-mapped/ > address as defined in - [RFC3493]. The family is stored in host byte > order and the ULID and locator are stored in network byte order. Since family is the size of a byte, I think specifying that "the family is stored in host byte order" is a no-op. > typedef struct in6_addr shim_ulid_t; > typedef struct in6_addr shim_locator_t; > > struct sockaddr_shim { > uint8_t sins_len; > uint8_t sins_family; > uint16_t sins_port; > shim_ulid_t sins_ulid; > shim_locator_t sins_locator; > uint64_t sins_flags; > } FWIW, some "logic" might lead to wonder about the choice of the sins_ prefix for fields of the sockaddr_shim structure: sockaddr_in -> sin_len, sin_family, etc. sockaddr_in6 -> sin6_len, sin6_family, etc. Therefore: sockaddr_shim -> sshim_len, sshim_family, etc. > The application usually sets the sins_ulid field using the > resolver. However, three special macros can be used to directly set a > value into the sins_ulid field. The macros are SHIM_ANY, > SHIM_ANY_PUB and SHIM_ANY_ANON. They denote an ULID value associated > with a wildcard ULID of any, public, or anonymous type. I miss the definition of these different ULID types (public vs. anonymous). I think we need some more text or a reference to another document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 ULID's). > In server applications, the SHIM_* macros accept incoming s/SHIM_* macros accept/SHIM_ANY* macros allows accepting/ > connections to all of the ULID of the local host. The macros > correspond to the sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT, > but they are applicable at the SHIM layer. It should be noticed that > only one process at a time in a host can bind with the SHIM_*ANY s/bind with the SHIM_*ANY/bind to the SHIM_ANY*/ > macro to the same port to avoid ambiguous bindings. I'm not sure about the restriction to one host binding on a given port. There are TCP/IP stacks that allows binding multiple processes to bind to same addresses and/or ports through the use of the appropriate socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite them here, or remove the above restriction. I am also not sure about restricting the above text to 'server application' -- client application might also bind sockets (e.g. FTP, although that's not the right exemple). > A client application can use the SHIM_ANY macro to establish a s/macro to establish a/macro with connect() or sendto() calls/ > connection when only the server locator (and not the ULID) is s/connection/communication/ > known beforehand. > In both client and server based applications, the use of the > SHIM_ANY* macro accepts also non-SHIM based communications to > maximize backwards compatibility. The text should specify that goes into the sins_ulid field (e.g. zeroes) when that is the case. > When the application wants > enforces the use of SHIM-based communications with ORCHID prefix > [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. > Alternatively, the application accepts both ORCHID and non-ORCHID- > based communications, but informs the difference e.g. to the user. > In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro How about SHIM_IS_IPV6_ADDR_ORCHID instead? > which inputs a pointer to a in6_addr and returns 1 when the > address has orchid prefix and 0 otherwise. > > Applications can also implement access control using the ULIDs. > In such a case, the application can compare two ULIDs using memcmp() > or similar function. > > 4.2. Resolver > > > The SHIM API uses the getaddrinfo resolver function which the > application uses to query both ULIDs and locators. I suggest to rewrite into: The SHIM API introduces a new addrinfo flag, AI_SHIM, to be used by application to query for both ULID and locator information via the getaddrinfo() resolver function [RFC3493]. > The resolver introduces a new data structure which is used both as > the input and output argument for the resolver. The data structure > is illustrated in Figure 4. s/The resolver introduces a new which is used both as the input an output argument for the resolver/The getaddrinfo() function uses a data structure used for both input to and output from the resolver/ > > struct addrinfo { > int ai_flags; /* e.g. AI_SHIM */ > int ai_family; /* e.g. PF_SHIM */ > int ai_socktype; /* e.g. SOCK_STREAM */ > int ai_protocol; /* 0 or IPPROTO_HIP */ > size_t ai_addrlen; /* length of the endpoint */ > struct sockaddr *ai_addr; /* socket address */ > char *ai_canonname; /* canon. name of the host */ > struct addrinfo *ai_next; /* next endpoint */ > }; > > Figure 4 > > In addrinfo structures, the family field is set to PF_SHIM when > the socket address structure contains an ULID that refers to ULID, s/to ULID/to a ULID/ > such as HIT. s/HIT/a HIT/ > The flag AI_SHIM must be set, or otherwise the resolver does not > return sockaddr_shim data structures to guarantee that legacy > applications do not break. But presumably legacy applications would not set ai_family to PF_SHIM, so the AI_SHIM flags seems redundant. > Some applications may prefer > configuring the locators manually and can set the AI_SHIM_NOLOCATORS > flag to prohibit the getaddrinfo from resolving any locators. > > The ai_family field is PF_SHIM with SHIM-specific addrinfo data > structures. What is the "SHIM-specific addrinfo data structures" ? do you mean an addrinfo data structure with an ai_addr pointing to a sockaddr_shim data structure? > The protocol field is 0 when the getaddrinfo caller does not care > about the specific SHIM protocol to be used. The caller (or the > resolver) can set this field also to IPPROTO_HIP. s/protocol field/ai_protocol field/ Since this API is supposed to be usable for multiple SHIM protocols (e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in use I'd think that the caller MUST set the protocol field to the constant identifying the protocol in use (e.g. IPPROTO_HIP, IPPROTO_SHIM6). > ai_addrlen is the size of the structure pointed by ai_addr. This is already specified as part of RFC3493. No need to duplicate that information here. > The ai_addr points to a sockaddr_shim structure when the value of > ai_family is PF_SHIM. The resolver sets SHIM_RVS in sins_flags of > the when the locator belongs to a rendezvous server > [I-D.ietf-hip-dns]. > > The SHIM API does not introduce changes to the interface syntax of > the existing sockets API functions, such as bind(), connect(), > send(), sendto(), sendmsg(), recv(), recvfrom(), and recvmsg(). Same is true for for getaddrinfo(), BTW. > However, the SHIM-aware application usually passes the functions a > sockaddr_shim structure instead of a sockaddr_in or sockaddr_in6 > structure. A SHIM-aware application either creates the > sockaddr_shim structures manually or obtains them from the resolver. > The getaddrinfo resolver [RFC3493] is shown in Figure 5. > int getaddrinfo(const char *nodename, > const char *servname, > const struct addrinfo *hints, > struct addrinfo **res) > void free_addrinfo(struct addrinfo *res) > > Figure 5 > > As described in [RFC3493], the getaddrinfo function takes the > nodename, servname, and hints as its input arguments. It places > the result of the query into the res argument. The return value is > zero on success, or a non-zero error value on error. The nodename > argument specifies the host name to be resolved; a NULL argument > denotes the local host. The servname parameter declares the port > number to be set in the socket addresses in the res output argument. > Both the nodename and servname cannot be NULL. > > The input argument hints acts like a filter that defines the > attributes required from the resolved endpoints. For example, the > resolver returns only anonymous endpoints in the output argument > res when the application sets the ai_addr pointer of hints to point > to a sockaddr_shim structure with sins_ulid filled with > SHIM_ANY_ANON. A NULL hints argument indicates that any kind of > endpoints are acceptable. > > The output argument res is dynamically allocated by the resolver. > The application must free res argument with the free_addrinfo > function. We do not need to specify that here, that's orthogonal to the discussion we're having IMO. > The res argument contains a linked list of the resolved > endpoints. The linked list contains sockaddr_shim structures only > when the input argument has the AI_SHIM flag set. When the > resolver finds SHIM identifiers, it inserts them to the front of the > list. This seems to imply that the resolver may also return non-SHIM sockaddr structures (e.g. sockaddr_in6) at the tail of the list. That should be made explicit. > Resolving of a hostname may result in multiple locators associated > to a single ULID, but the sockaddr_shim structure contains only a > single ULID-locator pair. The resolver handles this by repeating the > ULD as many time as needed. For example, let us consider a case > where the resolver finds an ULID that is associated to two locators. > In such a case, the resolver outputs two sockaddr_shim structures > with the same ULID but different locators. > > 5. IANA Considerations > > > No IANA considerations. > > > > 6. Security Considerations > > To be done. Ditto. :-) Hope the review helps. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 05 16:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1Y6-0001Jm-QT; Wed, 05 Sep 2007 16:32:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1Y4-0001Jh-SC for hipsec@ietf.org; Wed, 05 Sep 2007 16:32:28 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT1Y4-0001zS-Ex for hipsec@ietf.org; Wed, 05 Sep 2007 16:32:28 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IT1Y3-0007Yw-1Z for hipsec@ietf.org; Wed, 05 Sep 2007 16:32:27 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: HIP WG From: Philip Matthews Date: Wed, 5 Sep 2007 16:32:40 -0400 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Hipsec] Anonymous HIs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org draft-ietf-hip-base-08 contains the following text: 5.1.2. HIP Controls The HIP Controls section conveys information about the structure of the packet and capabilities of the host. The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A - Anonymous: If this is set, the sender's HI in this packet is anonymous, i.e., one not listed in a directory. Anonymous HIs SHOULD NOT be stored. This control is set in packets R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it. What directory is meant? DNS? Or something else? Is there some way to check if a HIT really is anonymous? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 05 23:08:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT7jY-0002HL-TO; Wed, 05 Sep 2007 23:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT7jX-0002H8-63 for hipsec@ietf.org; Wed, 05 Sep 2007 23:08:43 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT7jV-0000Ph-LK for hipsec@ietf.org; Wed, 05 Sep 2007 23:08:43 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0C92B212C63; Thu, 6 Sep 2007 06:08:40 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B649E212C59; Thu, 6 Sep 2007 06:08:39 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Anonymous HIs Date: Thu, 6 Sep 2007 06:08:26 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > draft-ietf-hip-base-08 contains the following text: > > 5.1.2. HIP Controls > > The HIP Controls section conveys information about the > structure of > the packet and capabilities of the host. > > The following fields have been defined: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | | | | | | | | | | |A| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A - Anonymous: If this is set, the sender's HI in this > packet is > anonymous, i.e., one not listed in a directory. Anonymous > HIs > SHOULD NOT be stored. This control is set in packets R1 > and/or > I2. The peer receiving an anonymous HI may choose to > refuse it. > > What directory is meant? DNS? Or something else? > Is there some way to check if a HIT really is anonymous? You may consider this as an anachronism, as anonymous HIs haven't really been fully developed. See RFC 4423 Sections 5 and 11 for the background. But, personally, I'm happy that the hook for that is still there. :-) The directories referred to is basically any directory. Anonymous HIs are meant to be used "once" and thrown away. No, there is no way to check if a HIT really is anonymous or not. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 06 13:04:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKme-0004Tk-5j; Thu, 06 Sep 2007 13:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKmc-0004Qa-GI for hipsec@ietf.org; Thu, 06 Sep 2007 13:04:46 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITKma-0004y9-Av for hipsec@ietf.org; Thu, 06 Sep 2007 13:04:46 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ITKmZ-00044A-2c; Thu, 06 Sep 2007 13:04:43 -0400 In-Reply-To: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Anonymous HIs Date: Thu, 6 Sep 2007 13:04:57 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip-hip- hop) is proposing to create peer-to-peer overlays using HIP. In HIP- HOP, the HIT is also a peer ID used to identify a peer in the overlay. Peers might be things like SIP phones or laptops without a DNS entry. In our view, they are quite likely to be located behind a NAT (at least in the short term). So are these "anonymous" HIs? What are the important properties of an "anonymous" HI that causes them to be treated differently? - Philip On 5-Sep-07, at 23:08 , Pekka Nikander wrote: >> draft-ietf-hip-base-08 contains the following text: >> >> 5.1.2. HIP Controls >> >> The HIP Controls section conveys information about the >> structure of >> the packet and capabilities of the host. >> >> The following fields have been defined: >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | | | | | | | | | | | | | | |A| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> A - Anonymous: If this is set, the sender's HI in this >> packet is >> anonymous, i.e., one not listed in a directory. >> Anonymous HIs >> SHOULD NOT be stored. This control is set in packets R1 >> and/or >> I2. The peer receiving an anonymous HI may choose to >> refuse it. >> >> What directory is meant? DNS? Or something else? >> Is there some way to check if a HIT really is anonymous? > > You may consider this as an anachronism, as anonymous HIs haven't > really been fully developed. See RFC 4423 Sections 5 and 11 for > the background. But, personally, I'm happy that the hook for that > is still there. :-) > > The directories referred to is basically any directory. Anonymous > HIs are meant to be used "once" and thrown away. > > No, there is no way to check if a HIT really is anonymous or not. > > --Pekka > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 06 14:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITLr4-0000U1-TC; Thu, 06 Sep 2007 14:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITLr3-0000Tv-Ot for hipsec@ietf.org; Thu, 06 Sep 2007 14:13:25 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITLr1-0006cu-Tt for hipsec@ietf.org; Thu, 06 Sep 2007 14:13:25 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3AE6A212C63; Thu, 6 Sep 2007 21:13:21 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D9971212C59; Thu, 6 Sep 2007 21:13:20 +0300 (EEST) In-Reply-To: References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Anonymous HIs Date: Thu, 6 Sep 2007 21:13:07 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.2 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If I've understood the HIP-HOP goals right, the peers will have long- lived HIs that will be stored in the DHT. From the present discussion point of view, that DHT could be classified as a "directory", since they allow one to look up information related to the HI. Hence, those HIs wouldn't be "anonymous". On the other hand, if when making a P2PSIP call I were to decide to make a new HI, in order to not to reveal my permanent HI to the callee, that new HI would be an anonymous HI. Presumably, I would destroy the HI after that one call. I thought the background thinking was clear enough in RFC 4423, but perhaps it isn't? --Pekka On 6 Sep 2007, at 20:04, Philip Matthews wrote: > As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip- > hip-hop) is proposing to create peer-to-peer overlays using HIP. In > HIP-HOP, the HIT is also a peer ID used to identify a peer in the > overlay. Peers might be things like SIP phones or laptops without a > DNS entry. In our view, they are quite likely to be located behind > a NAT (at least in the short term). So are these "anonymous" HIs? > What are the important properties of an "anonymous" HI that causes > them to be treated differently? > > - Philip > > On 5-Sep-07, at 23:08 , Pekka Nikander wrote: > >>> draft-ietf-hip-base-08 contains the following text: >>> >>> 5.1.2. HIP Controls >>> >>> The HIP Controls section conveys information about the >>> structure of >>> the packet and capabilities of the host. >>> >>> The following fields have been defined: >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | | | | | | | | | | | | | | |A| >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> A - Anonymous: If this is set, the sender's HI in this >>> packet is >>> anonymous, i.e., one not listed in a directory. >>> Anonymous HIs >>> SHOULD NOT be stored. This control is set in packets R1 >>> and/or >>> I2. The peer receiving an anonymous HI may choose to >>> refuse it. >>> >>> What directory is meant? DNS? Or something else? >>> Is there some way to check if a HIT really is anonymous? >> >> You may consider this as an anachronism, as anonymous HIs haven't >> really been fully developed. See RFC 4423 Sections 5 and 11 for >> the background. But, personally, I'm happy that the hook for that >> is still there. :-) >> >> The directories referred to is basically any directory. Anonymous >> HIs are meant to be used "once" and thrown away. >> >> No, there is no way to check if a HIT really is anonymous or not. >> >> --Pekka >> >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 07 02:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITXjg-0001Id-B9; Fri, 07 Sep 2007 02:54:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITXjf-0001IY-D3 for hipsec@ietf.org; Fri, 07 Sep 2007 02:54:35 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITXjd-0004YF-LC for hipsec@ietf.org; Fri, 07 Sep 2007 02:54:34 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69B80212C63; Fri, 7 Sep 2007 09:54:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 17BCC212C59; Fri, 7 Sep 2007 09:54:31 +0300 (EEST) Message-ID: <46E0F5A6.1030006@nomadiclab.com> Date: Fri, 07 Sep 2007 09:54:30 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: HIPsec Mailing List Content-Type: multipart/mixed; boundary="------------010308010507030500010804" X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Pekka Nikander , simon.schuetz@netlab.nec.de, Gonzalo Camarillo Subject: [Hipsec] ICE/HIP Integration: A Solution Space Analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------010308010507030500010804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, [draft-ietf-hip-nat-traversal-02] builds ICE functionality into HIP. An integration like this requires, of course, design decisions WRT which ICE-related meaning/action HIP messages should bear/trigger. I was missing some rationale for the specific solution in [draft-ietf-hip-nat- traversal-02]. So I made my own evaluation of the solution space for ICE/HIP integration. I am attaching this because it may be interesting for you as well. Since the result of my evaluation is supportive of [draft-ietf-hip-nat- traversal-02], I suggest to use it as a new "Rationale" section in the draft. Best regards, - Christian P.S.: The attached evaluation may be useful also for [draft-tschofenig-hip- ice-00], but I did not look into this yet. --------------010308010507030500010804 Content-Type: text/plain; name="vogt-hip-nat-traversal-hipwg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vogt-hip-nat-traversal-hipwg.txt" Solution Space Analysis for HIP-ICE Integration Christian Vogt, September 7, 2007 ----------------------------------------------- To integrate ICE functionality into a HIP base exchange, three questions must be answered for both the initiator's side and the responder's side: - When should a host discover local candidate locators? - Which HIP packets should carry candidate locators? - Which HIP packets should initiate reachability checks? Answering these questions involves a trade-off. On one hand, performing these tasks at a late stage during the HIP base exchange allows a host to defer spending the effort involved in candidate locator discovery and reachability checks until the correspondent host has proven its identity and provided reasonable assurance that its desire to communicate is genuine. Candidate locator discovery and reachability checks require both signaling as well as memory and processing on a host. Care must be taken that this cannot be exploited for resource (memory or processing) exhaustion attacks against the host, or for reflection-based flooding attacks against arbitrary victims elsewhere on the Internet. On the other hand, all HIP packets up to the ones carrying candidate locators must go through a rendezvous server to ensure successful delivery. Exchanging candidate locators early during the HIP base exchange therefore reduces the load on the rendezvous server and enables an earlier switch to more efficient communications via a direct path. We propose the following integration of ICE into the HIP base exchange and provide rationale for this below: - The responder sends its local candidate locators to the initiator with the R1 message. It discovers its local candidate locators any time before this. - The initiator begins reachability checks when it receives the R1 message from the responder. - The initiator sends its local candidate locators to the responder with the I2 message. It discovers its local candidate locators any time before this. - The responder begins reachability checks when it receives the I2 message from the initiator. The discovery of local candidate locators is thus effectively decoupled from any particular session establishment. This is necessary because a host discovers local candidates once, and it can use them with multiple correspondent hosts later on. Moreover, the threats involved in candidate locator discovery are very limited anyway. Since the procedure is a one-time task, misusing it for resource exhaustion is hard. The procedure also involves signaling only between a host and its STUN, TURN, or rendezvous servers. This signaling cannot be redirected by an attacker for a flooding attack. Reachability checks are more vulnerable to resource exhaustion and flooding attacks for the following two reasons: (1) Reachability checks are tied to a particular correspondent host, and must hence be redone for each correspondent host. This would give an attacker the ability to trigger reachability checks if it could spoof identities. (2) An attacker can amplify both resource exhaustion and flooding attacks via the number of (possibly spoofed) local candidate locators that it advertises to a victim host. The host pairs each of these locators with typically multiple local candidate locators of its own, and it performs a reachability check on each such pair. In addition, reachability checks that are directed against a spoofed locator fail to solicit a reponse. This causes the host to retransmit the reachability checks, increasing amplification further. It is hence important for a host to defer its reachability checks for a correspondent host until that correspondent host has proven its identity and, in case the correspondent host is the session initiator, provided reasonable assurance that its desire to communicate is genuine. With the proposed HIP-ICE integration approach, the initiator of a HIP base exchange defers its reachability checks until it has received the R1 message because this proves the responder's identity (via a signature). The proposed approach calls for the responder to defer its reachability checks until the receipt of the I2 message because this proves the initiator's identity (via a signature) and willingness to communicate (via a puzzle solution). Alternative HIP-ICE Integration Approach ---------------------------------------- The proposed HIP-ICE initegration approach protects the initiator against the (comparatively small) threat of misuse of candidate locator discovery because it could defer candidate locator discovery until after the receipt of the responder's signature. However, the responder is currently not thus protected as it needs to discover its local candidate locators already upon receipt of the unauthenticated I1 message. To also protect the responder against misuse of candidate locator discovery, exchange of the responder's candidate locators must take place only after the receipt of the initiator's I2 message. The responder would then start candidate locator discovery after verification of the signature in the I2 message, and send its local candidate locators to the initiator with the R2 message. Rendezvous Server Considerations -------------------------------- Exchanging candidate locators in the R1 and I2 messages requires at least the I1, R1, and I2 messages of the base handshake to be relayed via a rendezvous server in order to ensure delivery. All messages from the HIP base exchange must be sent via the rendezvous server if the candidate locators get exchanged in the I2 and R2 messages. Either case requires a deviation from the procedure defined in [HIPRVS], which calls for the R1, I2, and R2 messages to be sent via the direct path. Mobility and Multi-Homing Considerations ---------------------------------------- The HIP mobility and multi-homing extensions [HIPMM] allow a responder to advertise new locators in the R1 message, and an initiator may advertise new locators in the I2 message. This is in-line with the exchange of candidate locators in these same messages. --------------010308010507030500010804 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --------------010308010507030500010804-- From hipsec-bounces@lists.ietf.org Fri Sep 07 08:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITctk-0001Gt-EC; Fri, 07 Sep 2007 08:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITctj-0001Gn-6T for hipsec@ietf.org; Fri, 07 Sep 2007 08:25:19 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITcth-0007cC-Tr for hipsec@ietf.org; Fri, 07 Sep 2007 08:25:19 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ITcth-0006yp-0e; Fri, 07 Sep 2007 08:25:17 -0400 In-Reply-To: <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27F0A786-E55A-47B4-B080-63EBBE29B6EF@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Anonymous HIs Date: Fri, 7 Sep 2007 08:25:32 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 1.2 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Right now, the thought is that peers will use the same HI as long as they are in the overlay, and each peer potentially will have some credentials that indicate that it is allowed to join the overlay. We are currently looking more closely at this to understand the security implications of it. A user Fred that is "logged" that is located at the peer with HIT X would then be registered in the DHT as "fred@X". So from what you say, X would not be considered an "anonymous" HIT? I understand your description of an anonymous HIT that is used for one call. I had looked at RFC 4423, but the discussion seemed to rely on some background info that I didn't have. My suggestion would be to insert a couple of paragraphs into draft-ietf-hip-base that more fully describes the concept. I would be happy to help with preparing this text. A couple more questions about this concept. As I understand it, this bit is just informational to the host that receives it. The only protocol action the receiving host can take is to reject the request to set up the HIP association. Is this correct? What prevents a host from lying about this setting? How does this proposal avoid the security flaws of the Evil Bit proposal (RFC 3514)? - Philip On 6-Sep-07, at 14:13 , Pekka Nikander wrote: > If I've understood the HIP-HOP goals right, the peers will have > long-lived HIs that will be stored in the DHT. From the present > discussion point of view, that DHT could be classified as a > "directory", since they allow one to look up information related to > the HI. Hence, those HIs wouldn't be "anonymous". > > On the other hand, if when making a P2PSIP call I were to decide to > make a new HI, in order to not to reveal my permanent HI to the > callee, that new HI would be an anonymous HI. Presumably, I would > destroy the HI after that one call. > > I thought the background thinking was clear enough in RFC 4423, but > perhaps it isn't? > > --Pekka > > On 6 Sep 2007, at 20:04, Philip Matthews wrote: > >> As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip- >> hip-hop) is proposing to create peer-to-peer overlays using HIP. >> In HIP-HOP, the HIT is also a peer ID used to identify a peer in >> the overlay. Peers might be things like SIP phones or laptops >> without a DNS entry. In our view, they are quite likely to be >> located behind a NAT (at least in the short term). So are these >> "anonymous" HIs? What are the important properties of an >> "anonymous" HI that causes them to be treated differently? >> >> - Philip >> >> On 5-Sep-07, at 23:08 , Pekka Nikander wrote: >> >>>> draft-ietf-hip-base-08 contains the following text: >>>> >>>> 5.1.2. HIP Controls >>>> >>>> The HIP Controls section conveys information about the >>>> structure of >>>> the packet and capabilities of the host. >>>> >>>> The following fields have been defined: >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | | | | | | | | | | | | | | |A| >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> A - Anonymous: If this is set, the sender's HI in this >>>> packet is >>>> anonymous, i.e., one not listed in a directory. >>>> Anonymous HIs >>>> SHOULD NOT be stored. This control is set in packets >>>> R1 and/or >>>> I2. The peer receiving an anonymous HI may choose to >>>> refuse it. >>>> >>>> What directory is meant? DNS? Or something else? >>>> Is there some way to check if a HIT really is anonymous? >>> >>> You may consider this as an anachronism, as anonymous HIs haven't >>> really been fully developed. See RFC 4423 Sections 5 and 11 for >>> the background. But, personally, I'm happy that the hook for >>> that is still there. :-) >>> >>> The directories referred to is basically any directory. >>> Anonymous HIs are meant to be used "once" and thrown away. >>> >>> No, there is no way to check if a HIT really is anonymous or not. >>> >>> --Pekka >>> >>> >> >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 07 08:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdHQ-0007Jy-0o; Fri, 07 Sep 2007 08:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdHO-0007Eh-0c for hipsec@ietf.org; Fri, 07 Sep 2007 08:49:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdHL-0008Bp-RQ for hipsec@ietf.org; Fri, 07 Sep 2007 08:49:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7FC38212D39; Fri, 7 Sep 2007 15:49:42 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1693A212D37; Fri, 7 Sep 2007 15:49:42 +0300 (EEST) In-Reply-To: <27F0A786-E55A-47B4-B080-63EBBE29B6EF@magma.ca> References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> <27F0A786-E55A-47B4-B080-63EBBE29B6EF@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B858FA5-7605-4FED-B0EB-004CF24724F0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Anonymous HIs Date: Fri, 7 Sep 2007 15:49:27 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.2 (+) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 7 Sep 2007, at 15:25, Philip Matthews wrote: > Right now, the thought is that peers will use the same HI as long > as they are in the overlay, and each peer potentially will have > some credentials that indicate that it is allowed to join the > overlay. We are currently looking more closely at this to > understand the security implications of it. A user Fred that is > "logged" that is located at the peer with HIT X would then be > registered in the DHT as "fred@X". So from what you say, X would > not be considered an "anonymous" HIT? Right. > I understand your description of an anonymous HIT that is used for > one call. Not necessarily. In some other context, you might even use an anonymous HI for several years, but most probably only for one specific purpose. > I had looked at RFC 4423, but the discussion seemed to rely on some > background info that I didn't have. My suggestion would be to > insert a couple of paragraphs into draft-ietf-hip-base that more > fully describes the concept. I would be happy to help with > preparing this text. Well, unfortunately the base spec is now almost past IESG and entering the RFC Editor's queue. Hence, I think we don't want such a text added but perhaps rather a separate draft clarifying the issue. Or what does the WG think? Adding such text might endanger of having to circulate the draft again through the IESG. > A couple more questions about this concept. As I understand it, > this bit is just informational to the host that receives it. Yes. > The only protocol action the receiving host can take is to reject > the request to set up the HIP association. Is this correct? Basically, yes. Other than that, the host may not want to "remember" the anonymous HI afterwards; see RFC 4423 Section 5.2. See also the fourth paragraph of Section 13, Security Considerations. > What prevents a host from lying about this setting? How does this > proposal avoid the security flaws of the Evil Bit proposal (RFC 3514)? Well, while there is no way to check if a HI is anonymous, a host may certainly check that a HI *is* registered (i.e. not anonymous), if it can infer the registry from the context. That is, while you cannot attribute an anonymous HI to anyone (at least in theory), you may have a policy that requires all non-anonymous HIs to be attributable. --Pekka > > - Philip > > On 6-Sep-07, at 14:13 , Pekka Nikander wrote: > >> If I've understood the HIP-HOP goals right, the peers will have >> long-lived HIs that will be stored in the DHT. From the present >> discussion point of view, that DHT could be classified as a >> "directory", since they allow one to look up information related >> to the HI. Hence, those HIs wouldn't be "anonymous". >> >> On the other hand, if when making a P2PSIP call I were to decide >> to make a new HI, in order to not to reveal my permanent HI to the >> callee, that new HI would be an anonymous HI. Presumably, I would >> destroy the HI after that one call. >> >> I thought the background thinking was clear enough in RFC 4423, >> but perhaps it isn't? >> >> --Pekka >> >> On 6 Sep 2007, at 20:04, Philip Matthews wrote: >> >>> As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip- >>> hip-hop) is proposing to create peer-to-peer overlays using HIP. >>> In HIP-HOP, the HIT is also a peer ID used to identify a peer in >>> the overlay. Peers might be things like SIP phones or laptops >>> without a DNS entry. In our view, they are quite likely to be >>> located behind a NAT (at least in the short term). So are these >>> "anonymous" HIs? What are the important properties of an >>> "anonymous" HI that causes them to be treated differently? >>> >>> - Philip >>> >>> On 5-Sep-07, at 23:08 , Pekka Nikander wrote: >>> >>>>> draft-ietf-hip-base-08 contains the following text: >>>>> >>>>> 5.1.2. HIP Controls >>>>> >>>>> The HIP Controls section conveys information about the >>>>> structure of >>>>> the packet and capabilities of the host. >>>>> >>>>> The following fields have been defined: >>>>> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | | | | | | | | | | | | | | |A| >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> A - Anonymous: If this is set, the sender's HI in this >>>>> packet is >>>>> anonymous, i.e., one not listed in a directory. >>>>> Anonymous HIs >>>>> SHOULD NOT be stored. This control is set in packets >>>>> R1 and/or >>>>> I2. The peer receiving an anonymous HI may choose to >>>>> refuse it. >>>>> >>>>> What directory is meant? DNS? Or something else? >>>>> Is there some way to check if a HIT really is anonymous? >>>> >>>> You may consider this as an anachronism, as anonymous HIs >>>> haven't really been fully developed. See RFC 4423 Sections 5 >>>> and 11 for the background. But, personally, I'm happy that the >>>> hook for that is still there. :-) >>>> >>>> The directories referred to is basically any directory. >>>> Anonymous HIs are meant to be used "once" and thrown away. >>>> >>>> No, there is no way to check if a HIT really is anonymous or not. >>>> >>>> --Pekka >>>> >>>> >>> >>> >> >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 07 09:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdyc-00029c-6R; Fri, 07 Sep 2007 09:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdyb-00029X-DH for hipsec@ietf.org; Fri, 07 Sep 2007 09:34:25 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdyY-0000ec-6u for hipsec@ietf.org; Fri, 07 Sep 2007 09:34:24 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ITdyX-0006dW-2i; Fri, 07 Sep 2007 09:34:21 -0400 In-Reply-To: <0B858FA5-7605-4FED-B0EB-004CF24724F0@nomadiclab.com> References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> <27F0A786-E55A-47B4-B080-63EBBE29B6EF@magma.ca> <0B858FA5-7605-4FED-B0EB-004CF24724F0@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FC8B864-0253-4D45-9492-082CE1E159D8@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Anonymous HIs Date: Fri, 7 Sep 2007 09:34:37 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 7-Sep-07, at 08:49 , Pekka Nikander wrote: > > On 7 Sep 2007, at 15:25, Philip Matthews wrote: > >> The only protocol action the receiving host can take is to reject >> the request to set up the HIP association. Is this correct? > > Basically, yes. Other than that, the host may not want to > "remember" the anonymous HI afterwards; see RFC 4423 Section 5.2. Do you really mean section 5.2 "Storing Host Identifiers in DNS"? I don't see anything in there about remembering HIs. > >> What prevents a host from lying about this setting? How does this >> proposal avoid the security flaws of the Evil Bit proposal (RFC >> 3514)? > > Well, while there is no way to check if a HI is anonymous, a host > may certainly check that a HI *is* registered (i.e. not anonymous), > if it can infer the registry from the context. That is, while you > cannot attribute an anonymous HI to anyone (at least in theory), > you may have a policy that requires all non-anonymous HIs to be > attributable. If I understand you, under this policy the host rejects anonymous HIs and all non-anonymous HIs that it cannot verify. So why is the A bit helpful? The only case I can see where an A bit would be helpful is if a host would accept both anonymous and non-anonymous HIs. For non-anonymous HIs, it verified that they are indeed in the appropriate registry, which is assumed to be an expensive operation, hence the desire to avoid this check for HIs which are anonymous. It then does something different with two types of HIs, but I am not sure what that different thing would be. However, I can see problems with this too: what about a DoS attack where hosts set the A bit incorrectly to force extra work on the receiver? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 07 11:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfo0-0001qs-Q2; Fri, 07 Sep 2007 11:31:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfo0-0001lz-2K for hipsec@ietf.org; Fri, 07 Sep 2007 11:31:36 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITfnz-00085x-HE for hipsec@ietf.org; Fri, 07 Sep 2007 11:31:35 -0400 Received: from [163.117.82.80] (wifi-82-80.uc3m.es [163.117.82.80])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 7BBD8AB931; Fri, 7 Sep 2007 17:31:34 +0200 (CEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boei ng.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [Hipsec] NAT Traversal in HIP Date: Fri, 7 Sep 2007 17:31:50 +0200 To: Miika Komu X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.6226 TC:1F TRN:27 TV:3.6.1039(15408.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org catching up.... El 31/08/2007, a las 8:14, Miika Komu escribi=F3: > * HIP mobility and multihoming: this will get messy with ICE? This may > also reduce code reusability from ICE significantly. > maybe true, but if you want to support mobility and multihoming on =20 nated environments, you need extra functionality that currently is =20 not there and then you need to add ICE like capabilities. I mean, for example, for multihoming, you need failure detection. =20 This probably involves sending some periodic probes. OTOH, in a nated =20= environment, you need to send probes to keep the state alive. I guess =20= it makes most sense to use the same probes for keeping the nat state =20 alive and for failure detection. Bottom line is that this will get =20 messy in any case, because there seems to be a lot of interactions =20 between the multihoming mechanisms and the nat traversal mechanisms. OTOH, my personal opinion at this stage, is that it will be easier to =20= extend ICE to support the additional features needed like failure =20 detection in mulithomed environments) than to extend current =20 multihoming techniques to support all the nat traversal stuff. So =20 from a practical perspective, i would start from ICE and extend it to =20= support the additional features needed. regards, marcelo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 07 11:48:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITg4W-0001RY-1l; Fri, 07 Sep 2007 11:48:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITg4V-0001RS-2j for hipsec@ietf.org; Fri, 07 Sep 2007 11:48:39 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITg4T-0008WJ-TX for hipsec@ietf.org; Fri, 07 Sep 2007 11:48:38 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ITg4S-0007ZF-2f; Fri, 07 Sep 2007 11:48:36 -0400 In-Reply-To: <46E0F5A6.1030006@nomadiclab.com> References: <46E0F5A6.1030006@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Fri, 7 Sep 2007 11:48:52 -0400 To: Christian Vogt X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Pekka Nikander , HIPsec Mailing List , simon.schuetz@netlab.nec.de, Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org See inline. On 7-Sep-07, at 02:54 , Christian Vogt wrote: > Solution Space Analysis for HIP-ICE Integration > Christian Vogt, September 7, 2007 > ----------------------------------------------- > > To integrate ICE functionality into a HIP base exchange, three > questions must be answered for both the initiator's side and the > responder's side: > > - When should a host discover local candidate locators? > > - Which HIP packets should carry candidate locators? > > - Which HIP packets should initiate reachability checks? > > Answering these questions involves a trade-off. On one hand, > performing these tasks at a late stage during the HIP base exchange > allows a host to defer spending the effort involved in candidate > locator discovery and reachability checks until the correspondent host > has proven its identity and provided reasonable assurance that its > desire to communicate is genuine. Candidate locator discovery and > reachability checks require both signaling as well as memory and > processing on a host. Care must be taken that this cannot be > exploited for resource (memory or processing) exhaustion attacks > against the host, or for reflection-based flooding attacks against > arbitrary victims elsewhere on the Internet. On the other hand, all > HIP packets up to the ones carrying candidate locators must go through > a rendezvous server to ensure successful delivery. Exchanging > candidate locators early during the HIP base exchange therefore > reduces the load on the rendezvous server and enables an earlier > switch to more efficient communications via a direct path. > > We propose the following integration of ICE into the HIP base exchange > and provide rationale for this below: > > - The responder sends its local candidate locators to the initiator > with the R1 message. It discovers its local candidate locators any > time before this. My concern with this is that there can be a lot of work creating the list of locators. How do we avoid the following attacks: a) Sending a lot of I1 packets from a large number of hosts to a responder more or less simultaneously, where the responder wants to use a different locator set for each association. b) Sending I1 packets from a single host to a responder at 3 minute intervals, requiring the responder to assemble a locator list and keep various server-reflexive addresses alive (e.g., by sending UDP packets every 15 seconds). In both cases, the work at the responder is much larger than the work of the various initiators. Furthermore, the ICE security solution requires that the signaling channel between the two endpoints be secure. At present, I believe that there is not a secure channel when the R1 packet is sent (but correct me if I am wrong). For these reasons, I advocate using the I2 and R2 messages to exchange locators (in ICE terms, to carry the Offer and Answer). This means that the responder can delay the gathering of candidates/locators until after it receives the puzzle solution. > > - The initiator begins reachability checks when it receives the R1 > message from the responder. > > - The initiator sends its local candidate locators to the responder > with the I2 message. It discovers its local candidate locators any > time before this. > > - The responder begins reachability checks when it receives the I2 > message from the initiator. > > The discovery of local candidate locators is thus effectively > decoupled from any particular session establishment. This is > necessary because a host discovers local candidates once, and it can > use them with multiple correspondent hosts later on. Moreover, the > threats involved in candidate locator discovery are very limited > anyway. Since the procedure is a one-time task, misusing it for > resource exhaustion is hard. The procedure also involves signaling > only between a host and its STUN, TURN, or rendezvous servers. This > signaling cannot be redirected by an attacker for a flooding attack. What if a host wishes to use different UDP ports (at the UDP encapsulation layer) for different HIP associations? Furthermore, as soon as a host has gathered locators (candidates) it must keep them alive, which can be a burden and certainly consumes resources on the host, resources that will only be freed once a path is selected. > > Reachability checks are more vulnerable to resource exhaustion and > flooding attacks for the following two reasons: > > (1) Reachability checks are tied to a particular correspondent host, > and must hence be redone for each correspondent host. This would > give an attacker the ability to trigger reachability checks if it > could spoof identities. > > (2) An attacker can amplify both resource exhaustion and flooding > attacks via the number of (possibly spoofed) local candidate > locators that it advertises to a victim host. The host pairs each > of these locators with typically multiple local candidate locators > of its own, and it performs a reachability check on each such > pair. In addition, reachability checks that are directed against > a spoofed locator fail to solicit a reponse. This causes the host > to retransmit the reachability checks, increasing amplification > further. The so-called "ICE Hammer" attack. > > It is hence important for a host to defer its reachability checks for > a correspondent host until that correspondent host has proven its > identity and, in case the correspondent host is the session initiator, > provided reasonable assurance that its desire to communicate is > genuine. With the proposed HIP-ICE integration approach, the > initiator of a HIP base exchange defers its reachability checks until > it has received the R1 message because this proves the responder's > identity (via a signature). The proposed approach calls for the > responder to defer its reachability checks until the receipt of the I2 > message because this proves the initiator's identity (via a signature) > and willingness to communicate (via a puzzle solution). > > > > Alternative HIP-ICE Integration Approach > ---------------------------------------- > > The proposed HIP-ICE initegration approach protects the initiator > against the (comparatively small) threat of misuse of candidate > locator discovery because it could defer candidate locator discovery > until after the receipt of the responder's signature. However, the > responder is currently not thus protected as it needs to discover its > local candidate locators already upon receipt of the unauthenticated > I1 message. To also protect the responder against misuse of candidate > locator discovery, exchange of the responder's candidate locators must > take place only after the receipt of the initiator's I2 message. The > responder would then start candidate locator discovery after > verification of the signature in the I2 message, and send its local > candidate locators to the initiator with the R2 message. Yup, though I don't agree with the "(comparatively small)" characterization. > > > > Rendezvous Server Considerations > -------------------------------- > > Exchanging candidate locators in the R1 and I2 messages requires at > least the I1, R1, and I2 messages of the base handshake to be relayed > via a rendezvous server in order to ensure delivery. All messages > from the HIP base exchange must be sent via the rendezvous server if > the candidate locators get exchanged in the I2 and R2 messages. > Either case requires a deviation from the procedure defined in > [HIPRVS], which calls for the R1, I2, and R2 messages to be sent via > the direct path. Yes. The current RVS proposal works only in the absence of NATs. > > > > Mobility and Multi-Homing Considerations > ---------------------------------------- > > The HIP mobility and multi-homing extensions [HIPMM] allow a responder > to advertise new locators in the R1 message, and an initiator may > advertise new locators in the I2 message. This is in-line with the > exchange of candidate locators in these same messages. > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 08 14:55:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU5Sz-0003hk-Gc; Sat, 08 Sep 2007 14:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU5Sy-0003dn-C4 for hipsec@ietf.org; Sat, 08 Sep 2007 14:55:36 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU5Sw-0006UZ-PW for hipsec@ietf.org; Sat, 08 Sep 2007 14:55:36 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2E868212D37; Sat, 8 Sep 2007 21:55:33 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A868F212D1F; Sat, 8 Sep 2007 21:55:31 +0300 (EEST) In-Reply-To: <7FC8B864-0253-4D45-9492-082CE1E159D8@magma.ca> References: <300961F3-760C-4FD0-97CE-D4B900FD70E1@nomadiclab.com> <7FAD0F14-983D-4720-9382-7E3F9D74E48F@nomadiclab.com> <27F0A786-E55A-47B4-B080-63EBBE29B6EF@magma.ca> <0B858FA5-7605-4FED-B0EB-004CF24724F0@nomadiclab.com> <7FC8B864-0253-4D45-9492-082CE1E159D8@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90F25975-74E3-48BF-9DBC-D95D93B6C788@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Anonymous HIs Date: Sat, 8 Sep 2007 21:55:11 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Philip, I don't think this discussion is very useful. The "anonymous" bit is there as a placeholder or hook for additional privacy, as RFC 4423 tries to explain. Whether that is really useful or not, I cannot really say, as the method has not been fully developed. You may be right that it doesn't help even in the non-attack case; otoh, it may help a responder not to bother checking in some cases. I think that the intention is clear -- if not, we apparently have a disconnect in our mental minds. For a starter, I think that privacy is mostly an economic issue, not so much a civil rights issue. In other words, my thinking there is quite much influenced by Andrew Odlyzko's work. Hence, to me anonymity is not just something nice to have but something that is absolutely necessary for the electronic market places to work in the long run. But that is a long story, and I don't know if we should go there here. I also think that as the bit stays today, it is most probably insufficient. More or less the same as with opportunistic mode -- there is just too little in the spec to be really useful. But I think it is a good placeholder for future developments, just like the opportunistic mode. --Pekka On 7 Sep 2007, at 16:34, Philip Matthews wrote: > > On 7-Sep-07, at 08:49 , Pekka Nikander wrote: > >> >> On 7 Sep 2007, at 15:25, Philip Matthews wrote: >> >>> The only protocol action the receiving host can take is to reject >>> the request to set up the HIP association. Is this correct? >> >> Basically, yes. Other than that, the host may not want to >> "remember" the anonymous HI afterwards; see RFC 4423 Section 5.2. > Do you really mean section 5.2 "Storing Host Identifiers in DNS"? I > don't see anything in there about remembering HIs. > >> >>> What prevents a host from lying about this setting? How does this >>> proposal avoid the security flaws of the Evil Bit proposal (RFC >>> 3514)? >> >> Well, while there is no way to check if a HI is anonymous, a host >> may certainly check that a HI *is* registered (i.e. not >> anonymous), if it can infer the registry from the context. That >> is, while you cannot attribute an anonymous HI to anyone (at least >> in theory), you may have a policy that requires all non-anonymous >> HIs to be attributable. > > If I understand you, under this policy the host rejects anonymous > HIs and all non-anonymous HIs that it cannot verify. So why is the > A bit helpful? > > The only case I can see where an A bit would be helpful is if a > host would accept both anonymous and non-anonymous HIs. For non- > anonymous HIs, it verified that they are indeed in the appropriate > registry, which is assumed to be an expensive operation, hence the > desire to avoid this check for HIs which are anonymous. It then > does something different with two types of HIs, but I am not sure > what that different thing would be. However, I can see problems > with this too: what about a DoS attack where hosts set the A bit > incorrectly to force extra work on the receiver? > > - Philip > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 10 03:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdd0-0001UT-Ay; Mon, 10 Sep 2007 03:24:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdcz-0001UN-8j for hipsec@ietf.org; Mon, 10 Sep 2007 03:24:13 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUdcy-0003zX-Ee for hipsec@ietf.org; Mon, 10 Sep 2007 03:24:13 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3A834212D37; Mon, 10 Sep 2007 10:24:10 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id F3725212D1F; Mon, 10 Sep 2007 10:24:09 +0300 (EEST) Message-ID: <46E4F119.6070104@nomadiclab.com> Date: Mon, 10 Sep 2007 10:24:09 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> In-Reply-To: <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Pekka Nikander , HIPsec Mailing List , simon.schuetz@netlab.nec.de, Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> - The responder sends its local candidate locators to the initiator with >> the R1 message. It discovers its local candidate locators any time before >> this. > > My concern with this is that there can be a lot of work creating the list of > locators. How do we avoid the following attacks: a) Sending a lot of I1 > packets from a large number of hosts to a responder more or less > simultaneously, where the responder wants to use a different locator set for > each association. b) Sending I1 packets from a single host to a responder at > 3 minute intervals, requiring the responder to assemble a locator list and > keep various server-reflexive addresses alive (e.g., by sending UDP packets > every 15 seconds). In both cases, the work at the responder is much larger > than the work of the various initiators. > > Furthermore, the ICE security solution requires that the signaling channel > between the two endpoints be secure. At present, I believe that there is not > a secure channel when the R1 packet is sent (but correct me if I am wrong). > > For these reasons, I advocate using the I2 and R2 messages to exchange > locators (in ICE terms, to carry the Offer and Answer). This means that the > responder can delay the gathering of candidates/locators until after it > receives the puzzle solution. Philip, using I2 and R2 messages to exchange locators is what I was describing in section "Alternative HIP-ICE Integration Approach". The reason I preferred using the R1 and I2 messages is that it allows earlier use of a direct path, and that I considered the residual vulnerabilities small. Now, while I don't see a reason for a responder to enforce a different locator set per association (your item a above), I do see your point that keep-alives for server-reflexive addresses might be exploitable (your item b above). Using I2 and R2 messages to exchange locators would mitigate this. > What if a host wishes to use different UDP ports (at the UDP encapsulation > layer) for different HIP associations? Furthermore, as soon as a host has > gathered locators (candidates) it must keep them alive, which can be a burden > and certainly consumes resources on the host, resources that will only be > freed once a path is selected. These issues are similar to what you described further up as items a and b. Again, I do not see a reason for a responder to enforce different ports per association. But the issue of exploitable keep-alive overhead is valid. Best, - Christian _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 10 04:51:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUezU-0006fa-7o; Mon, 10 Sep 2007 04:51:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUezS-0006eG-SO for hipsec@ietf.org; Mon, 10 Sep 2007 04:51:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUezS-0006Ro-EI for hipsec@ietf.org; Mon, 10 Sep 2007 04:51:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6A3BA2D22; Mon, 10 Sep 2007 11:51:29 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4710D2CE2; Mon, 10 Sep 2007 11:51:22 +0300 (EEST) Date: Mon, 10 Sep 2007 11:51:22 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: marcelo bagnulo braun Subject: Re: [Hipsec] NAT Traversal in HIP In-Reply-To: Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boei ng.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1189414282=:19647" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1189414282=:19647 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Fri, 7 Sep 2007, marcelo bagnulo braun wrote: Hi Marcelo, > catching up.... > > El 31/08/2007, a las 8:14, Miika Komu escribi=F3: > >> * HIP mobility and multihoming: this will get messy with ICE? This may >> also reduce code reusability from ICE significantly. >>=20 > > maybe true, but if you want to support mobility and multihoming on nate= d=20 > environments, you need extra functionality that currently is not there = and=20 > then you need to add ICE like capabilities. > > I mean, for example, for multihoming, you need failure detection. This=20 > probably involves sending some periodic probes. OTOH, in a nated enviro= nment,=20 > you need to send probes to keep the state alive. I guess it makes most = sense=20 > to use the same probes for keeping the nat state alive and for failure=20 > detection. Bottom line is that this will get messy in any case, because= there=20 > seems to be a lot of interactions between the multihoming mechanisms an= d the=20 > nat traversal mechanisms. > > OTOH, my personal opinion at this stage, is that it will be easier to e= xtend=20 > ICE to support the additional features needed like failure detection in= =20 > mulithomed environments) than to extend current multihoming techniques = to=20 > support all the nat traversal stuff. So from a practical perspective, i= would=20 > start from ICE and extend it to support the additional features needed. how would you suggest solving the rendezvous/relay problem using ICE? --=20 Miika Komu http://www.iki.fi/miika/ ---559023410-1804928587-1189414282=:19647 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec ---559023410-1804928587-1189414282=:19647-- From hipsec-bounces@lists.ietf.org Mon Sep 10 13:31:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUn6T-0003iw-1B; Mon, 10 Sep 2007 13:31:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUn6R-0003Ul-Qg for hipsec@ietf.org; Mon, 10 Sep 2007 13:31:15 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUn6R-0005ge-BC for hipsec@ietf.org; Mon, 10 Sep 2007 13:31:15 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IUn6P-0002vi-2T; Mon, 10 Sep 2007 13:31:13 -0400 In-Reply-To: <46E4F119.6070104@nomadiclab.com> References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Mon, 10 Sep 2007 13:28:47 -0400 To: Christian Vogt X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Pekka Nikander , HIPsec Mailing List , simon.schuetz@netlab.nec.de, Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 10-Sep-07, at 03:24 , Christian Vogt wrote: > > The reason I preferred using the R1 and I2 messages is that it > allows earlier > use of a direct path, and that I considered the residual > vulnerabilities small. > Now, while I don't see a reason for a responder to enforce a > different locator > set per association (your item a above), I do see your point that > keep-alives > for server-reflexive addresses might be exploitable (your item b > above). Using > I2 and R2 messages to exchange locators would mitigate this. Just to be clear, I am not proposing that we _enforce_ the use of a different locator set for each association. However, I would like it to be a viable option. Otherwise, you are enforcing the reverse: a responder _must_ use the same locator set for all associations. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 10 13:45:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJw-0002r9-Or; Mon, 10 Sep 2007 13:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJv-0002pw-4Y for hipsec@ietf.org; Mon, 10 Sep 2007 13:45:11 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUnJt-0004Pk-Ie for hipsec@ietf.org; Mon, 10 Sep 2007 13:45:11 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 033E0212D37; Mon, 10 Sep 2007 20:45:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6D69E212D1F; Mon, 10 Sep 2007 20:45:07 +0300 (EEST) In-Reply-To: <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3198901A-3E7D-41F5-9A31-2C3DBF83933B@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Mon, 10 Sep 2007 20:44:52 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: simon.schuetz@netlab.nec.de, Christian Vogt , Gonzalo Camarillo , HIPsec Mailing List X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> The reason I preferred using the R1 and I2 messages is that it >> allows earlier >> use of a direct path, and that I considered the residual >> vulnerabilities small. >> Now, while I don't see a reason for a responder to enforce a >> different locator >> set per association (your item a above), I do see your point that >> keep-alives >> for server-reflexive addresses might be exploitable (your item b >> above). Using >> I2 and R2 messages to exchange locators would mitigate this. > > Just to be clear, I am not proposing that we _enforce_ the use of a > different locator > set for each association. However, I would like it to be a viable > option. I don't see any reason why we should mandate that the locators are exchanged in either R1/I2, I2/R2 or even later with UPDATEs. That is, just like in the case of the HIP mobility extension, to me the HIP "ICE extension" would be a more-or-less independent protocol run on the top of the "HIP substrate", created by the base exchange, and then enhancing and modifying the properties of the "substrate". Hence, if I understand the situation right, we can have both, and leave the choice to a local policy at execution time. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 02:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyq5-0000F3-3P; Tue, 11 Sep 2007 02:03:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyq3-0000Ex-Pe for hipsec@ietf.org; Tue, 11 Sep 2007 02:03:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUyq3-0001D5-Em for hipsec@ietf.org; Tue, 11 Sep 2007 02:03:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6CDC7212D37; Tue, 11 Sep 2007 09:03:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 34399212D1F; Tue, 11 Sep 2007 09:03:05 +0300 (EEST) Message-ID: <46E62F98.9040102@nomadiclab.com> Date: Tue, 11 Sep 2007 09:03:04 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> <3198901A-3E7D-41F5-9A31-2C3DBF83933B@nomadiclab.com> In-Reply-To: <3198901A-3E7D-41F5-9A31-2C3DBF83933B@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: simon.schuetz@netlab.nec.de, HIPsec Mailing List , Philip Matthews , Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Pekka and Philip: Pekka Nikander wrote: > Hence, if I understand the situation right, we can have both, and leave > the choice to a local policy at execution time. Right. What the specification would have to provide is a description of the security considerations that apply to either of the approaches. Best regards, - Christian _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 07:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV44e-0002Vj-5W; Tue, 11 Sep 2007 07:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV44c-0002Ve-Ot for hipsec@ietf.org; Tue, 11 Sep 2007 07:38:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV44b-0008EL-Gr for hipsec@ietf.org; Tue, 11 Sep 2007 07:38:30 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E5F8F20520; Tue, 11 Sep 2007 13:38:28 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-9a-46e67e342b62 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CDF9320507; Tue, 11 Sep 2007 13:38:28 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 13:38:28 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 13:38:28 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 682E523F6; Tue, 11 Sep 2007 14:38:28 +0300 (EEST) Message-ID: <46E67E34.2090401@ericsson.com> Date: Tue, 11 Sep 2007 14:38:28 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Sep 2007 11:38:28.0473 (UTC) FILETIME=[45983E90:01C7F468] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Hipsec] NAT traversal design team X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we would like to form a small design team to work on NAT traversal for HIP, which, as you know, is one of our chartered work items. Design team members will be expected to actively participate in conference calls and may be required to write text for the draft. That is, if you want to monitor the progress of this work, you do not need to be in the design team. They will send periodic reports to the mailing list. On the other hand, if you can commit cycles to actively work on this issue, you are welcome to volunteer. The design team will take the three following drafts and the mailing list discussions as its starting point. http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt If you want to volunteer, reply to this email (only to me; no need to spam the list) letting me know. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 08:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4wJ-0003Zg-D1; Tue, 11 Sep 2007 08:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4wI-0003Za-PZ for hipsec@ietf.org; Tue, 11 Sep 2007 08:33:58 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV4wH-0001Cq-Ar for hipsec@ietf.org; Tue, 11 Sep 2007 08:33:58 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6EF622C27; Tue, 11 Sep 2007 15:33:56 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 2A7272C40; Tue, 11 Sep 2007 15:33:49 +0300 (EEST) Date: Tue, 11 Sep 2007 15:33:49 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Christian Vogt In-Reply-To: <46E0F5A6.1030006@nomadiclab.com> Message-ID: References: <46E0F5A6.1030006@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: simon.schuetz@netlab.nec.de, Pekka Nikander , HIPsec Mailing List , Gonzalo Camarillo Subject: [Hipsec] Re: ICE/HIP Integration: A Solution Space Analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 7 Sep 2007, Christian Vogt wrote: Hi, thanks for text! I'll consider it in the next version, but for the time being we should postpone until there is design team which has decided on the direction to go. > Folks, > > [draft-ietf-hip-nat-traversal-02] builds ICE functionality into HIP. An > integration like this requires, of course, design decisions WRT which > ICE-related meaning/action HIP messages should bear/trigger. > > I was missing some rationale for the specific solution in [draft-ietf-hip-nat- > traversal-02]. So I made my own evaluation of the solution space for ICE/HIP > integration. I am attaching this because it may be interesting for you as well. > > Since the result of my evaluation is supportive of [draft-ietf-hip-nat- > traversal-02], I suggest to use it as a new "Rationale" section in the draft. > > Best regards, > - Christian > > P.S.: The attached evaluation may be useful also for [draft-tschofenig-hip- > ice-00], but I did not look into this yet. > > > > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 08:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV52T-0001CA-A8; Tue, 11 Sep 2007 08:40:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV52R-0001C4-Mi for hipsec@ietf.org; Tue, 11 Sep 2007 08:40:20 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV52R-00032r-9t for hipsec@ietf.org; Tue, 11 Sep 2007 08:40:19 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2CCA12D67; Tue, 11 Sep 2007 15:40:18 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 71CB42D67; Tue, 11 Sep 2007 15:40:11 +0300 (EEST) Date: Tue, 11 Sep 2007 15:40:11 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis In-Reply-To: <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> Message-ID: References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Pekka Nikander , Christian Vogt , simon.schuetz@netlab.nec.de, Gonzalo Camarillo , HIPsec Mailing List X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Sep 2007, Philip Matthews wrote: > > On 10-Sep-07, at 03:24 , Christian Vogt wrote: > >> >> The reason I preferred using the R1 and I2 messages is that it allows >> earlier >> use of a direct path, and that I considered the residual vulnerabilities >> small. >> Now, while I don't see a reason for a responder to enforce a different >> locator >> set per association (your item a above), I do see your point that >> keep-alives >> for server-reflexive addresses might be exploitable (your item b above). >> Using >> I2 and R2 messages to exchange locators would mitigate this. > > Just to be clear, I am not proposing that we _enforce_ the use of a different > locator > set for each association. However, I would like it to be a viable option. > > Otherwise, you are enforcing the reverse: a responder _must_ use the same > locator set > for all associations. Hi, FYI, the locators are not in included in R2 in the 02 version of the draft because I wanted first to gather some feedback on this issue. I have no strong objection to it and it actually seems a useful feature. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 10:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Pr-00061y-2l; Tue, 11 Sep 2007 10:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Pp-00061k-Ii for hipsec@ietf.org; Tue, 11 Sep 2007 10:08:33 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6Po-0003jm-BO for hipsec@ietf.org; Tue, 11 Sep 2007 10:08:33 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id DAF842D70; Tue, 11 Sep 2007 17:08:31 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DE3B92D13; Tue, 11 Sep 2007 17:08:24 +0300 (EEST) Date: Tue, 11 Sep 2007 17:08:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] NAT Traversal in HIP In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049757@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049757@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 4 Sep 2007, Henderson, Thomas R wrote: Hi Tom, >> Yes, it seems tempting implementation wise, but I have >> expressed several >> concerns on this list which should be addressed first. > > I am not suggesting that existing ICE library is the answer, but that I > would rather look at the existing capabilities first of ICE and also the > Cornell NUTSS software to see how much is already there. I guess that > my point is that if you start writing the HIP relay server from scratch, > you miss the opportunity to learn how existing approaches can be > leveraged. That is why I just said that my inclination is to try the > existing approaches first and see where the holes may be. The NUTSS stuff is interesting but I think it belongs the RG for the time being. >> * HIP Relay server: this is needed for guaranteed NAT traversal. >> The relay has to forward HIP control packets which contain >> the transport >> address candidates. So we can't use STUN servers for this. > > I think that this is an open question that deserves further study. I have presented a concrete specification for a HIP-relay middlebox in the 02 version of the draft. So far, nobody has presented an alternative. I think the Relay spec in 02 version of the draft could be used also if the WG wants ICE format for the messages. >> I have also expressed other concerns, such as security related, in my >> earlier emails and won't repeat them here. I hope that people >> address the >> issues that have been presented on this list on a technical >> level. In the >> end, we should select single approach to support interoperability. > > I think I would say the goal is to achieve interoperability, and whether > a single or multiple approaches leads to this is for further study. > > I appreciate that you have already done a lot of work on this and maybe > I just need to catch up to your level of understanding. Well, one option could be to design an alternative NAT traversal mechanism in the RG, perhaps based on NUTSS architecture. Is this what you are suggesting? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 11:20:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7XU-0001ht-PU; Tue, 11 Sep 2007 11:20:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7XT-0001ha-5H for hipsec@ietf.org; Tue, 11 Sep 2007 11:20:31 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV7XS-0008Ak-PZ for hipsec@ietf.org; Tue, 11 Sep 2007 11:20:31 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8BFKIVA002649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2007 08:20:18 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8BFKHPK016042; Tue, 11 Sep 2007 08:20:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8BFK7g0015479; Tue, 11 Sep 2007 08:20:16 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 08:20:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NAT Traversal in HIP Date: Tue, 11 Sep 2007 08:20:15 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049795@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] NAT Traversal in HIP Thread-Index: Acf0fVCNgI2cSnzSQb2LhrPPtyUGoAABPqPQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 11 Sep 2007 15:20:15.0794 (UTC) FILETIME=[41604920:01C7F487] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, > >> * HIP Relay server: this is needed for guaranteed NAT traversal. > >> The relay has to forward HIP control packets which contain > >> the transport > >> address candidates. So we can't use STUN servers for this. > > > > I think that this is an open question that deserves further study. >=20 > I have presented a concrete specification for a HIP-relay=20 > middlebox in the=20 > 02 version of the draft. So far, nobody has presented an=20 > alternative. I=20 > think the Relay spec in 02 version of the draft could be used=20 > also if the=20 > WG wants ICE format for the messages. If you think of ICE/STUN running underneath HIP, rather than being integrated with HIP, then the alternative is STUN used in conjunction with existing HIP rendezvous/lookup services. > Well, one option could be to design an alternative NAT=20 > traversal mechanism=20 > in the RG, perhaps based on NUTSS architecture. Is this what you are=20 > suggesting? >=20 No, I'm mainly suggesting trying to experiment with a few approaches before deciding, and to see how far we could get before committing to an explicit relay box. If we get to the point where we need relays in the data path, we should also look at Hi3 architecture again. - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 12:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV8Qb-0007fX-U3; Tue, 11 Sep 2007 12:17:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV8Qa-0007fK-NY for hipsec@ietf.org; Tue, 11 Sep 2007 12:17:28 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV8QZ-0008KT-99 for hipsec@ietf.org; Tue, 11 Sep 2007 12:17:28 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AFC0E2D0D; Tue, 11 Sep 2007 19:17:26 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B1CF82CBA; Tue, 11 Sep 2007 19:17:19 +0300 (EEST) Date: Tue, 11 Sep 2007 19:17:19 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] NAT Traversal in HIP In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049795@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049795@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 11 Sep 2007, Henderson, Thomas R wrote: Tom, > Miika, > >>>> * HIP Relay server: this is needed for guaranteed NAT traversal. >>>> The relay has to forward HIP control packets which contain >>>> the transport >>>> address candidates. So we can't use STUN servers for this. >>> >>> I think that this is an open question that deserves further study. >> >> I have presented a concrete specification for a HIP-relay >> middlebox in the >> 02 version of the draft. So far, nobody has presented an >> alternative. I >> think the Relay spec in 02 version of the draft could be used >> also if the >> WG wants ICE format for the messages. > > If you think of ICE/STUN running underneath HIP, rather than being > integrated with HIP, then the alternative is STUN used in conjunction > with existing HIP rendezvous/lookup services. I am sorry but this "high level" approach already hit the wall as explained details of the earlier emails. This has been already reasoned in several emails why this kind of "insulating" layering does not work. I tempt you to be more specific :) >> Well, one option could be to design an alternative NAT >> traversal mechanism >> in the RG, perhaps based on NUTSS architecture. Is this what you are >> suggesting? > > No, I'm mainly suggesting trying to experiment with a few approaches > before deciding, and to see how far we could get before committing to an > explicit relay box. If we get to the point where we need relays in the > data path, we should also look at Hi3 architecture again. We need a middlebox anyway to forward the address candidates. There is no way of circumvating this in a reliable manner. The middlebox can be explicit or implicit. However, I argue that an completely implicit relay will mean triangular routing for ESP, which should be avoided at any cost. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 12:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV8sr-0002zz-1N; Tue, 11 Sep 2007 12:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV8sp-0002x9-IF for hipsec@ietf.org; Tue, 11 Sep 2007 12:46:39 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV8sm-0000dG-B3 for hipsec@ietf.org; Tue, 11 Sep 2007 12:46:39 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8BGkUQ9007385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2007 09:46:35 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8BGkU2c028741; Tue, 11 Sep 2007 11:46:30 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8BGkO36028322; Tue, 11 Sep 2007 11:46:28 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 09:46:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NAT Traversal in HIP Date: Tue, 11 Sep 2007 09:46:22 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0404979B@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] NAT Traversal in HIP Thread-Index: Acf0jz/AP01EZi6zRr+fBwY9lnI5OAAA0cAg From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 11 Sep 2007 16:46:22.0591 (UTC) FILETIME=[4906F0F0:01C7F493] X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, > > If you think of ICE/STUN running underneath HIP, rather than being > > integrated with HIP, then the alternative is STUN used in=20 > conjunction > > with existing HIP rendezvous/lookup services. >=20 > I am sorry but this "high level" approach already hit the wall as=20 > explained details of the earlier emails. This has been=20 > already reasoned in=20 > several emails why this kind of "insulating" layering does=20 > not work. I=20 > tempt you to be more specific :) draft-tschofenig-hip-ice-00.txt was suggested today to be within scope of the design team. =20 - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 11 16:55:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVClB-0000iA-I3; Tue, 11 Sep 2007 16:55:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCl9-0000TL-FK for hipsec@ietf.org; Tue, 11 Sep 2007 16:54:59 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVCl9-0001Co-55 for hipsec@ietf.org; Tue, 11 Sep 2007 16:54:59 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IVCl5-00077U-1z; Tue, 11 Sep 2007 16:54:55 -0400 In-Reply-To: References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A109173-3D26-484A-A049-9B7B4EB953F2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Tue, 11 Sep 2007 16:54:29 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Pekka Nikander , Christian Vogt , simon.schuetz@netlab.nec.de, Gonzalo Camarillo , HIPsec Mailing List X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org One additional point on all this. The ICE security analysis relies on the fact that ICE information exchanged is done so in a manner that prevents an attacker from eavesdropping. So I am guessing that, in order to include the locator info in the R1 packet, the Initiator would need to include its public key in the I1 packet, which is a (small) change from the way things are done right now. Am I correct? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 12 02:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLUx-0001h0-Aw; Wed, 12 Sep 2007 02:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLUw-0001gv-7c for hipsec@ietf.org; Wed, 12 Sep 2007 02:14:50 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVLUu-0007F0-K0 for hipsec@ietf.org; Wed, 12 Sep 2007 02:14:50 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D83E7212D37; Wed, 12 Sep 2007 09:14:46 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 68B23212D1F; Wed, 12 Sep 2007 09:14:46 +0300 (EEST) In-Reply-To: <7A109173-3D26-484A-A049-9B7B4EB953F2@magma.ca> References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> <7A109173-3D26-484A-A049-9B7B4EB953F2@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Wed, 12 Sep 2007 09:14:30 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: simon.schuetz@netlab.nec.de, Christian Vogt , HIPsec Mailing List , Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > The ICE security analysis relies on the fact that ICE information > exchanged is done so in a manner that prevents an attacker from > eavesdropping. So I am guessing that, in order to include the > locator info in the R1 packet, the Initiator would need to include > its public key in the I1 packet, which is a (small) change from the > way things are done right now. Am I correct? Well, sending the public key in I1 and changing when session key is created would be a *major* change to HIP, changing its security properties to a very large extend. See Aura, T., Nagarajan, A. & Gurtov, A. (2005), Analysis of the HIP Base Exchange Protocol, in 'the 10th Australasian Conference on Information Security and Privacy (ACISP 2005)', Vol. 3574 of Lecture Notes in Computer Science, Springer-Verlag, Brisbane, Australia, pp. 481--493. http:// infrahip.hiit.fi/papers/analysis_hip.pdf (Please note that the changes proposed in the paper have been mostly incorporated to the present versions of the protocol.) What comes to ICE security, I'm intrigued about your claim. Where can I read the security analysis? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 12 15:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXy2-0002hk-G3; Wed, 12 Sep 2007 15:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXy0-0002gu-OD for hipsec@ietf.org; Wed, 12 Sep 2007 15:33:40 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVXxz-0008Tu-GE for hipsec@ietf.org; Wed, 12 Sep 2007 15:33:40 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IVXxm-0003vA-1i; Wed, 12 Sep 2007 15:33:26 -0400 In-Reply-To: References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> <7A109173-3D26-484A-A049-9B7B4EB953F2@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Wed, 12 Sep 2007 15:33:20 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: simon.schuetz@netlab.nec.de, Christian Vogt , HIPsec Mailing List , Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 12-Sep-07, at 02:14 , Pekka Nikander wrote: >> The ICE security analysis relies on the fact that ICE information >> exchanged is done so in a manner that prevents an attacker from >> eavesdropping. So I am guessing that, in order to include the >> locator info in the R1 packet, the Initiator would need to include >> its public key in the I1 packet, which is a (small) change from >> the way things are done right now. Am I correct? > > Well, sending the public key in I1 and changing when session key is > created would be a *major* change to HIP, changing its security > properties to a very large extend. See Aura, T., Nagarajan, A. & > Gurtov, A. (2005), Analysis of the HIP Base Exchange Protocol, in > 'the 10th Australasian Conference on Information Security and > Privacy (ACISP 2005)', Vol. 3574 of Lecture Notes in Computer > Science, Springer-Verlag, Brisbane, Australia, pp. 481--493. > http://infrahip.hiit.fi/papers/analysis_hip.pdf (Please note that > the changes proposed in the paper have been mostly incorporated to > the present versions of the protocol.) What about the I2 and R2 packets? My understanding is that the ENCRYPTED TLV can be included in those messages, and they can in turn include multiple sub-attributes (such as LOCATOR). Is this correct? > > What comes to ICE security, I'm intrigued about your claim. Where > can I read the security analysis? http://tools.ietf.org/html/draft-ietf-mmusic-ice-17#section-18 See in particular the discussion related to a secure offer/answer exchange or secure signaling. In a nutshell, the two ICE endpoints exchange a "username fragment" and a "password" as part of the offer/answer exchange. These are used as follows: L R |===========Offer;ufrag:UL,pass:PL=========>| |<========Answer;ufrag:UR,pass:PR===========| | | |-----STUN Request user:"UR:UL"------------>| |<---------STUN Response--------------------| | | |<----STUN Request user:"UL:UR"-------------| |----------STUN Response------------------->| The two username fragments are concatenated together to form the username in the STUN Request message. This shows that the request is sent and received by the correct endpoints (see the discussion in section B.4 of the ICE spec). The password is used as the keying material for the MESSAGE-INTEGRITY attribute in the STUN messages, which ensures that the STUN messages have not been corrupted or faked. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Sep 12 15:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVY3l-0004Bn-O0; Wed, 12 Sep 2007 15:39:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVY3k-0004B2-LP for hipsec@ietf.org; Wed, 12 Sep 2007 15:39:36 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVY3j-000654-Eo for hipsec@ietf.org; Wed, 12 Sep 2007 15:39:36 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 71FAA2D24; Wed, 12 Sep 2007 22:39:34 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 6F0BF2C2B; Wed, 12 Sep 2007 22:39:26 +0300 (EEST) Date: Wed, 12 Sep 2007 22:39:26 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709051533.34704.julien.IETF@laposte.net> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 5 Sep 2007, Julien Laganier wrote: Julien, > I have reviewed draft-ietf-hip-native-api-02.txt, and I think the > documents is in good shape. > > I have however a couple of comments and suggested changes below that I > would like to see addressed before the document is sent to IESG for > publication. thanks for the review! I have addressed all of your editorial comments in the draft. A preversion of the next version of the draft based on your comments is in here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt > I had no time to distinguish between editorial and technical ones, > sorry. No problem. Below I have commented only the things that were unclear or need further clarification, otherwise I applied your comments as you suggested. I see no need to repeat minor nits here. > SHIM and SHIM-aware are not defined in the introduction. At minimum I > would expect the abstract text explaining the HIP focus but larger > applicability to other SHIM layers to be duplicated here. Added some text to intro, I hope the changes are fine. > Also, if we talk about address family, shouldn't we use AF_SHIM instead > of PF_SHIM? In practice, there is no difference between AF and PF. Added text: The API extensions introduce a new address family, AF_SHIM, and a new socket address structure for sockets using explicit identifier- locator bindings. PF_SHIM is used as an alias for AF_SHIM in this document because the distinction between PF and AF has been lost in the practice. > Also, is "initiate outgoing communications without knowledge of the peer > identity" opportunistic mode? If yes it should be spelled out. I don't > see how it is possible to accept a HIP incoming communication without > knowledge of the peer identity since identity will be in I2... Maybe > you refer to initiate outgoing communications without knowing the local > identity? > >> This document describes also how to address this situation using late >> binding based on new wildcards. > > 'late binding' is not defined. We can't expect anyone to understand what > it means. Removed 'late binding' since it was not really used elsewhere in the text. Changed the 'initiate outgoing' text to this: Some applications may accept incoming communications from any identifier. Other applications may initiate outgoing communications without knowledge of the peer identifier in Opportunistic Mode [I-D.ietf-hip-base] by just relying on a peer locator. This document describes how to address both situations using "wildcards" described in a later section. >> There are two related IETF documents that are define other related >> API extensions. Multihoming related APIs are defined in >> [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy >> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] > > I disagree with the use of 'other related API extensions' in this > context. While this document does indeed defines extensions to the > socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api]. Changed to: There are two related API documents. Multihoming related APIs are defined in [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy attributes and channel bindings are defined in [I-D.ietf-btns-c-api] > human readable names are not limited to FQDNs, unqualified DNS names can > be used too (e.g. thanks to the 'search example.com' line in > a /etc/resolv.conf). I'm also not sure about restricting user > interfaces to human-readable names (e.g. FQDN), it also happens that IP > addresses are entered in user interface, alone or embedded in a URL. I hope this is better then: User Interface | Hostname, FQDN or ULID >> We limit the description to those interfaces and data structures that >> are either modified or completely new, because the SHIM API is >> otherwise identical to the sockets API [POSIX]. > > In all API definitions that follows, it should be specified which header > file should be included to result in the definitions (e.g. PF_SHIM, > AF_SHIM, sockaddr_shim), e.g. , or > . It would also be good to have a section that recapitulate > all new definitions at the end of the document. Added this, I hope it is ok now. >> The application usually sets the sins_ulid field using the >> resolver. However, three special macros can be used to directly set a >> value into the sins_ulid field. The macros are SHIM_ANY, >> SHIM_ANY_PUB and SHIM_ANY_ANON. They denote an ULID value associated >> with a wildcard ULID of any, public, or anonymous type. > > I miss the definition of these different ULID types (public vs. > anonymous). I think we need some more text or a reference to another > document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 > ULID's). Added the reference as you suggested and added a reference HIP architecture RFC as well regarding to the anonymous bit. I hope this is ok? We could also removed the ANON and PUB altogether (I am referring to the discussion of Pekka and Philip on the anonymity topic). > I'm not sure about the restriction to one host binding on a given port. > There are TCP/IP stacks that allows binding multiple processes to bind > to same addresses and/or ports through the use of the appropriate > socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite > them here, or remove the above restriction. Removed. >> A client application can use the SHIM_ANY macro to establish a > > s/macro to establish a/macro with connect() or sendto() calls/ Instead of listing all the socket calls, the text now says "outgoing communications". I hope this is ok to cover both TCP and UDP based communication? >> known beforehand. >> In both client and server based applications, the use of the >> SHIM_ANY* macro accepts also non-SHIM based communications to >> maximize backwards compatibility. > > The text should specify that goes into the sins_ulid field (e.g. zeroes) > when that is the case. The SHIM_ANY macros is actually used to initialized that particular field. Clarified the text. > >> When the application wants >> enforces the use of SHIM-based communications with ORCHID prefix >> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >> Alternatively, the application accepts both ORCHID and non-ORCHID- >> based communications, but informs the difference e.g. to the user. >> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro > > How about SHIM_IS_IPV6_ADDR_ORCHID instead? Agreed. >> The flag AI_SHIM must be set, or otherwise the resolver does not >> return sockaddr_shim data structures to guarantee that legacy >> applications do not break. > > But presumably legacy applications would not set ai_family to PF_SHIM, > so the AI_SHIM flags seems redundant. > > .. >> The protocol field is 0 when the getaddrinfo caller does not care >> about the specific SHIM protocol to be used. The caller (or the >> resolver) can set this field also to IPPROTO_HIP. > > .. > > Since this API is supposed to be usable for multiple SHIM protocols > (e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in > use I'd think that the caller MUST set the protocol field to the > constant identifying the protocol in use (e.g. IPPROTO_HIP, > IPPROTO_SHIM6). Removed the statement on removing legacy applications. I think the AI_SHIM flag is still necessary. The protocol field can be set to zero even with SHIM-aware applications when the application does not care which particular SHIM protocol it is riding on. In such a case, a separate flag is needed. >> Some applications may prefer >> configuring the locators manually and can set the AI_SHIM_NOLOCATORS >> flag to prohibit the getaddrinfo from resolving any locators. >> >> The ai_family field is PF_SHIM with SHIM-specific addrinfo data >> structures. > > What is the "SHIM-specific addrinfo data structures" ? do you mean an > addrinfo data structure with an ai_addr pointing to a sockaddr_shim > data structure? Yes, corrected. >> ai_addrlen is the size of the structure pointed by ai_addr. > > This is already specified as part of RFC3493. No need to duplicate that > information here. I think it is more reader-friendly to go through all of the fields one-by-one and describe how they are affected by the draft. Added some clarifications: ai_addrlen is the size of the structure pointed by ai_addr. This equals to sizeof(struct sockaddr_shim) when when ai_family field is PF_SHIM. >> The output argument res is dynamically allocated by the resolver. >> The application must free res argument with the free_addrinfo >> function. > > We do not need to specify that here, that's orthogonal to the discussion > we're having IMO. I think it is useful to recap here how the resolver works. Changed the text to: The output argument res is dynamically allocated by the resolver. The application frees res argument with the free_addrinfo function. The res argument contains a linked list of the resolved endpoints. The linked list contains sockaddr_shim structures only when the input argument has the AI_SHIM flag set. When the resolver finds SHIM identifiers, it inserts them to the front of the list. SHIM identifiers for different protocols are sorted according to local policies. Non-SHIM identifiers are present only when ai_protocol is set zero in the hints arguments of getaddrinfo() or the hints argument is NULL. The non-SHIM identifiers are placed after SHIM identifiers. Notice: I added text that sorting e.g. between HIP vs. SHIM6 identifiers is a local policy issue. >> The res argument contains a linked list of the resolved >> endpoints. The linked list contains sockaddr_shim structures only >> when the input argument has the AI_SHIM flag set. When the >> resolver finds SHIM identifiers, it inserts them to the front of the >> list. > > This seems to imply that the resolver may also return non-SHIM sockaddr > structures (e.g. sockaddr_in6) at the tail of the list. That should be > made explicit. Done. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 13 07:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hm-OE; Thu, 13 Sep 2007 07:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hc-7O for hipsec@lists.ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnB7-0001kP-SY for hipsec@lists.ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: by ug-out-1314.google.com with SMTP id z38so371348ugc for ; Thu, 13 Sep 2007 04:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cczhwW+O2YYBSz9PsushRg+eRHTp/JG6iclQCEdgC5o=; b=KYP+QzE9S4tCThRY/RNJaDJXLf7utd421idjwe+NAqm7ElcpjNGDfP32mxbQ0aGMILNb/5Rg81WrHkI6kAwQZMf++oQk/XsVfKajeof9gYqioPp1u0B79o4bROA7y9e0i2ciiKH7ydVkWdS35YqcOJxMwqjLdnNffOLkOgpMaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pO1gW9EfqICUq367nc88+b2QGTb6QRyNRftH/pkuybeDc2x4HC+UxOdVgqz84PGtl5LGoKS7q/HGYDZGn95hsgwBIWDIn6mlH/ma8G5uq/aKn8DDl6LNi8idp00ON2N9kjSuRoohCqD2sCEKhwFY+jbXaX8BpOPvaCQ0WFHJwg8= Received: by 10.67.24.18 with SMTP id b18mr499344ugj.1189684092420; Thu, 13 Sep 2007 04:48:12 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm1030286ugd.2007.09.13.04.48.10 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 04:48:11 -0700 (PDT) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Thu, 13 Sep 2007 13:48:07 +0200 User-Agent: KMail/1.9.6 References: <200709051533.34704.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709131348.07644.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, On Wednesday 12 September 2007, Miika Komu wrote: > > thanks for the review! I have addressed all of your editorial > comments in the draft. A preversion of the next version of the draft > based on your comments is in here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt I found one more problem with the definition of LSI: It is not the presentation of a public key, but rather a 32-bit handle, or descriptor. Suggest to change the definition to: LSI : Local Scope Identifier, a local, 32-bit descriptor for a given public key. > Below I have commented only the things that were unclear or need > further clarification, otherwise I applied your comments as you > suggested. I see no need to repeat minor nits here. All right. The updated draft looks good. Couple of followups below where more discussion is needed (I deleted the rest): > > SHIM and SHIM-aware are not defined in the introduction. At minimum > > I would expect the abstract text explaining the HIP focus but > > larger applicability to other SHIM layers to be duplicated here. > > Added some text to intro, I hope the changes are fine. I think that the following paragraph of the intro should also be duplicated in section 4 which specifies the API: An application can also use the new family to detect SHIM support in the local host. Namely, the application creates a socket by calling socket() function with the first argument (domain) as AF_SHIM. The system returns a positive integer representing a socket descriptor when the system supports SHIM. Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT. > > human readable names are not limited to FQDNs, unqualified DNS > > names can be used too (e.g. thanks to the 'search example.com' line > > in a /etc/resolv.conf). I'm also not sure about restricting user > > interfaces to human-readable names (e.g. FQDN), it also happens > > that IP addresses are entered in user interface, alone or embedded > > in a URL. > > I hope this is better then: > > User Interface | Hostname, FQDN or ULID relative (i.e. not fully qualified) domain name are not necessarily limited to hostname, they can be any domain name taken relative to a well known origin, or to a list of domains used as a search list. For example, when the list of domain used as a search list contains "isi.edu." and "cs.isi.edu.", the fully qualified domain name "www.cs.isi.edu." corresponds to both of these relative domain name: "www" and "www.cs". > >> We limit the description to those interfaces and data structures > >> that are either modified or completely new, because the SHIM API > >> is otherwise identical to the sockets API [POSIX]. > > > > In all API definitions that follows, it should be specified which > > header file should be included to result in the definitions (e.g. > > PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , > > or . It would also be good to have a > > section that recapitulate all new definitions at the end of the > > document. > > Added this, I hope it is ok now. I checked it, and I am questioning the location of the "shim.h" header file. My understanding is that the SHIM layer will be used in cunjunction with an internet protocol. As such, my choice would be to put the "shim.h" header file in the "netinet/" subdirectory. That is replace with . If the SHIM facility is expected to be used with network protocols other than internet ones, then I'd rather expect What do you think? > >> A client application can use the SHIM_ANY macro to establish a > > > > s/macro to establish a/macro with connect() or sendto() calls/ > > Instead of listing all the socket calls, the text now says "outgoing > communications". I hope this is ok to cover both TCP and UDP based > communication? I still think it is better to list the systems calls since it is not clear _where_ the macro is used if you just say "outgoing communications" -- is it used for bind() or connect() ? > >> known beforehand. > >> In both client and server based applications, the use of the > >> SHIM_ANY* macro accepts also non-SHIM based communications to > >> maximize backwards compatibility. > > > > The text should specify that goes into the sins_ulid field (e.g. > > zeroes) when that is the case. > > The SHIM_ANY macros is actually used to initialized that particular > field. Clarified the text. The text has some typos, and misses 'also' at the beginning. Rewrite in: An application can also use the the SHIM_ANY macro in sshim_ulid field to establish outgoing communications in Opportunistic mode [I-D.ietf-hip-base], when the application knows the remote peer locator but no ULID. Another typo: s/The SHIM_ANY* macro/The SHIM_ANY* macros/ That's it. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 13 07:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hr-Tm; Thu, 13 Sep 2007 07:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hh-Bm for hipsec@ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnB7-0001kO-Sa for hipsec@ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1200344uge for ; Thu, 13 Sep 2007 04:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cczhwW+O2YYBSz9PsushRg+eRHTp/JG6iclQCEdgC5o=; b=KYP+QzE9S4tCThRY/RNJaDJXLf7utd421idjwe+NAqm7ElcpjNGDfP32mxbQ0aGMILNb/5Rg81WrHkI6kAwQZMf++oQk/XsVfKajeof9gYqioPp1u0B79o4bROA7y9e0i2ciiKH7ydVkWdS35YqcOJxMwqjLdnNffOLkOgpMaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pO1gW9EfqICUq367nc88+b2QGTb6QRyNRftH/pkuybeDc2x4HC+UxOdVgqz84PGtl5LGoKS7q/HGYDZGn95hsgwBIWDIn6mlH/ma8G5uq/aKn8DDl6LNi8idp00ON2N9kjSuRoohCqD2sCEKhwFY+jbXaX8BpOPvaCQ0WFHJwg8= Received: by 10.67.24.18 with SMTP id b18mr499344ugj.1189684092420; Thu, 13 Sep 2007 04:48:12 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm1030286ugd.2007.09.13.04.48.10 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 04:48:11 -0700 (PDT) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Thu, 13 Sep 2007 13:48:07 +0200 User-Agent: KMail/1.9.6 References: <200709051533.34704.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709131348.07644.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, On Wednesday 12 September 2007, Miika Komu wrote: > > thanks for the review! I have addressed all of your editorial > comments in the draft. A preversion of the next version of the draft > based on your comments is in here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt I found one more problem with the definition of LSI: It is not the presentation of a public key, but rather a 32-bit handle, or descriptor. Suggest to change the definition to: LSI : Local Scope Identifier, a local, 32-bit descriptor for a given public key. > Below I have commented only the things that were unclear or need > further clarification, otherwise I applied your comments as you > suggested. I see no need to repeat minor nits here. All right. The updated draft looks good. Couple of followups below where more discussion is needed (I deleted the rest): > > SHIM and SHIM-aware are not defined in the introduction. At minimum > > I would expect the abstract text explaining the HIP focus but > > larger applicability to other SHIM layers to be duplicated here. > > Added some text to intro, I hope the changes are fine. I think that the following paragraph of the intro should also be duplicated in section 4 which specifies the API: An application can also use the new family to detect SHIM support in the local host. Namely, the application creates a socket by calling socket() function with the first argument (domain) as AF_SHIM. The system returns a positive integer representing a socket descriptor when the system supports SHIM. Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT. > > human readable names are not limited to FQDNs, unqualified DNS > > names can be used too (e.g. thanks to the 'search example.com' line > > in a /etc/resolv.conf). I'm also not sure about restricting user > > interfaces to human-readable names (e.g. FQDN), it also happens > > that IP addresses are entered in user interface, alone or embedded > > in a URL. > > I hope this is better then: > > User Interface | Hostname, FQDN or ULID relative (i.e. not fully qualified) domain name are not necessarily limited to hostname, they can be any domain name taken relative to a well known origin, or to a list of domains used as a search list. For example, when the list of domain used as a search list contains "isi.edu." and "cs.isi.edu.", the fully qualified domain name "www.cs.isi.edu." corresponds to both of these relative domain name: "www" and "www.cs". > >> We limit the description to those interfaces and data structures > >> that are either modified or completely new, because the SHIM API > >> is otherwise identical to the sockets API [POSIX]. > > > > In all API definitions that follows, it should be specified which > > header file should be included to result in the definitions (e.g. > > PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , > > or . It would also be good to have a > > section that recapitulate all new definitions at the end of the > > document. > > Added this, I hope it is ok now. I checked it, and I am questioning the location of the "shim.h" header file. My understanding is that the SHIM layer will be used in cunjunction with an internet protocol. As such, my choice would be to put the "shim.h" header file in the "netinet/" subdirectory. That is replace with . If the SHIM facility is expected to be used with network protocols other than internet ones, then I'd rather expect What do you think? > >> A client application can use the SHIM_ANY macro to establish a > > > > s/macro to establish a/macro with connect() or sendto() calls/ > > Instead of listing all the socket calls, the text now says "outgoing > communications". I hope this is ok to cover both TCP and UDP based > communication? I still think it is better to list the systems calls since it is not clear _where_ the macro is used if you just say "outgoing communications" -- is it used for bind() or connect() ? > >> known beforehand. > >> In both client and server based applications, the use of the > >> SHIM_ANY* macro accepts also non-SHIM based communications to > >> maximize backwards compatibility. > > > > The text should specify that goes into the sins_ulid field (e.g. > > zeroes) when that is the case. > > The SHIM_ANY macros is actually used to initialized that particular > field. Clarified the text. The text has some typos, and misses 'also' at the beginning. Rewrite in: An application can also use the the SHIM_ANY macro in sshim_ulid field to establish outgoing communications in Opportunistic mode [I-D.ietf-hip-base], when the application knows the remote peer locator but no ULID. Another typo: s/The SHIM_ANY* macro/The SHIM_ANY* macros/ That's it. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 13 07:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hm-OE; Thu, 13 Sep 2007 07:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hc-7O for hipsec@lists.ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnB7-0001kP-SY for hipsec@lists.ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: by ug-out-1314.google.com with SMTP id z38so371348ugc for ; Thu, 13 Sep 2007 04:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cczhwW+O2YYBSz9PsushRg+eRHTp/JG6iclQCEdgC5o=; b=KYP+QzE9S4tCThRY/RNJaDJXLf7utd421idjwe+NAqm7ElcpjNGDfP32mxbQ0aGMILNb/5Rg81WrHkI6kAwQZMf++oQk/XsVfKajeof9gYqioPp1u0B79o4bROA7y9e0i2ciiKH7ydVkWdS35YqcOJxMwqjLdnNffOLkOgpMaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pO1gW9EfqICUq367nc88+b2QGTb6QRyNRftH/pkuybeDc2x4HC+UxOdVgqz84PGtl5LGoKS7q/HGYDZGn95hsgwBIWDIn6mlH/ma8G5uq/aKn8DDl6LNi8idp00ON2N9kjSuRoohCqD2sCEKhwFY+jbXaX8BpOPvaCQ0WFHJwg8= Received: by 10.67.24.18 with SMTP id b18mr499344ugj.1189684092420; Thu, 13 Sep 2007 04:48:12 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm1030286ugd.2007.09.13.04.48.10 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 04:48:11 -0700 (PDT) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Thu, 13 Sep 2007 13:48:07 +0200 User-Agent: KMail/1.9.6 References: <200709051533.34704.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709131348.07644.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, On Wednesday 12 September 2007, Miika Komu wrote: > > thanks for the review! I have addressed all of your editorial > comments in the draft. A preversion of the next version of the draft > based on your comments is in here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt I found one more problem with the definition of LSI: It is not the presentation of a public key, but rather a 32-bit handle, or descriptor. Suggest to change the definition to: LSI : Local Scope Identifier, a local, 32-bit descriptor for a given public key. > Below I have commented only the things that were unclear or need > further clarification, otherwise I applied your comments as you > suggested. I see no need to repeat minor nits here. All right. The updated draft looks good. Couple of followups below where more discussion is needed (I deleted the rest): > > SHIM and SHIM-aware are not defined in the introduction. At minimum > > I would expect the abstract text explaining the HIP focus but > > larger applicability to other SHIM layers to be duplicated here. > > Added some text to intro, I hope the changes are fine. I think that the following paragraph of the intro should also be duplicated in section 4 which specifies the API: An application can also use the new family to detect SHIM support in the local host. Namely, the application creates a socket by calling socket() function with the first argument (domain) as AF_SHIM. The system returns a positive integer representing a socket descriptor when the system supports SHIM. Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT. > > human readable names are not limited to FQDNs, unqualified DNS > > names can be used too (e.g. thanks to the 'search example.com' line > > in a /etc/resolv.conf). I'm also not sure about restricting user > > interfaces to human-readable names (e.g. FQDN), it also happens > > that IP addresses are entered in user interface, alone or embedded > > in a URL. > > I hope this is better then: > > User Interface | Hostname, FQDN or ULID relative (i.e. not fully qualified) domain name are not necessarily limited to hostname, they can be any domain name taken relative to a well known origin, or to a list of domains used as a search list. For example, when the list of domain used as a search list contains "isi.edu." and "cs.isi.edu.", the fully qualified domain name "www.cs.isi.edu." corresponds to both of these relative domain name: "www" and "www.cs". > >> We limit the description to those interfaces and data structures > >> that are either modified or completely new, because the SHIM API > >> is otherwise identical to the sockets API [POSIX]. > > > > In all API definitions that follows, it should be specified which > > header file should be included to result in the definitions (e.g. > > PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , > > or . It would also be good to have a > > section that recapitulate all new definitions at the end of the > > document. > > Added this, I hope it is ok now. I checked it, and I am questioning the location of the "shim.h" header file. My understanding is that the SHIM layer will be used in cunjunction with an internet protocol. As such, my choice would be to put the "shim.h" header file in the "netinet/" subdirectory. That is replace with . If the SHIM facility is expected to be used with network protocols other than internet ones, then I'd rather expect What do you think? > >> A client application can use the SHIM_ANY macro to establish a > > > > s/macro to establish a/macro with connect() or sendto() calls/ > > Instead of listing all the socket calls, the text now says "outgoing > communications". I hope this is ok to cover both TCP and UDP based > communication? I still think it is better to list the systems calls since it is not clear _where_ the macro is used if you just say "outgoing communications" -- is it used for bind() or connect() ? > >> known beforehand. > >> In both client and server based applications, the use of the > >> SHIM_ANY* macro accepts also non-SHIM based communications to > >> maximize backwards compatibility. > > > > The text should specify that goes into the sins_ulid field (e.g. > > zeroes) when that is the case. > > The SHIM_ANY macros is actually used to initialized that particular > field. Clarified the text. The text has some typos, and misses 'also' at the beginning. Rewrite in: An application can also use the the SHIM_ANY macro in sshim_ulid field to establish outgoing communications in Opportunistic mode [I-D.ietf-hip-base], when the application knows the remote peer locator but no ULID. Another typo: s/The SHIM_ANY* macro/The SHIM_ANY* macros/ That's it. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 13 07:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hr-Tm; Thu, 13 Sep 2007 07:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnB9-0000Hh-Bm for hipsec@ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnB7-0001kO-Sa for hipsec@ietf.org; Thu, 13 Sep 2007 07:48:15 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1200344uge for ; Thu, 13 Sep 2007 04:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=cczhwW+O2YYBSz9PsushRg+eRHTp/JG6iclQCEdgC5o=; b=KYP+QzE9S4tCThRY/RNJaDJXLf7utd421idjwe+NAqm7ElcpjNGDfP32mxbQ0aGMILNb/5Rg81WrHkI6kAwQZMf++oQk/XsVfKajeof9gYqioPp1u0B79o4bROA7y9e0i2ciiKH7ydVkWdS35YqcOJxMwqjLdnNffOLkOgpMaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pO1gW9EfqICUq367nc88+b2QGTb6QRyNRftH/pkuybeDc2x4HC+UxOdVgqz84PGtl5LGoKS7q/HGYDZGn95hsgwBIWDIn6mlH/ma8G5uq/aKn8DDl6LNi8idp00ON2N9kjSuRoohCqD2sCEKhwFY+jbXaX8BpOPvaCQ0WFHJwg8= Received: by 10.67.24.18 with SMTP id b18mr499344ugj.1189684092420; Thu, 13 Sep 2007 04:48:12 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm1030286ugd.2007.09.13.04.48.10 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 04:48:11 -0700 (PDT) From: Julien Laganier To: hipsec@lists.ietf.org Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Thu, 13 Sep 2007 13:48:07 +0200 User-Agent: KMail/1.9.6 References: <200709051533.34704.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709131348.07644.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, On Wednesday 12 September 2007, Miika Komu wrote: > > thanks for the review! I have addressed all of your editorial > comments in the draft. A preversion of the next version of the draft > based on your comments is in here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt I found one more problem with the definition of LSI: It is not the presentation of a public key, but rather a 32-bit handle, or descriptor. Suggest to change the definition to: LSI : Local Scope Identifier, a local, 32-bit descriptor for a given public key. > Below I have commented only the things that were unclear or need > further clarification, otherwise I applied your comments as you > suggested. I see no need to repeat minor nits here. All right. The updated draft looks good. Couple of followups below where more discussion is needed (I deleted the rest): > > SHIM and SHIM-aware are not defined in the introduction. At minimum > > I would expect the abstract text explaining the HIP focus but > > larger applicability to other SHIM layers to be duplicated here. > > Added some text to intro, I hope the changes are fine. I think that the following paragraph of the intro should also be duplicated in section 4 which specifies the API: An application can also use the new family to detect SHIM support in the local host. Namely, the application creates a socket by calling socket() function with the first argument (domain) as AF_SHIM. The system returns a positive integer representing a socket descriptor when the system supports SHIM. Otherwise, the system returns -1 and sets errno to EAFNOSUPPORT. > > human readable names are not limited to FQDNs, unqualified DNS > > names can be used too (e.g. thanks to the 'search example.com' line > > in a /etc/resolv.conf). I'm also not sure about restricting user > > interfaces to human-readable names (e.g. FQDN), it also happens > > that IP addresses are entered in user interface, alone or embedded > > in a URL. > > I hope this is better then: > > User Interface | Hostname, FQDN or ULID relative (i.e. not fully qualified) domain name are not necessarily limited to hostname, they can be any domain name taken relative to a well known origin, or to a list of domains used as a search list. For example, when the list of domain used as a search list contains "isi.edu." and "cs.isi.edu.", the fully qualified domain name "www.cs.isi.edu." corresponds to both of these relative domain name: "www" and "www.cs". > >> We limit the description to those interfaces and data structures > >> that are either modified or completely new, because the SHIM API > >> is otherwise identical to the sockets API [POSIX]. > > > > In all API definitions that follows, it should be specified which > > header file should be included to result in the definitions (e.g. > > PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , > > or . It would also be good to have a > > section that recapitulate all new definitions at the end of the > > document. > > Added this, I hope it is ok now. I checked it, and I am questioning the location of the "shim.h" header file. My understanding is that the SHIM layer will be used in cunjunction with an internet protocol. As such, my choice would be to put the "shim.h" header file in the "netinet/" subdirectory. That is replace with . If the SHIM facility is expected to be used with network protocols other than internet ones, then I'd rather expect What do you think? > >> A client application can use the SHIM_ANY macro to establish a > > > > s/macro to establish a/macro with connect() or sendto() calls/ > > Instead of listing all the socket calls, the text now says "outgoing > communications". I hope this is ok to cover both TCP and UDP based > communication? I still think it is better to list the systems calls since it is not clear _where_ the macro is used if you just say "outgoing communications" -- is it used for bind() or connect() ? > >> known beforehand. > >> In both client and server based applications, the use of the > >> SHIM_ANY* macro accepts also non-SHIM based communications to > >> maximize backwards compatibility. > > > > The text should specify that goes into the sins_ulid field (e.g. > > zeroes) when that is the case. > > The SHIM_ANY macros is actually used to initialized that particular > field. Clarified the text. The text has some typos, and misses 'also' at the beginning. Rewrite in: An application can also use the the SHIM_ANY macro in sshim_ulid field to establish outgoing communications in Opportunistic mode [I-D.ietf-hip-base], when the application knows the remote peer locator but no ULID. Another typo: s/The SHIM_ANY* macro/The SHIM_ANY* macros/ That's it. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 13 08:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVngE-0001rI-3t; Thu, 13 Sep 2007 08:20:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVngC-0001r3-DV for hipsec@ietf.org; Thu, 13 Sep 2007 08:20:20 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVngB-0003U3-83 for hipsec@ietf.org; Thu, 13 Sep 2007 08:20:19 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0EFEA212D37; Thu, 13 Sep 2007 15:20:17 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C6450212D1F; Thu, 13 Sep 2007 15:20:16 +0300 (EEST) In-Reply-To: References: <46E0F5A6.1030006@nomadiclab.com> <6D50F505-BBF8-44E2-86BB-216A671F2B78@magma.ca> <46E4F119.6070104@nomadiclab.com> <3D575C97-D93F-4602-8DAB-BDB1A757BB96@magma.ca> <7A109173-3D26-484A-A049-9B7B4EB953F2@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <729BD197-2CB3-4C17-B4FE-7E716E5D7BFC@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] ICE/HIP Integration: A Solution Space Analysis Date: Thu, 13 Sep 2007 15:19:58 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: simon.schuetz@netlab.nec.de, Christian Vogt , HIPsec Mailing List , Gonzalo Camarillo X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> The ICE security analysis relies on the fact that ICE information >>> exchanged is done so in a manner that prevents an attacker from >>> eavesdropping. So I am guessing that, in order to include the >>> locator info in the R1 packet, the Initiator would need to >>> include its public key in the I1 packet, which is a (small) >>> change from the way things are done right now. Am I correct? >> >> Well, sending the public key in I1 and changing when session key >> is created would be a *major* change to HIP... > > What about the I2 and R2 packets? My understanding is that the > ENCRYPTED TLV can be included in those messages, and they can in > turn include multiple sub-attributes (such as LOCATOR). Is this > correct? Yes, that is correct, but ... >> What comes to ICE security, I'm intrigued about your claim. Where >> can I read the security analysis? > > http://tools.ietf.org/html/draft-ietf-mmusic-ice-17#section-18 ... based on my very quick skimming of the section, the issue seems to be the integrity of the messages, not their secrecy. In the current ICE solution the password is used as a (quite weak) integrity mechanism; HIP can do better. If that is true (someone please read the ICE sec cons section more thoroughly), then we can start the offer/answer already in R1 in the case where the responder's offer is independent of the initiator. On the other hand, when the responder's locator set is initiator- dependent, we have to defer the start of the exchange until I2. In neither case you should need to use ENCRYPTED. The existing integrity checks (SIG/HMAC) should suffice, if I understand the situation correctly. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 15 07:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVOp-0003pq-UR; Sat, 15 Sep 2007 07:01:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVOp-0003pj-4f for hipsec@ietf.org; Sat, 15 Sep 2007 07:01:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWVOo-0000Of-JT for hipsec@ietf.org; Sat, 15 Sep 2007 07:01:18 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0BF8720724; Sat, 15 Sep 2007 13:01:18 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-6b-46ebbb7ec1e3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F3FA42010F; Sat, 15 Sep 2007 13:01:17 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 13:01:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 13:01:17 +0200 Received: from [131.160.126.213] (rvi2-126-213.lmf.ericsson.se [131.160.126.213]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 017102466; Sat, 15 Sep 2007 14:01:16 +0300 (EEST) Message-ID: <46EBBB7B.8080100@ericsson.com> Date: Sat, 15 Sep 2007 14:01:15 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2007 11:01:17.0213 (UTC) FILETIME=[BD4FFCD0:01C7F787] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] Meeting in Vancouver X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we have not met face-to-face for a while already. I believe it is time to have a face-to-face meeting in order to discuss our current WG items. So, I intend to request a slot for the HIP WG in Vancouver. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 15 07:04:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVRp-00064D-Qs; Sat, 15 Sep 2007 07:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVRo-000648-94 for hipsec@ietf.org; Sat, 15 Sep 2007 07:04:24 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWVRm-0004IT-Fs for hipsec@ietf.org; Sat, 15 Sep 2007 07:04:24 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id XAA03313; Sat, 15 Sep 2007 23:04:18 +1200 In-Reply-To: <46EBBB7B.8080100@ericsson.com> References: <46EBBB7B.8080100@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F3568E2-976B-4733-A0DE-E95C4596C2CE@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] Meeting in Vancouver Date: Sat, 15 Sep 2007 23:04:14 +1200 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Good idea. I think we need a discussion on NAT traversal. Andrew On 15/09/2007, at 11:01 PM, Gonzalo Camarillo wrote: > Folks, > > we have not met face-to-face for a while already. I believe it is > time to have a face-to-face meeting in order to discuss our current > WG items. So, I intend to request a slot for the HIP WG in Vancouver. > > Cheers, > > Gonzalo > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 15 09:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXpm-0000hV-Nd; Sat, 15 Sep 2007 09:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWXpl-0000gd-BG for hipsec@ietf.org; Sat, 15 Sep 2007 09:37:17 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWXpj-0000dT-Sk for hipsec@ietf.org; Sat, 15 Sep 2007 09:37:17 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 30F132CD6; Sat, 15 Sep 2007 16:37:15 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 34F582C40; Sat, 15 Sep 2007 16:37:08 +0300 (EEST) Date: Sat, 15 Sep 2007 16:37:08 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Andrew McGregor Subject: Re: [Hipsec] Meeting in Vancouver In-Reply-To: <1F3568E2-976B-4733-A0DE-E95C4596C2CE@indranet.co.nz> Message-ID: References: <46EBBB7B.8080100@ericsson.com> <1F3568E2-976B-4733-A0DE-E95C4596C2CE@indranet.co.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Sat, 15 Sep 2007, Andrew McGregor wrote: Hi, agree. I think it would hurt to have a slot for the API work either. > Good idea. I think we need a discussion on NAT traversal. > > Andrew > > On 15/09/2007, at 11:01 PM, Gonzalo Camarillo wrote: > >> Folks, >> >> we have not met face-to-face for a while already. I believe it is time to >> have a face-to-face meeting in order to discuss our current WG items. So, I >> intend to request a slot for the HIP WG in Vancouver. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Sep 15 10:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYhN-0005rp-Jz; Sat, 15 Sep 2007 10:32:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYhM-0005rf-Eh for hipsec@ietf.org; Sat, 15 Sep 2007 10:32:40 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWYhL-0008Af-Vk for hipsec@ietf.org; Sat, 15 Sep 2007 10:32:40 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89CE62077A; Sat, 15 Sep 2007 16:32:38 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-98-46ebed06593e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C55E20639; Sat, 15 Sep 2007 16:32:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 16:32:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Sep 2007 16:32:36 +0200 Received: from [131.160.126.213] (rvi2-126-213.lmf.ericsson.se [131.160.126.213]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A5D682466; Sat, 15 Sep 2007 17:32:36 +0300 (EEST) Message-ID: <46EBED04.8000701@ericsson.com> Date: Sat, 15 Sep 2007 17:32:36 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Meeting in Vancouver References: <46EBBB7B.8080100@ericsson.com> <1F3568E2-976B-4733-A0DE-E95C4596C2CE@indranet.co.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2007 14:32:36.0547 (UTC) FILETIME=[42C8D130:01C7F7A5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, > agree. I think it would hurt to have a slot for the API work either. I assume you mean that it would *not* hurt, right? :o) Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 16 15:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWzux-0004mJ-4h; Sun, 16 Sep 2007 15:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWzuw-0004m7-80 for hipsec@lists.ietf.org; Sun, 16 Sep 2007 15:36:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWzuu-0002MS-Kr for hipsec@lists.ietf.org; Sun, 16 Sep 2007 15:36:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A42D52C84; Sun, 16 Sep 2007 22:36:27 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5BD472C3A; Sun, 16 Sep 2007 22:36:19 +0300 (EEST) Date: Sun, 16 Sep 2007 22:36:19 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709131348.07644.julien.IETF@laposte.net> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <200709131348.07644.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: 'HIP WG' , hipsec@lists.ietf.org, draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 13 Sep 2007, Julien Laganier wrote: Hi Julien, new version based on your comments is available here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt > Hi Miika, > > On Wednesday 12 September 2007, Miika Komu wrote: >> >> thanks for the review! I have addressed all of your editorial >> comments in the draft. A preversion of the next version of the draft >> based on your comments is in here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt > > I found one more problem with the definition of LSI: It is not the > presentation of a public key, but rather a 32-bit handle, or > descriptor. Suggest to change the definition to: > > LSI : Local Scope Identifier, a local, 32-bit descriptor for a given > public key. Ok. >>> SHIM and SHIM-aware are not defined in the introduction. At minimum >>> I would expect the abstract text explaining the HIP focus but >>> larger applicability to other SHIM layers to be duplicated here. >> >> Added some text to intro, I hope the changes are fine. > > I think that the following paragraph of the intro should also be > duplicated in section 4 which specifies the API: > > An application can also use the new family to detect SHIM support in > the local host. Namely, the application creates a socket by calling > socket() function with the first argument (domain) as AF_SHIM. The > system returns a positive integer representing a socket descriptor > when the system supports SHIM. Otherwise, the system returns -1 and > sets errno to EAFNOSUPPORT. Added. >>> human readable names are not limited to FQDNs, unqualified DNS >>> names can be used too (e.g. thanks to the 'search example.com' line >>> in a /etc/resolv.conf). I'm also not sure about restricting user >>> interfaces to human-readable names (e.g. FQDN), it also happens >>> that IP addresses are entered in user interface, alone or embedded >>> in a URL. >> >> I hope this is better then: >> >> User Interface | Hostname, FQDN or ULID > > relative (i.e. not fully qualified) domain name are not necessarily > limited to hostname, they can be any domain name taken relative to a > well known origin, or to a list of domains used as a search list. For > example, when the list of domain used as a search list > contains "isi.edu." and "cs.isi.edu.", the fully qualified domain > name "www.cs.isi.edu." corresponds to both of these relative domain > name: "www" and "www.cs". Please make a concrete suggestion on what to change? I think this not very important for the draft. >>>> We limit the description to those interfaces and data structures >>>> that are either modified or completely new, because the SHIM API >>>> is otherwise identical to the sockets API [POSIX]. >>> >>> In all API definitions that follows, it should be specified which >>> header file should be included to result in the definitions (e.g. >>> PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , >>> or . It would also be good to have a >>> section that recapitulate all new definitions at the end of the >>> document. >> >> Added this, I hope it is ok now. > > I checked it, and I am questioning the location of the "shim.h" header > file. My understanding is that the SHIM layer will be used in > cunjunction with an internet protocol. As such, my choice would be to > put the "shim.h" header file in the "netinet/" subdirectory. That is > replace with . > > If the SHIM facility is expected to be used with network protocols other > than internet ones, then I'd rather expect > > What do you think? Changed it to . >>>> A client application can use the SHIM_ANY macro to establish a >>> >>> s/macro to establish a/macro with connect() or sendto() calls/ >> >> Instead of listing all the socket calls, the text now says "outgoing >> communications". I hope this is ok to cover both TCP and UDP based >> communication? > > I still think it is better to list the systems calls since it is not > clear _where_ the macro is used if you just say "outgoing > communications" -- is it used for bind() or connect() ? Ok, added the examples. >>>> known beforehand. >>>> In both client and server based applications, the use of the >>>> SHIM_ANY* macro accepts also non-SHIM based communications to >>>> maximize backwards compatibility. >>> >>> The text should specify that goes into the sins_ulid field (e.g. >>> zeroes) when that is the case. >> >> The SHIM_ANY macros is actually used to initialized that particular >> field. Clarified the text. > > The text has some typos, and misses 'also' at the beginning. Rewrite in: > > An application can also use the the SHIM_ANY macro in sshim_ulid > field to establish outgoing communications in Opportunistic mode > [I-D.ietf-hip-base], when the application knows the remote peer > locator but no ULID. > > Another typo: > > s/The SHIM_ANY* macro/The SHIM_ANY* macros/ > > That's it. Changed. Thanks for your feedback! -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 16 15:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWzuw-0004mC-Uh; Sun, 16 Sep 2007 15:36:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWzuv-0004m1-LZ for hipsec@ietf.org; Sun, 16 Sep 2007 15:36:29 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWzuu-00033N-QV for hipsec@ietf.org; Sun, 16 Sep 2007 15:36:29 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A42D52C84; Sun, 16 Sep 2007 22:36:27 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5BD472C3A; Sun, 16 Sep 2007 22:36:19 +0300 (EEST) Date: Sun, 16 Sep 2007 22:36:19 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709131348.07644.julien.IETF@laposte.net> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <200709131348.07644.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: 'HIP WG' , hipsec@lists.ietf.org, draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 13 Sep 2007, Julien Laganier wrote: Hi Julien, new version based on your comments is available here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt > Hi Miika, > > On Wednesday 12 September 2007, Miika Komu wrote: >> >> thanks for the review! I have addressed all of your editorial >> comments in the draft. A preversion of the next version of the draft >> based on your comments is in here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt > > I found one more problem with the definition of LSI: It is not the > presentation of a public key, but rather a 32-bit handle, or > descriptor. Suggest to change the definition to: > > LSI : Local Scope Identifier, a local, 32-bit descriptor for a given > public key. Ok. >>> SHIM and SHIM-aware are not defined in the introduction. At minimum >>> I would expect the abstract text explaining the HIP focus but >>> larger applicability to other SHIM layers to be duplicated here. >> >> Added some text to intro, I hope the changes are fine. > > I think that the following paragraph of the intro should also be > duplicated in section 4 which specifies the API: > > An application can also use the new family to detect SHIM support in > the local host. Namely, the application creates a socket by calling > socket() function with the first argument (domain) as AF_SHIM. The > system returns a positive integer representing a socket descriptor > when the system supports SHIM. Otherwise, the system returns -1 and > sets errno to EAFNOSUPPORT. Added. >>> human readable names are not limited to FQDNs, unqualified DNS >>> names can be used too (e.g. thanks to the 'search example.com' line >>> in a /etc/resolv.conf). I'm also not sure about restricting user >>> interfaces to human-readable names (e.g. FQDN), it also happens >>> that IP addresses are entered in user interface, alone or embedded >>> in a URL. >> >> I hope this is better then: >> >> User Interface | Hostname, FQDN or ULID > > relative (i.e. not fully qualified) domain name are not necessarily > limited to hostname, they can be any domain name taken relative to a > well known origin, or to a list of domains used as a search list. For > example, when the list of domain used as a search list > contains "isi.edu." and "cs.isi.edu.", the fully qualified domain > name "www.cs.isi.edu." corresponds to both of these relative domain > name: "www" and "www.cs". Please make a concrete suggestion on what to change? I think this not very important for the draft. >>>> We limit the description to those interfaces and data structures >>>> that are either modified or completely new, because the SHIM API >>>> is otherwise identical to the sockets API [POSIX]. >>> >>> In all API definitions that follows, it should be specified which >>> header file should be included to result in the definitions (e.g. >>> PF_SHIM, AF_SHIM, sockaddr_shim), e.g. , >>> or . It would also be good to have a >>> section that recapitulate all new definitions at the end of the >>> document. >> >> Added this, I hope it is ok now. > > I checked it, and I am questioning the location of the "shim.h" header > file. My understanding is that the SHIM layer will be used in > cunjunction with an internet protocol. As such, my choice would be to > put the "shim.h" header file in the "netinet/" subdirectory. That is > replace with . > > If the SHIM facility is expected to be used with network protocols other > than internet ones, then I'd rather expect > > What do you think? Changed it to . >>>> A client application can use the SHIM_ANY macro to establish a >>> >>> s/macro to establish a/macro with connect() or sendto() calls/ >> >> Instead of listing all the socket calls, the text now says "outgoing >> communications". I hope this is ok to cover both TCP and UDP based >> communication? > > I still think it is better to list the systems calls since it is not > clear _where_ the macro is used if you just say "outgoing > communications" -- is it used for bind() or connect() ? Ok, added the examples. >>>> known beforehand. >>>> In both client and server based applications, the use of the >>>> SHIM_ANY* macro accepts also non-SHIM based communications to >>>> maximize backwards compatibility. >>> >>> The text should specify that goes into the sins_ulid field (e.g. >>> zeroes) when that is the case. >> >> The SHIM_ANY macros is actually used to initialized that particular >> field. Clarified the text. > > The text has some typos, and misses 'also' at the beginning. Rewrite in: > > An application can also use the the SHIM_ANY macro in sshim_ulid > field to establish outgoing communications in Opportunistic mode > [I-D.ietf-hip-base], when the application knows the remote peer > locator but no ULID. > > Another typo: > > s/The SHIM_ANY* macro/The SHIM_ANY* macros/ > > That's it. Changed. Thanks for your feedback! -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 16 16:05:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX0Mr-0005wU-SW; Sun, 16 Sep 2007 16:05:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX0Mq-0005wK-HI for hipsec@ietf.org; Sun, 16 Sep 2007 16:05:20 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX0Mq-0003nP-2r for hipsec@ietf.org; Sun, 16 Sep 2007 16:05:20 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 950D52CE0; Sun, 16 Sep 2007 23:05:19 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 691682CCC; Sun, 16 Sep 2007 23:05:07 +0300 (EEST) Date: Sun, 16 Sep 2007 23:05:07 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709131348.07644.julien.IETF@laposte.net> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <200709131348.07644.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'HIP WG' , hipsec@lists.ietf.org, draft-ietf-hip-native-api@tools.ietf.org, Marcelo Bagnulo Braun X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 13 Sep 2007, Julien Laganier wrote: Hi folks, as you know the HIP-related API standards have been split into three different working groups: * BTNS WG draft describes how to get/set ipsec related attributes and how to control channel bindings in an IPsec-aware application: http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt * SHIM6 WG draft explains how to get/set multihoming related attributes (such as locator management) in a SHIM6/HIP aware application: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt * HIP WG draft describes initial identity-locator discovery and the use of opportunistic mode in a HIP-aware application: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt I got feedback from Shinta who is the editor of the SHIM6 API draft. Below is a summary of the discussion so far: * The name of the native HIP API draft is not very descriptive anymore? I suggested "Sockets API Extensions for Initial Discovery and Management of SHIM Layer Identifier-locator Bindings", since SHIM6 draft already takes care of locator bindings especially after the initial contact. Please suggest if you can think of some better name. * Is the native API draft useful for SHIM6 at all? I am looking for more feedback on this, but I have the following use case in my mind: an application that is both HIP and SHIM6 aware. Even though the native HIP API draft is not very useful for SHIM6, we should guarantee interoperability between the two protocols at the API level. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 16 16:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX0Mt-0005xg-1Z; Sun, 16 Sep 2007 16:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX0Mr-0005wP-Od for hipsec@lists.ietf.org; Sun, 16 Sep 2007 16:05:21 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX0Mq-00033U-2I for hipsec@lists.ietf.org; Sun, 16 Sep 2007 16:05:21 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 950D52CE0; Sun, 16 Sep 2007 23:05:19 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 691682CCC; Sun, 16 Sep 2007 23:05:07 +0300 (EEST) Date: Sun, 16 Sep 2007 23:05:07 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709131348.07644.julien.IETF@laposte.net> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <200709131348.07644.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'HIP WG' , hipsec@lists.ietf.org, draft-ietf-hip-native-api@tools.ietf.org, Marcelo Bagnulo Braun X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 13 Sep 2007, Julien Laganier wrote: Hi folks, as you know the HIP-related API standards have been split into three different working groups: * BTNS WG draft describes how to get/set ipsec related attributes and how to control channel bindings in an IPsec-aware application: http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt * SHIM6 WG draft explains how to get/set multihoming related attributes (such as locator management) in a SHIM6/HIP aware application: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt * HIP WG draft describes initial identity-locator discovery and the use of opportunistic mode in a HIP-aware application: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt I got feedback from Shinta who is the editor of the SHIM6 API draft. Below is a summary of the discussion so far: * The name of the native HIP API draft is not very descriptive anymore? I suggested "Sockets API Extensions for Initial Discovery and Management of SHIM Layer Identifier-locator Bindings", since SHIM6 draft already takes care of locator bindings especially after the initial contact. Please suggest if you can think of some better name. * Is the native API draft useful for SHIM6 at all? I am looking for more feedback on this, but I have the following use case in my mind: an application that is both HIP and SHIM6 aware. Even though the native HIP API draft is not very useful for SHIM6, we should guarantee interoperability between the two protocols at the API level. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 04:49:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCIC-00047n-Mt; Mon, 17 Sep 2007 04:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCIA-00047h-T0 for hipsec@ietf.org; Mon, 17 Sep 2007 04:49:18 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCI9-0004uG-5n for hipsec@ietf.org; Mon, 17 Sep 2007 04:49:18 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 04D7F212D1F; Mon, 17 Sep 2007 11:49:16 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 77A6F212C54; Mon, 17 Sep 2007 11:49:14 +0300 (EEST) Message-ID: <46EE3F84.1080504@nomadiclab.com> Date: Mon, 17 Sep 2007 11:49:08 +0300 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt References: <200709051533.34704.julien.IETF@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hello, Question regarding section 4.1. Socket Family and Address Structure. Why there is sshim_locator in the sockaddr_shim? struct sockaddr_shim { uint8_t sshim_len; uint8_t sshim_family; uint16_t sshim_port; shim_ulid_t sshim_ulid; shim_locator_t sshim_locator; uint64_t sshim_flags; } IMHO it is not needed as the connection to peer is bound to ULID not locator and the peer might have more than one locator which means that you are not anyway providing full set of locators to the socket. Furthermore in section 3.3 the resolver is supposed to deliver both ULIDs and locators to the SHIM layer. Jan Miika Komu wrote: > On Wed, 5 Sep 2007, Julien Laganier wrote: > > Julien, > >> I have reviewed draft-ietf-hip-native-api-02.txt, and I think the >> documents is in good shape. >> >> I have however a couple of comments and suggested changes below that I >> would like to see addressed before the document is sent to IESG for >> publication. > > thanks for the review! I have addressed all of your editorial comments > in the draft. A preversion of the next version of the draft based on > your comments is in here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt > >> I had no time to distinguish between editorial and technical ones, >> sorry. > > No problem. > > Below I have commented only the things that were unclear or need > further clarification, otherwise I applied your comments as you > suggested. I see no need to repeat minor nits here. > >> SHIM and SHIM-aware are not defined in the introduction. At minimum I >> would expect the abstract text explaining the HIP focus but larger >> applicability to other SHIM layers to be duplicated here. > > Added some text to intro, I hope the changes are fine. > >> Also, if we talk about address family, shouldn't we use AF_SHIM instead >> of PF_SHIM? > > In practice, there is no difference between AF and PF. Added text: > > The API extensions introduce a new address family, AF_SHIM, and a new > socket address structure for sockets using explicit identifier- > locator bindings. PF_SHIM is used as an alias for AF_SHIM in this > document because the distinction between PF and AF has been lost in > the practice. > >> Also, is "initiate outgoing communications without knowledge of the peer >> identity" opportunistic mode? If yes it should be spelled out. I don't >> see how it is possible to accept a HIP incoming communication without >> knowledge of the peer identity since identity will be in I2... Maybe >> you refer to initiate outgoing communications without knowing the local >> identity? >> >>> This document describes also how to address this situation using late >>> binding based on new wildcards. >> >> 'late binding' is not defined. We can't expect anyone to understand what >> it means. > > Removed 'late binding' since it was not really used elsewhere in the > text. Changed the 'initiate outgoing' text to this: > > Some applications may accept incoming communications from any > identifier. Other applications may initiate outgoing communications > without knowledge of the peer identifier in Opportunistic Mode > [I-D.ietf-hip-base] by just relying on a peer locator. This document > describes how to address both situations using "wildcards" described > in a later section. > >>> There are two related IETF documents that are define other related >>> API extensions. Multihoming related APIs are defined in >>> [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy >>> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] >> >> I disagree with the use of 'other related API extensions' in this >> context. While this document does indeed defines extensions to the >> socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api]. > > Changed to: > > There are two related API documents. Multihoming related APIs are > defined in [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy > attributes and channel bindings are defined in [I-D.ietf-btns-c-api] > >> human readable names are not limited to FQDNs, unqualified DNS names can >> be used too (e.g. thanks to the 'search example.com' line in >> a /etc/resolv.conf). I'm also not sure about restricting user >> interfaces to human-readable names (e.g. FQDN), it also happens that IP >> addresses are entered in user interface, alone or embedded in a URL. > > I hope this is better then: > > User Interface | Hostname, FQDN or ULID > >>> We limit the description to those interfaces and data structures that >>> are either modified or completely new, because the SHIM API is >>> otherwise identical to the sockets API [POSIX]. >> >> In all API definitions that follows, it should be specified which header >> file should be included to result in the definitions (e.g. PF_SHIM, >> AF_SHIM, sockaddr_shim), e.g. , or >> . It would also be good to have a section that recapitulate >> all new definitions at the end of the document. > > Added this, I hope it is ok now. > >>> The application usually sets the sins_ulid field using the >>> resolver. However, three special macros can be used to directly set a >>> value into the sins_ulid field. The macros are SHIM_ANY, >>> SHIM_ANY_PUB and SHIM_ANY_ANON. They denote an ULID value associated >>> with a wildcard ULID of any, public, or anonymous type. >> >> I miss the definition of these different ULID types (public vs. >> anonymous). I think we need some more text or a reference to another >> document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 >> ULID's). > > Added the reference as you suggested and added a reference HIP > architecture RFC as well regarding to the anonymous bit. I hope this > is ok? We could also removed the ANON and PUB altogether (I am > referring to the discussion of Pekka and Philip on the anonymity topic). > >> I'm not sure about the restriction to one host binding on a given port. >> There are TCP/IP stacks that allows binding multiple processes to bind >> to same addresses and/or ports through the use of the appropriate >> socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite >> them here, or remove the above restriction. > > Removed. > >>> A client application can use the SHIM_ANY macro to establish a >> >> s/macro to establish a/macro with connect() or sendto() calls/ > > Instead of listing all the socket calls, the text now says "outgoing > communications". I hope this is ok to cover both TCP and UDP based > communication? > >>> known beforehand. >>> In both client and server based applications, the use of the >>> SHIM_ANY* macro accepts also non-SHIM based communications to >>> maximize backwards compatibility. >> >> The text should specify that goes into the sins_ulid field (e.g. zeroes) >> when that is the case. > > The SHIM_ANY macros is actually used to initialized that particular > field. Clarified the text. > >> >>> When the application wants >>> enforces the use of SHIM-based communications with ORCHID prefix >>> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >>> Alternatively, the application accepts both ORCHID and non-ORCHID- >>> based communications, but informs the difference e.g. to the user. >>> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >> >> How about SHIM_IS_IPV6_ADDR_ORCHID instead? > > Agreed. > >>> The flag AI_SHIM must be set, or otherwise the resolver does not >>> return sockaddr_shim data structures to guarantee that legacy >>> applications do not break. >> >> But presumably legacy applications would not set ai_family to PF_SHIM, >> so the AI_SHIM flags seems redundant. >> >> .. >>> The protocol field is 0 when the getaddrinfo caller does not care >>> about the specific SHIM protocol to be used. The caller (or the >>> resolver) can set this field also to IPPROTO_HIP. >> >> .. >> >> Since this API is supposed to be usable for multiple SHIM protocols >> (e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in >> use I'd think that the caller MUST set the protocol field to the >> constant identifying the protocol in use (e.g. IPPROTO_HIP, >> IPPROTO_SHIM6). > > Removed the statement on removing legacy applications. I think the > AI_SHIM flag is still necessary. The protocol field can be set to zero > even with SHIM-aware applications when the application does not care > which particular SHIM protocol it is riding on. In such a case, a > separate flag is needed. > >>> Some applications may prefer >>> configuring the locators manually and can set the AI_SHIM_NOLOCATORS >>> flag to prohibit the getaddrinfo from resolving any locators. >>> >>> The ai_family field is PF_SHIM with SHIM-specific addrinfo data >>> structures. >> >> What is the "SHIM-specific addrinfo data structures" ? do you mean an >> addrinfo data structure with an ai_addr pointing to a sockaddr_shim >> data structure? > > Yes, corrected. > >>> ai_addrlen is the size of the structure pointed by ai_addr. >> >> This is already specified as part of RFC3493. No need to duplicate that >> information here. > > I think it is more reader-friendly to go through all of the fields > one-by-one and describe how they are affected by the draft. Added some > clarifications: > > ai_addrlen is the size of the structure pointed by ai_addr. This > equals to sizeof(struct sockaddr_shim) when when ai_family field is > PF_SHIM. > >>> The output argument res is dynamically allocated by the resolver. >>> The application must free res argument with the free_addrinfo >>> function. >> >> We do not need to specify that here, that's orthogonal to the discussion >> we're having IMO. > > I think it is useful to recap here how the resolver works. Changed the > text to: > > The output argument res is dynamically allocated by the resolver. > The application frees res argument with the free_addrinfo function. > The res argument contains a linked list of the resolved endpoints. > The linked list contains sockaddr_shim structures only when the input > argument has the AI_SHIM flag set. When the resolver finds SHIM > identifiers, it inserts them to the front of the list. SHIM > identifiers for different protocols are sorted according to local > policies. Non-SHIM identifiers are present only when ai_protocol is > set zero in the hints arguments of getaddrinfo() or the hints > argument is NULL. The non-SHIM identifiers are placed after SHIM > identifiers. > > Notice: I added text that sorting e.g. between HIP vs. SHIM6 > identifiers is a local policy issue. > >>> The res argument contains a linked list of the resolved >>> endpoints. The linked list contains sockaddr_shim structures only >>> when the input argument has the AI_SHIM flag set. When the >>> resolver finds SHIM identifiers, it inserts them to the front of the >>> list. >> >> This seems to imply that the resolver may also return non-SHIM sockaddr >> structures (e.g. sockaddr_in6) at the tail of the list. That should be >> made explicit. > > Done. > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 06:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXE7R-0003t9-K7; Mon, 17 Sep 2007 06:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXE7R-0003t2-3b for hipsec@ietf.org; Mon, 17 Sep 2007 06:46:21 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXE7P-0008PG-GQ for hipsec@ietf.org; Mon, 17 Sep 2007 06:46:21 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E7609198690; Mon, 17 Sep 2007 13:46:17 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9DD95198646; Mon, 17 Sep 2007 13:46:17 +0300 (EEST) Message-ID: <46EE5AF9.4070706@piuha.net> Date: Mon, 17 Sep 2007 13:46:17 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: draft-ietf-hip-native-api@tools.ietf.org, HIP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Hipsec] review of draft-ietf-hip-native-api-02 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I happened to read this draft. A few comments: In general, I'd like to see work like this move forward. The main question mark that I had relates to the positioning of this work as a generic Shim layer API vs. HIP-only API. I think a generic API would be useful, but I'm uncertain if the API as defined is a good fit for non-HIP designs, most notably the Shim6 design. But I'm sure you have talked about this in the past. Can you post pointers to such discussion? Anyway, what I see problematic from the point of using for Shim6 is the following: - The resolution step does not distinguish ULIDs from locators. - Section 4.1 ULID comparison for Shim6 may produce surprising results, given that different connection attempts may result in different ULIDs. - I'm not sure how the deferred context creation approach in Shim6 fits with this API. What's the role of this spec vs. the shim6 draft that you have? Other comments: > | Locator | Non-routable IPv4 or IPv6 address used at the lower | > | | layers | I'm pretty sure you meant routable. > In practise, the resolver functionality can implemented in different s/can/can be/ > They denote an ULID value associated with a wildcard > ULID of any, public, or anonymous type. I do not understand the difference. Please elaborate. > In both client and server based applications, the use of the > SHIM_ANY* macro accepts also non-SHIM based communications to > maximize backwards compatibility. When the application wants > enforces the use of SHIM-based communications with ORCHID prefix > [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. > Alternatively, the application accepts both ORCHID and non-ORCHID- > based communications, but informs the difference e.g. to the user. > In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro > which inputs a pointer to a in6_addr and returns 1 when the address > has orchid prefix and 0 otherwise. Is the use of Orchids the same or different issue from using a Shim? I.e., do all Shims employ an Orchid? And if not, wouldn't you want to enable/disable the use of non-shim communications and Orchids separately? Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 07:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXF6M-00033S-Io; Mon, 17 Sep 2007 07:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXF6J-00033H-Rv for hipsec@ietf.org; Mon, 17 Sep 2007 07:49:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXF6I-0001rf-3i for hipsec@ietf.org; Mon, 17 Sep 2007 07:49:15 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 851FF2C72; Mon, 17 Sep 2007 14:49:13 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1A5FD2C72; Mon, 17 Sep 2007 14:49:06 +0300 (EEST) Date: Mon, 17 Sep 2007 14:49:06 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <46EE3F84.1080504@nomadiclab.com> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Jan Mikael Melen wrote: Hi, ulid is the HIT and locator is a routable address (IPv4 or IPv6). The legacy API draft discusses in detail the case where only HITs are given to a non-HIP aware application. Due to constraints in the resolver API and size of sockaddr structures, the returned data structures may contain some redundancy. Particularly, the resolver returns n * m sockaddr_shim data structures when the resolution results in n HITs and m locators. Returning multiple locators within a single sockaddr structure is possible, but the sockaddr structure size is limited and we have to have some redundancy anyway. The resolution procedure also considers mostly *initial* address look-up from DNS. The hosts are free to communicate additional locators in the base exchange or using UPDATE. On the other hand, multiple locators in a single structure might speed-up the HIP connection establishment when the base exchange is parallerized. However, some applications parallize connections already at the application layer. I have no strong opinion on this. We can fit easily fit 10 in6_addr locator structures into sockaddr_shim. Opinions? > Hello, > > Question regarding section 4.1. Socket Family and Address Structure. Why > there is sshim_locator in the sockaddr_shim? > struct sockaddr_shim { > uint8_t sshim_len; > uint8_t sshim_family; > uint16_t sshim_port; > shim_ulid_t sshim_ulid; > shim_locator_t sshim_locator; > uint64_t sshim_flags; > } > > IMHO it is not needed as the connection to peer is bound to ULID not locator > and the peer might have more than one locator which means that you are not > anyway providing full set of locators to the socket. Furthermore in section > 3.3 the resolver is supposed to deliver both ULIDs and locators to the SHIM > layer. > > Jan > > > Miika Komu wrote: >> On Wed, 5 Sep 2007, Julien Laganier wrote: >> >> Julien, >> >>> I have reviewed draft-ietf-hip-native-api-02.txt, and I think the >>> documents is in good shape. >>> >>> I have however a couple of comments and suggested changes below that I >>> would like to see addressed before the document is sent to IESG for >>> publication. >> >> thanks for the review! I have addressed all of your editorial comments in >> the draft. A preversion of the next version of the draft based on your >> comments is in here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt >> >>> I had no time to distinguish between editorial and technical ones, >>> sorry. >> >> No problem. >> >> Below I have commented only the things that were unclear or need further >> clarification, otherwise I applied your comments as you suggested. I see no >> need to repeat minor nits here. >> >>> SHIM and SHIM-aware are not defined in the introduction. At minimum I >>> would expect the abstract text explaining the HIP focus but larger >>> applicability to other SHIM layers to be duplicated here. >> >> Added some text to intro, I hope the changes are fine. >> >>> Also, if we talk about address family, shouldn't we use AF_SHIM instead >>> of PF_SHIM? >> >> In practice, there is no difference between AF and PF. Added text: >> >> The API extensions introduce a new address family, AF_SHIM, and a new >> socket address structure for sockets using explicit identifier- >> locator bindings. PF_SHIM is used as an alias for AF_SHIM in this >> document because the distinction between PF and AF has been lost in >> the practice. >> >>> Also, is "initiate outgoing communications without knowledge of the peer >>> identity" opportunistic mode? If yes it should be spelled out. I don't >>> see how it is possible to accept a HIP incoming communication without >>> knowledge of the peer identity since identity will be in I2... Maybe >>> you refer to initiate outgoing communications without knowing the local >>> identity? >>> >>>> This document describes also how to address this situation using late >>>> binding based on new wildcards. >>> >>> 'late binding' is not defined. We can't expect anyone to understand what >>> it means. >> >> Removed 'late binding' since it was not really used elsewhere in the text. >> Changed the 'initiate outgoing' text to this: >> >> Some applications may accept incoming communications from any >> identifier. Other applications may initiate outgoing communications >> without knowledge of the peer identifier in Opportunistic Mode >> [I-D.ietf-hip-base] by just relying on a peer locator. This document >> describes how to address both situations using "wildcards" described >> in a later section. >> >>>> There are two related IETF documents that are define other related >>>> API extensions. Multihoming related APIs are defined in >>>> [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy >>>> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] >>> >>> I disagree with the use of 'other related API extensions' in this >>> context. While this document does indeed defines extensions to the >>> socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api]. >> >> Changed to: >> >> There are two related API documents. Multihoming related APIs are >> defined in [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy >> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] >> >>> human readable names are not limited to FQDNs, unqualified DNS names can >>> be used too (e.g. thanks to the 'search example.com' line in >>> a /etc/resolv.conf). I'm also not sure about restricting user >>> interfaces to human-readable names (e.g. FQDN), it also happens that IP >>> addresses are entered in user interface, alone or embedded in a URL. >> >> I hope this is better then: >> >> User Interface | Hostname, FQDN or ULID >> >>>> We limit the description to those interfaces and data structures that >>>> are either modified or completely new, because the SHIM API is >>>> otherwise identical to the sockets API [POSIX]. >>> >>> In all API definitions that follows, it should be specified which header >>> file should be included to result in the definitions (e.g. PF_SHIM, >>> AF_SHIM, sockaddr_shim), e.g. , or >>> . It would also be good to have a section that recapitulate >>> all new definitions at the end of the document. >> >> Added this, I hope it is ok now. >> >>>> The application usually sets the sins_ulid field using the >>>> resolver. However, three special macros can be used to directly set a >>>> value into the sins_ulid field. The macros are SHIM_ANY, >>>> SHIM_ANY_PUB and SHIM_ANY_ANON. They denote an ULID value associated >>>> with a wildcard ULID of any, public, or anonymous type. >>> >>> I miss the definition of these different ULID types (public vs. >>> anonymous). I think we need some more text or a reference to another >>> document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 >>> ULID's). >> >> Added the reference as you suggested and added a reference HIP architecture >> RFC as well regarding to the anonymous bit. I hope this is ok? We could >> also removed the ANON and PUB altogether (I am referring to the discussion >> of Pekka and Philip on the anonymity topic). >> >>> I'm not sure about the restriction to one host binding on a given port. >>> There are TCP/IP stacks that allows binding multiple processes to bind >>> to same addresses and/or ports through the use of the appropriate >>> socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite >>> them here, or remove the above restriction. >> >> Removed. >> >>>> A client application can use the SHIM_ANY macro to establish a >>> >>> s/macro to establish a/macro with connect() or sendto() calls/ >> >> Instead of listing all the socket calls, the text now says "outgoing >> communications". I hope this is ok to cover both TCP and UDP based >> communication? >> >>>> known beforehand. >>>> In both client and server based applications, the use of the >>>> SHIM_ANY* macro accepts also non-SHIM based communications to >>>> maximize backwards compatibility. >>> >>> The text should specify that goes into the sins_ulid field (e.g. zeroes) >>> when that is the case. >> >> The SHIM_ANY macros is actually used to initialized that particular field. >> Clarified the text. >> >>> >>>> When the application wants >>>> enforces the use of SHIM-based communications with ORCHID prefix >>>> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >>>> Alternatively, the application accepts both ORCHID and non-ORCHID- >>>> based communications, but informs the difference e.g. to the user. >>>> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >>> >>> How about SHIM_IS_IPV6_ADDR_ORCHID instead? >> >> Agreed. >> >>>> The flag AI_SHIM must be set, or otherwise the resolver does not >>>> return sockaddr_shim data structures to guarantee that legacy >>>> applications do not break. >>> >>> But presumably legacy applications would not set ai_family to PF_SHIM, >>> so the AI_SHIM flags seems redundant. >>> >>> .. >>>> The protocol field is 0 when the getaddrinfo caller does not care >>>> about the specific SHIM protocol to be used. The caller (or the >>>> resolver) can set this field also to IPPROTO_HIP. >>> >>> .. >>> >>> Since this API is supposed to be usable for multiple SHIM protocols >>> (e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in >>> use I'd think that the caller MUST set the protocol field to the >>> constant identifying the protocol in use (e.g. IPPROTO_HIP, >>> IPPROTO_SHIM6). >> >> Removed the statement on removing legacy applications. I think the AI_SHIM >> flag is still necessary. The protocol field can be set to zero even with >> SHIM-aware applications when the application does not care which particular >> SHIM protocol it is riding on. In such a case, a separate flag is needed. >> >>>> Some applications may prefer >>>> configuring the locators manually and can set the AI_SHIM_NOLOCATORS >>>> flag to prohibit the getaddrinfo from resolving any locators. >>>> >>>> The ai_family field is PF_SHIM with SHIM-specific addrinfo data >>>> structures. >>> >>> What is the "SHIM-specific addrinfo data structures" ? do you mean an >>> addrinfo data structure with an ai_addr pointing to a sockaddr_shim >>> data structure? >> >> Yes, corrected. >> >>>> ai_addrlen is the size of the structure pointed by ai_addr. >>> >>> This is already specified as part of RFC3493. No need to duplicate that >>> information here. >> >> I think it is more reader-friendly to go through all of the fields >> one-by-one and describe how they are affected by the draft. Added some >> clarifications: >> >> ai_addrlen is the size of the structure pointed by ai_addr. This >> equals to sizeof(struct sockaddr_shim) when when ai_family field is >> PF_SHIM. >> >>>> The output argument res is dynamically allocated by the resolver. >>>> The application must free res argument with the free_addrinfo >>>> function. >>> >>> We do not need to specify that here, that's orthogonal to the discussion >>> we're having IMO. >> >> I think it is useful to recap here how the resolver works. Changed the text >> to: >> >> The output argument res is dynamically allocated by the resolver. >> The application frees res argument with the free_addrinfo function. >> The res argument contains a linked list of the resolved endpoints. >> The linked list contains sockaddr_shim structures only when the input >> argument has the AI_SHIM flag set. When the resolver finds SHIM >> identifiers, it inserts them to the front of the list. SHIM >> identifiers for different protocols are sorted according to local >> policies. Non-SHIM identifiers are present only when ai_protocol is >> set zero in the hints arguments of getaddrinfo() or the hints >> argument is NULL. The non-SHIM identifiers are placed after SHIM >> identifiers. >> >> Notice: I added text that sorting e.g. between HIP vs. SHIM6 identifiers is >> a local policy issue. >> >>>> The res argument contains a linked list of the resolved >>>> endpoints. The linked list contains sockaddr_shim structures only >>>> when the input argument has the AI_SHIM flag set. When the >>>> resolver finds SHIM identifiers, it inserts them to the front of the >>>> list. >>> >>> This seems to imply that the resolver may also return non-SHIM sockaddr >>> structures (e.g. sockaddr_in6) at the tail of the list. That should be >>> made explicit. >> >> Done. >> > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 07:58:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFEx-0001H6-CL; Mon, 17 Sep 2007 07:58:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFEw-0001H1-3I for hipsec@ietf.org; Mon, 17 Sep 2007 07:58:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXFEu-00021Y-ST for hipsec@ietf.org; Mon, 17 Sep 2007 07:58:10 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2135535uge for ; Mon, 17 Sep 2007 04:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=3C2SrpkJQhLvpR6L9svVeto/v1rg2l1Nt57S2vYwg/k=; b=raddkOts2mskJgmflddZ8ee5vwS89nESnsQOsbgSzrggRyKPPr1J7mA09YpChz+jlG3ktZxzbiau6b/Js3A8BiV8TZVK9hw1VIEqNY2dgDKndzD9LA7fQ3edozZQcoYMFaZZI584Iw/x1WnxJ4rar8LSTkjyMm5Z291wy/VgvWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=nHoc1wTUaDOukXMoWe3v0zJq0D5ft0zkyCjDisej6NPnIbnmyxglXJXx64JWCQ1+6PSVgCBLVK/VNTQtZy8qlE1Lpc3q++vALZ8pFJqBqiejBQ1xRsh2m5O0+dTcSg2h0NoIyQstGjrlGEBhHgvL5WYofqSm6/QHHpeaWHOzHWA= Received: by 10.67.28.4 with SMTP id f4mr7078493ugj.1190030287891; Mon, 17 Sep 2007 04:58:07 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id i39sm8300684ugd.2007.09.17.04.58.05 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2007 04:58:06 -0700 (PDT) From: Julien Laganier To: Miika Komu Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Mon, 17 Sep 2007 13:58:02 +0200 User-Agent: KMail/1.9.6 References: <200709131348.07644.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709171358.03323.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Sunday 16 September 2007, Miika Komu wrote: > Hi Julien, Hi Miika, > new version based on your comments is available here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt I checked it, looks good. Only remaining item is: > >>> human readable names are not limited to FQDNs, unqualified DNS > >>> names can be used too (e.g. thanks to the 'search example.com' > >>> line in a /etc/resolv.conf). I'm also not sure about restricting > >>> user interfaces to human-readable names (e.g. FQDN), it also > >>> happens that IP addresses are entered in user interface, alone or > >>> embedded in a URL. > >> > >> I hope this is better then: > >> > >> User Interface | Hostname, FQDN or ULID > > > > relative (i.e. not fully qualified) domain name are not necessarily > > limited to hostname, they can be any domain name taken relative to > > a well known origin, or to a list of domains used as a search list. > > For example, when the list of domain used as a search list > > contains "isi.edu." and "cs.isi.edu.", the fully qualified domain > > name "www.cs.isi.edu." corresponds to both of these relative domain > > name: "www" and "www.cs". > > Please make a concrete suggestion on what to change? I think this not > very important for the draft. s/hostname/relative domain name/ --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 08:07:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFOK-0000Ft-GG; Mon, 17 Sep 2007 08:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFOI-000093-BS for hipsec@ietf.org; Mon, 17 Sep 2007 08:07:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXFOG-0002D3-Tf for hipsec@ietf.org; Mon, 17 Sep 2007 08:07:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6560C2D13; Mon, 17 Sep 2007 15:07:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AEDCE2D0E; Mon, 17 Sep 2007 15:07:40 +0300 (EEST) Date: Mon, 17 Sep 2007 15:07:40 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jari Arkko In-Reply-To: <46EE5AF9.4070706@piuha.net> Message-ID: References: <46EE5AF9.4070706@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: HIP , draft-ietf-hip-native-api@tools.ietf.org, Marcelo Bagnulo Braun Subject: [Hipsec] Re: review of draft-ietf-hip-native-api-02 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Jari Arkko wrote: Hi Jari, thanks for the feedback, comments below. > I happened to read this draft. A few comments: > > In general, I'd like to see work like this move forward. > > The main question mark that I had relates to the > positioning of this work as a generic Shim layer > API vs. HIP-only API. I think a generic API would > be useful, but I'm uncertain if the API as defined > is a good fit for non-HIP designs, most notably the > Shim6 design. > > But I'm sure you have talked about this in the past. > Can you post pointers to such discussion? Not really because it has been just non-electoric discussions. > Anyway, what I see problematic from the point of > using for Shim6 is the following: > > - The resolution step does not distinguish ULIDs > from locators. ULIDs and locators have separate field in the sockaddr_shim structure. Please clarify? > - Section 4.1 ULID comparison for Shim6 may > produce surprising results, given that > different connection attempts may result > in different ULIDs. This applies also to HITs as the application may receive multiple HITs. Please suggest text? > - I'm not sure how the deferred context creation > approach in Shim6 fits with this API. > > What's the role of this spec vs. the shim6 draft that you > have? Is this "rough" categorization helpful and should it be included in the draft? http://www1.ietf.org/mail-archive/web/hipsec/current/msg02222.html > > Other comments: > >> | Locator | Non-routable IPv4 or IPv6 address used at the lower | >> | | layers | > I'm pretty sure you meant routable. > >> In practise, the resolver functionality can implemented in different > > s/can/can be/ Yes, thanks. >> They denote an ULID value associated with a wildcard >> ULID of any, public, or anonymous type. > > I do not understand the difference. Please elaborate. Any means public or anonymous (perhaps this should be clarified?). Public and anonymous are described in the 03-pre2-version of the draft already: "In the case of HIP, anonymous identifiers refer to the anonymous identities in [RFC4423]. In the case of SHIM6, anonymous identifiers refer to the use of temporary IPv6 addresses as specified in [RFC3041]." >> In both client and server based applications, the use of the >> SHIM_ANY* macro accepts also non-SHIM based communications to >> maximize backwards compatibility. When the application wants >> enforces the use of SHIM-based communications with ORCHID prefix >> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >> Alternatively, the application accepts both ORCHID and non-ORCHID- >> based communications, but informs the difference e.g. to the user. >> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >> which inputs a pointer to a in6_addr and returns 1 when the address >> has orchid prefix and 0 otherwise. > > Is the use of Orchids the same or different issue from using > a Shim? I.e., do all Shims employ an Orchid? And if not, wouldn't > you want to enable/disable the use of non-shim communications > and Orchids separately? SHIM and Orchid are decoupled issues. The 03-pre2-version of the draft mentions: a) The flag AI_SHIM must be set, or otherwise the resolver does not return sockaddr_shim data structures. b) To distinguish between ORCHID [RFC4843] and non-ORCHID-based communications, it can call SHIM_IS_IPV6_ADDR_ORCHID macro. c) Alternatively, the application can set the flag SHIM_FLAG_ONLY_ORCHID in sshim_flags to allow only ORCHID-based communications. Should this be clarified? Suggest some text? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 08:33:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFnW-0004X5-FH; Mon, 17 Sep 2007 08:33:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFnU-0004UP-OR for hipsec@ietf.org; Mon, 17 Sep 2007 08:33:52 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXFnT-00059F-0W for hipsec@ietf.org; Mon, 17 Sep 2007 08:33:52 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D186E212D1F; Mon, 17 Sep 2007 15:33:48 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 8929A212C54; Mon, 17 Sep 2007 15:33:48 +0300 (EEST) Message-ID: <46EE7426.5070600@nomadiclab.com> Date: Mon, 17 Sep 2007 15:33:42 +0300 From: Jan Mikael Melen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, I don't understand the reasoning behind the logic why would we want to have the locator in the first place in the sockaddr_shim. Now the current daft suggests that if the application resolves peer's FQDN using hints AF_UNSPEC it will end up getting a struct sockadd_shim which contains the locator for the peer and addition to that you will get sockaddr_in/in6 which also contains locator to the peer. E.g. now if the peer has one (1) ipv4 address and two (2) ipv6 addresses and ulid the result as said in the current draft is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. Semantically I would expect that it would work as today. So my understanding is that if application resolves the FQDN using hints AF_INET it will get a list of ipv4 addresses and if using AF_INET6 the application will get the list of ipv6 addresses. If I now draw a line from this to the AF_SHIM, I would expect to get only a list of ULIDs that the peer has because as an application I'm not really interested of the locator anymore (that is the whole point of of having shim layer). Maybe I have missed something. If then again I would be a application that is interested both from ulids and addresses I would then give hints AF_UNSPEC which would then result a list containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None of the structs would contain duplicated data, if we take again the same example as earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. Regards, Jan Miika Komu wrote: > On Mon, 17 Sep 2007, Jan Mikael Melen wrote: > > Hi, > > ulid is the HIT and locator is a routable address (IPv4 or IPv6). The > legacy API draft discusses in detail the case where only HITs are > given to a non-HIP aware application. > > Due to constraints in the resolver API and size of sockaddr > structures, the returned data structures may contain some redundancy. > Particularly, the resolver returns n * m sockaddr_shim data structures > when the resolution results in n HITs and m locators. > > Returning multiple locators within a single sockaddr structure is > possible, but the sockaddr structure size is limited and we have to > have some redundancy anyway. The resolution procedure also considers > mostly *initial* address look-up from DNS. The hosts are free to > communicate additional locators in the base exchange or using UPDATE. > > On the other hand, multiple locators in a single structure might > speed-up the HIP connection establishment when the base exchange is > parallerized. However, some applications parallize connections already > at the application layer. I have no strong opinion on this. We can fit > easily fit 10 in6_addr locator structures into sockaddr_shim. Opinions? > >> Hello, >> >> Question regarding section 4.1. Socket Family and Address Structure. >> Why there is sshim_locator in the sockaddr_shim? >> struct sockaddr_shim { >> uint8_t sshim_len; >> uint8_t sshim_family; >> uint16_t sshim_port; >> shim_ulid_t sshim_ulid; >> shim_locator_t sshim_locator; >> uint64_t sshim_flags; >> } >> >> IMHO it is not needed as the connection to peer is bound to ULID not >> locator and the peer might have more than one locator which means >> that you are not anyway providing full set of locators to the socket. >> Furthermore in section 3.3 the resolver is supposed to deliver both >> ULIDs and locators to the SHIM layer. >> >> Jan >> >> >> Miika Komu wrote: >>> On Wed, 5 Sep 2007, Julien Laganier wrote: >>> >>> Julien, >>> >>>> I have reviewed draft-ietf-hip-native-api-02.txt, and I think the >>>> documents is in good shape. >>>> >>>> I have however a couple of comments and suggested changes below that I >>>> would like to see addressed before the document is sent to IESG for >>>> publication. >>> >>> thanks for the review! I have addressed all of your editorial >>> comments in the draft. A preversion of the next version of the draft >>> based on your comments is in here: >>> >>> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt >>> >>>> I had no time to distinguish between editorial and technical ones, >>>> sorry. >>> >>> No problem. >>> >>> Below I have commented only the things that were unclear or need >>> further clarification, otherwise I applied your comments as you >>> suggested. I see no need to repeat minor nits here. >>> >>>> SHIM and SHIM-aware are not defined in the introduction. At minimum I >>>> would expect the abstract text explaining the HIP focus but larger >>>> applicability to other SHIM layers to be duplicated here. >>> >>> Added some text to intro, I hope the changes are fine. >>> >>>> Also, if we talk about address family, shouldn't we use AF_SHIM >>>> instead >>>> of PF_SHIM? >>> >>> In practice, there is no difference between AF and PF. Added text: >>> >>> The API extensions introduce a new address family, AF_SHIM, and a >>> new >>> socket address structure for sockets using explicit identifier- >>> locator bindings. PF_SHIM is used as an alias for AF_SHIM in this >>> document because the distinction between PF and AF has been lost in >>> the practice. >>> >>>> Also, is "initiate outgoing communications without knowledge of the >>>> peer >>>> identity" opportunistic mode? If yes it should be spelled out. I don't >>>> see how it is possible to accept a HIP incoming communication without >>>> knowledge of the peer identity since identity will be in I2... Maybe >>>> you refer to initiate outgoing communications without knowing the >>>> local >>>> identity? >>>> >>>>> This document describes also how to address this situation using late >>>>> binding based on new wildcards. >>>> >>>> 'late binding' is not defined. We can't expect anyone to understand >>>> what >>>> it means. >>> >>> Removed 'late binding' since it was not really used elsewhere in the >>> text. Changed the 'initiate outgoing' text to this: >>> >>> Some applications may accept incoming communications from any >>> identifier. Other applications may initiate outgoing communications >>> without knowledge of the peer identifier in Opportunistic Mode >>> [I-D.ietf-hip-base] by just relying on a peer locator. This >>> document >>> describes how to address both situations using "wildcards" described >>> in a later section. >>> >>>>> There are two related IETF documents that are define other related >>>>> API extensions. Multihoming related APIs are defined in >>>>> [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy >>>>> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] >>>> >>>> I disagree with the use of 'other related API extensions' in this >>>> context. While this document does indeed defines extensions to the >>>> socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api]. >>> >>> Changed to: >>> >>> There are two related API documents. Multihoming related APIs are >>> defined in [I-D.ietf-shim6-multihome-shim-api]. IPsec related >>> policy >>> attributes and channel bindings are defined in [I-D.ietf-btns-c-api] >>> >>>> human readable names are not limited to FQDNs, unqualified DNS >>>> names can >>>> be used too (e.g. thanks to the 'search example.com' line in >>>> a /etc/resolv.conf). I'm also not sure about restricting user >>>> interfaces to human-readable names (e.g. FQDN), it also happens >>>> that IP >>>> addresses are entered in user interface, alone or embedded in a URL. >>> >>> I hope this is better then: >>> >>> User Interface | Hostname, FQDN or ULID >>> >>>>> We limit the description to those interfaces and data structures that >>>>> are either modified or completely new, because the SHIM API is >>>>> otherwise identical to the sockets API [POSIX]. >>>> >>>> In all API definitions that follows, it should be specified which >>>> header >>>> file should be included to result in the definitions (e.g. PF_SHIM, >>>> AF_SHIM, sockaddr_shim), e.g. , or >>>> . It would also be good to have a section that recapitulate >>>> all new definitions at the end of the document. >>> >>> Added this, I hope it is ok now. >>> >>>>> The application usually sets the sins_ulid field using the >>>>> resolver. However, three special macros can be used to directly set a >>>>> value into the sins_ulid field. The macros are SHIM_ANY, >>>>> SHIM_ANY_PUB and SHIM_ANY_ANON. They denote an ULID value associated >>>>> with a wildcard ULID of any, public, or anonymous type. >>>> >>>> I miss the definition of these different ULID types (public vs. >>>> anonymous). I think we need some more text or a reference to another >>>> document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 >>>> ULID's). >>> >>> Added the reference as you suggested and added a reference HIP >>> architecture RFC as well regarding to the anonymous bit. I hope this >>> is ok? We could also removed the ANON and PUB altogether (I am >>> referring to the discussion of Pekka and Philip on the anonymity >>> topic). >>> >>>> I'm not sure about the restriction to one host binding on a given >>>> port. >>>> There are TCP/IP stacks that allows binding multiple processes to bind >>>> to same addresses and/or ports through the use of the appropriate >>>> socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite >>>> them here, or remove the above restriction. >>> >>> Removed. >>> >>>>> A client application can use the SHIM_ANY macro to establish a >>>> >>>> s/macro to establish a/macro with connect() or sendto() calls/ >>> >>> Instead of listing all the socket calls, the text now says "outgoing >>> communications". I hope this is ok to cover both TCP and UDP based >>> communication? >>> >>>>> known beforehand. >>>>> In both client and server based applications, the use of the >>>>> SHIM_ANY* macro accepts also non-SHIM based communications to >>>>> maximize backwards compatibility. >>>> >>>> The text should specify that goes into the sins_ulid field (e.g. >>>> zeroes) >>>> when that is the case. >>> >>> The SHIM_ANY macros is actually used to initialized that particular >>> field. Clarified the text. >>> >>>> >>>>> When the application wants >>>>> enforces the use of SHIM-based communications with ORCHID prefix >>>>> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >>>>> Alternatively, the application accepts both ORCHID and non-ORCHID- >>>>> based communications, but informs the difference e.g. to the user. >>>>> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >>>> >>>> How about SHIM_IS_IPV6_ADDR_ORCHID instead? >>> >>> Agreed. >>> >>>>> The flag AI_SHIM must be set, or otherwise the resolver does not >>>>> return sockaddr_shim data structures to guarantee that legacy >>>>> applications do not break. >>>> >>>> But presumably legacy applications would not set ai_family to PF_SHIM, >>>> so the AI_SHIM flags seems redundant. >>>> >>>> .. >>>>> The protocol field is 0 when the getaddrinfo caller does not care >>>>> about the specific SHIM protocol to be used. The caller (or the >>>>> resolver) can set this field also to IPPROTO_HIP. >>>> >>>> .. >>>> >>>> Since this API is supposed to be usable for multiple SHIM protocols >>>> (e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in >>>> use I'd think that the caller MUST set the protocol field to the >>>> constant identifying the protocol in use (e.g. IPPROTO_HIP, >>>> IPPROTO_SHIM6). >>> >>> Removed the statement on removing legacy applications. I think the >>> AI_SHIM flag is still necessary. The protocol field can be set to >>> zero even with SHIM-aware applications when the application does not >>> care which particular SHIM protocol it is riding on. In such a case, >>> a separate flag is needed. >>> >>>>> Some applications may prefer >>>>> configuring the locators manually and can set the AI_SHIM_NOLOCATORS >>>>> flag to prohibit the getaddrinfo from resolving any locators. >>>>> >>>>> The ai_family field is PF_SHIM with SHIM-specific addrinfo data >>>>> structures. >>>> >>>> What is the "SHIM-specific addrinfo data structures" ? do you mean an >>>> addrinfo data structure with an ai_addr pointing to a sockaddr_shim >>>> data structure? >>> >>> Yes, corrected. >>> >>>>> ai_addrlen is the size of the structure pointed by ai_addr. >>>> >>>> This is already specified as part of RFC3493. No need to duplicate >>>> that >>>> information here. >>> >>> I think it is more reader-friendly to go through all of the fields >>> one-by-one and describe how they are affected by the draft. Added >>> some clarifications: >>> >>> ai_addrlen is the size of the structure pointed by ai_addr. This >>> equals to sizeof(struct sockaddr_shim) when when ai_family field is >>> PF_SHIM. >>> >>>>> The output argument res is dynamically allocated by the resolver. >>>>> The application must free res argument with the free_addrinfo >>>>> function. >>>> >>>> We do not need to specify that here, that's orthogonal to the >>>> discussion >>>> we're having IMO. >>> >>> I think it is useful to recap here how the resolver works. Changed >>> the text to: >>> >>> The output argument res is dynamically allocated by the resolver. >>> The application frees res argument with the free_addrinfo function. >>> The res argument contains a linked list of the resolved endpoints. >>> The linked list contains sockaddr_shim structures only when the >>> input >>> argument has the AI_SHIM flag set. When the resolver finds SHIM >>> identifiers, it inserts them to the front of the list. SHIM >>> identifiers for different protocols are sorted according to local >>> policies. Non-SHIM identifiers are present only when ai_protocol is >>> set zero in the hints arguments of getaddrinfo() or the hints >>> argument is NULL. The non-SHIM identifiers are placed after SHIM >>> identifiers. >>> >>> Notice: I added text that sorting e.g. between HIP vs. SHIM6 >>> identifiers is a local policy issue. >>> >>>>> The res argument contains a linked list of the resolved >>>>> endpoints. The linked list contains sockaddr_shim structures only >>>>> when the input argument has the AI_SHIM flag set. When the >>>>> resolver finds SHIM identifiers, it inserts them to the front of the >>>>> list. >>>> >>>> This seems to imply that the resolver may also return non-SHIM >>>> sockaddr >>>> structures (e.g. sockaddr_in6) at the tail of the list. That should be >>>> made explicit. >>> >>> Done. >>> >> > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 08:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFrl-0000Xs-VC; Mon, 17 Sep 2007 08:38:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXFrk-0000XO-SL for hipsec@ietf.org; Mon, 17 Sep 2007 08:38:16 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXFrk-0005Ev-6C for hipsec@ietf.org; Mon, 17 Sep 2007 08:38:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 05717198690; Mon, 17 Sep 2007 15:38:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ADFDA19865D; Mon, 17 Sep 2007 15:38:14 +0300 (EEST) Message-ID: <46EE7537.50503@piuha.net> Date: Mon, 17 Sep 2007 15:38:15 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Miika Komu References: <46EE5AF9.4070706@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: HIP , draft-ietf-hip-native-api@tools.ietf.org, Marcelo Bagnulo Braun Subject: [Hipsec] Re: review of draft-ietf-hip-native-api-02 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, > Not really because it has been just non-electoric discussions. Ok. Can you summarize then? >> Anyway, what I see problematic from the point of >> using for Shim6 is the following: >> >> - The resolution step does not distinguish ULIDs >> from locators. > > ULIDs and locators have separate field in the sockaddr_shim structure. > Please clarify? Yes, in your API. But in Shim6 there is no distinction. >> - Section 4.1 ULID comparison for Shim6 may >> produce surprising results, given that >> different connection attempts may result >> in different ULIDs. > > This applies also to HITs as the application may receive multiple > HITs. Please suggest text? I don't have a good suggestion. You may end up just having to document the issue. >> - I'm not sure how the deferred context creation >> approach in Shim6 fits with this API. >> >> What's the role of this spec vs. the shim6 draft that you >> have? > > Is this "rough" categorization helpful and should it be included in > the draft? > > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02222.html I think you said something along these lines in the draft already. But I would like to see the current explanation expanded. >> >> I do not understand the difference. Please elaborate. > > Any means public or anonymous (perhaps this should be clarified?). > Public and anonymous are described in the 03-pre2-version of the draft > already: > > "In the case of HIP, anonymous identifiers refer to the anonymous > identities in [RFC4423]. In the case of SHIM6, anonymous identifiers > refer to the use of temporary IPv6 addresses as specified in [RFC3041]." Ok, I think. > >>> In both client and server based applications, the use of the >>> SHIM_ANY* macro accepts also non-SHIM based communications to >>> maximize backwards compatibility. When the application wants >>> enforces the use of SHIM-based communications with ORCHID prefix >>> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >>> Alternatively, the application accepts both ORCHID and non-ORCHID- >>> based communications, but informs the difference e.g. to the user. >>> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >>> which inputs a pointer to a in6_addr and returns 1 when the address >>> has orchid prefix and 0 otherwise. >> >> Is the use of Orchids the same or different issue from using >> a Shim? I.e., do all Shims employ an Orchid? And if not, wouldn't >> you want to enable/disable the use of non-shim communications >> and Orchids separately? > > SHIM and Orchid are decoupled issues. The 03-pre2-version of the draft > mentions: > > a) The flag AI_SHIM must be set, or otherwise the resolver does not > return sockaddr_shim data structures. > b) To distinguish between ORCHID [RFC4843] and non-ORCHID-based > communications, it can call SHIM_IS_IPV6_ADDR_ORCHID macro. > c) Alternatively, the application can set the flag SHIM_FLAG_ONLY_ORCHID > in sshim_flags to allow only ORCHID-based communications. > > Should this be clarified? Suggest some text? > This is better, but let me ask a further question: how do you control whether you want to talk to non-shim capable hosts? Or is that in the draft-ietf-shim6-multihoming-api draft? Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 12:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJJM-0006kD-Gb; Mon, 17 Sep 2007 12:19:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJJL-0006k8-Tx for hipsec@ietf.org; Mon, 17 Sep 2007 12:18:59 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXJJL-000295-G0 for hipsec@ietf.org; Mon, 17 Sep 2007 12:18:59 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8HGItNC013713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Sep 2007 09:18:56 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8HGItjk012082; Mon, 17 Sep 2007 09:18:55 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8HGIjXw011503; Mon, 17 Sep 2007 09:18:49 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 09:17:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Sep 2007 09:17:40 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040497D0@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: another review of draft-ietf-hip-native-api-02.txt Thread-Index: Acf5RkS9T/ABIiW2QJe/kRRQ1ApV0Q== From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 17 Sep 2007 16:17:40.0883 (UTC) FILETIME=[4549A630:01C7F946] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: HIP Subject: [Hipsec] another review of draft-ietf-hip-native-api-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, Here are a few high-level comments, some of which have been touched upon by other reviewers. My inclination would be to first describe what an API looks like that modifies or extends the IPv6 API for HIP support only, and then later consider whether and how it can be generalized to support other non-HIP usage. The reason is that if you try to do the general solution first, you may lose or obscure getting the HIP-specific concerns right. =20 In a similar vein, I would like to see stated up front what are the functional requirements or assumptions of this API. In particular, before we get to syntactical issues, it should be more clear what name or names (HIT, ORCHID, LSI, HI, RVS) the application is expected to deal with, and what are the expected semantics of the API calls. As an example, is the system expected to be able to handle the case when no locator information is available in the connect call, or when there are multiple locators, etc.? =20 We should also state what are the assumptions on policy that an application may want to control. This seems to me to be underdeveloped in the current draft; section 4.1 goes into some of this but I think there are going to be more policy issues that need to be exposed. For example, another possible option is to tell the system whether to enforce the usage of HIP or whether to allow non-HIP communications if the peer doesn't support HIP. =20 Multihoming is also underdeveloped; I realize that there is a separate shim6 multihoming API document which you are trying to leverage, but again there probably are some dependencies to explore because that other API draft, for instance, presumes that REAP is implemented, which is not officially part of HIP. =20 We should also clarify more explicitly the assumptions and requirements of how the resolver interacts differently with the system (for instance, in Figure 2, the resolver/SHIM interaction steps d and e implies certain assumptions on the sequence of events on how the pieces of the system obtain binding information). =20 - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 17:15:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNvA-00011x-Q3; Mon, 17 Sep 2007 17:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNv8-000102-RU for hipsec@ietf.org; Mon, 17 Sep 2007 17:14:18 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXNv2-0001fI-N9 for hipsec@ietf.org; Mon, 17 Sep 2007 17:14:18 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IXNuT-0006UM-3D for hipsec@ietf.org; Mon, 17 Sep 2007 17:13:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: HIP WG From: Philip Matthews Date: Mon, 17 Sep 2007 17:13:35 -0400 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Hipsec] Question about HIP base exchange X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Say an Initiator wants to establish a HIP association with some node with HIT Y. It sends off an I1 packet which travels through various middleware boxes and finally arrives at some node that purports to be Y. This node, in turn, replies with an R1 packet which travels back though middleware boxes to the Initiator. The two nodes then exchange I2 and R2 packets. Question: At what point does the Initiator know that it really is talking to node Y? In other words, what prevents an attacker from intercepting or caching an R2 response from HIT Y and replaying it to make the Initiator believe that it has HIT Y? I am guessing that the Initiator does not know that it is really talking to HIT Y until it receives the R2 packet. Am I right? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Sep 17 19:20:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXPrz-0002yP-K4; Mon, 17 Sep 2007 19:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXPry-0002x1-HH for hipsec@ietf.org; Mon, 17 Sep 2007 19:19:10 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXPrs-0004zi-Ai for hipsec@ietf.org; Mon, 17 Sep 2007 19:19:10 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8HNIg0V012602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Sep 2007 16:18:46 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8HNIfxJ019150; Mon, 17 Sep 2007 16:18:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8HNId9G019108; Mon, 17 Sep 2007 16:18:41 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 16:18:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Question about HIP base exchange Date: Mon, 17 Sep 2007 16:18:39 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040497D5@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Question about HIP base exchange Thread-Index: Acf5cG1nO9Il+Qm/RVWjE7JGT1a1bQAAkV3g From: "Henderson, Thomas R" To: "Philip Matthews" , "HIP WG" X-OriginalArrivalTime: 17 Sep 2007 23:18:39.0555 (UTC) FILETIME=[14A12130:01C7F981] X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: Monday, September 17, 2007 2:14 PM > To: HIP WG > Subject: [Hipsec] Question about HIP base exchange >=20 > Say an Initiator wants to establish a HIP association with some node =20 > with HIT Y. It sends off an I1 packet which travels through various =20 > middleware boxes and finally arrives at some node that=20 > purports to be =20 > Y. This node, in turn, replies with an R1 packet which travels back =20 > though middleware boxes to the Initiator. The two nodes then=20 > exchange =20 > I2 and R2 packets. >=20 > Question: At what point does the Initiator know that it really is =20 > talking to node Y? =20 When R2 is validated. > In other words, what prevents an=20 > attacker from =20 > intercepting or caching an R2 response from HIT Y and=20 > replaying it to =20 > make the Initiator believe that it has HIT Y? Each base exchange should use a different Diffie-Hellman key, and the Diffie-Hellman keying material is used to extract the HMAC keys, so a replayed R2 should fail the HMAC_2 verification. >=20 > I am guessing that the Initiator does not know that it is really =20 > talking to HIT Y until it receives the R2 packet. Am I right? >=20 Yes, it is possible that an R1 could have been replayed, although the R1 generation counter is designed to limit the possibility of succumbing to such an attack. - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 03:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXX7-00046S-7H; Tue, 18 Sep 2007 03:30:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXX5-00045N-Ud for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:07 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXXX5-0002dc-Gs for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:07 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A4CC32D12; Tue, 18 Sep 2007 10:30:06 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id CC34F2D02; Tue, 18 Sep 2007 10:29:59 +0300 (EEST) Date: Tue, 18 Sep 2007 10:29:59 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709171358.03323.julien.IETF@laposte.net> Message-ID: References: <200709131348.07644.julien.IETF@laposte.net> <200709171358.03323.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Julien Laganier wrote: Hi Julien, > On Sunday 16 September 2007, Miika Komu wrote: >> Hi Julien, > > Hi Miika, > >> new version based on your comments is available here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt > > I checked it, looks good. Only remaining item is: > >>>>> human readable names are not limited to FQDNs, unqualified DNS >>>>> names can be used too (e.g. thanks to the 'search example.com' >>>>> line in a /etc/resolv.conf). I'm also not sure about restricting >>>>> user interfaces to human-readable names (e.g. FQDN), it also >>>>> happens that IP addresses are entered in user interface, alone or >>>>> embedded in a URL. >>>> >>>> I hope this is better then: >>>> >>>> User Interface | Hostname, FQDN or ULID >>> >>> relative (i.e. not fully qualified) domain name are not necessarily >>> limited to hostname, they can be any domain name taken relative to >>> a well known origin, or to a list of domains used as a search list. >>> For example, when the list of domain used as a search list >>> contains "isi.edu." and "cs.isi.edu.", the fully qualified domain >>> name "www.cs.isi.edu." corresponds to both of these relative domain >>> name: "www" and "www.cs". >> >> Please make a concrete suggestion on what to change? I think this not >> very important for the draft. > > s/hostname/relative domain name/ Thanks, this change will be in the next version. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ HipseFrom hipsec-bounces@lists.ietf.org Tue Sep 18 03:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXX7-00046S-7H; Tue, 18 Sep 2007 03:30:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXX5-00045N-Ud for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:07 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXXX5-0002dc-Gs for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:07 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A4CC32D12; Tue, 18 Sep 2007 10:30:06 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id CC34F2D02; Tue, 18 Sep 2007 10:29:59 +0300 (EEST) Date: Tue, 18 Sep 2007 10:29:59 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709171358.03323.julien.IETF@laposte.net> Message-ID: References: <200709131348.07644.julien.IETF@laposte.net> <200709171358.03323.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'HIP WG' , draft-ietf-hip-native-api@tools.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Julien Laganier wrote: Hi Julien, > On Sunday 16 September 2007, Miika Komu wrote: >> Hi Julien, > > Hi Miika, > >> new version based on your comments is available here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt > > I checked it, looks good. Only remaining item is: > >>>>> human readable names are not limited to FQDNs, unqualified DNS >>>>> names can be used too (e.g. thanks to the 'search example.com' >>>>> line in a /etc/resolv.conf). I'm also not sure about restricting >>>>> user interfaces to human-readable names (e.g. FQDN), it also >>>>> happens that IP addresses are entered in user interface, alone or >>>>> embedded in a URL. >>>> >>>> I hope this is better then: >>>> >>>> User Interface | Hostname, FQDN or ULID >>> >>> relative (i.e. not fully qualified) domain name are not necessarily >>> limited to hostname, they can be any domain name taken relative to >>> a well known origin, or to a list of domains used as a search list. >>> For example, when the list of domain used as a search list >>> contains "isi.edu." and "cs.isi.edu.", the fully qualified domain >>> name "www.cs.isi.edu." corresponds to both of these relative domain >>> name: "www" and "www.cs". >> >> Please make a concrete suggestion on what to change? I think this not >> very important for the draft. > > s/hostname/relative domain name/ Thanks, this change will be in the next version. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 03:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXXD-000499-D5; Tue, 18 Sep 2007 03:30:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXXB-000479-Gg for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:13 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXXXA-0002do-Rl for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:13 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5EDE82D0F; Tue, 18 Sep 2007 10:30:12 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AABFD2D0E; Tue, 18 Sep 2007 10:30:03 +0300 (EEST) Date: Tue, 18 Sep 2007 10:30:03 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <46EE7426.5070600@nomadiclab.com> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> <46EE7426.5070600@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Jan Mikael Melen wrote: Hi Jan, > Hi, > > I don't understand the reasoning behind the logic why would we want to have > the locator in the first place in the sockaddr_shim. Now the current daft > suggests that if the application resolves peer's FQDN using hints AF_UNSPEC > it will end up getting a struct sockadd_shim which contains the locator for > the peer and addition to that you will get sockaddr_in/in6 which also > contains locator to the peer. E.g. now if the peer has one (1) ipv4 address > and two (2) ipv6 addresses and ulid the result as said in the current draft > is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. > > Semantically I would expect that it would work as today. So my understanding > is that if application resolves the FQDN using hints AF_INET it will get a > list of ipv4 addresses and if using AF_INET6 the application will get the > list of ipv6 addresses. If I now draw a line from this to the AF_SHIM, I > would expect to get only a list of ULIDs that the peer has because as an > application I'm not really interested of the locator anymore (that is the > whole point of of having shim layer). Maybe I have missed something. I got your point now. You just want the ulid field and not the locator field. You are also implicitly suggesting that the resolver (or local DNS proxy) communicates the IP addresses matching to the HIP daemon as a side effect of HIT resolving as ic mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 03:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXXD-000499-D5; Tue, 18 Sep 2007 03:30:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXXXB-000479-Gg for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:13 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXXXA-0002do-Rl for hipsec@ietf.org; Tue, 18 Sep 2007 03:30:13 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5EDE82D0F; Tue, 18 Sep 2007 10:30:12 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AABFD2D0E; Tue, 18 Sep 2007 10:30:03 +0300 (EEST) Date: Tue, 18 Sep 2007 10:30:03 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <46EE7426.5070600@nomadiclab.com> Message-ID: References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> <46EE7426.5070600@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Jan Mikael Melen wrote: Hi Jan, > Hi, > > I don't understand the reasoning behind the logic why would we want to have > the locator in the first place in the sockaddr_shim. Now the current daft > suggests that if the application resolves peer's FQDN using hints AF_UNSPEC > it will end up getting a struct sockadd_shim which contains the locator for > the peer and addition to that you will get sockaddr_in/in6 which also > contains locator to the peer. E.g. now if the peer has one (1) ipv4 address > and two (2) ipv6 addresses and ulid the result as said in the current draft > is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. > > Semantically I would expect that it would work as today. So my understanding > is that if application resolves the FQDN using hints AF_INET it will get a > list of ipv4 addresses and if using AF_INET6 the application will get the > list of ipv6 addresses. If I now draw a line from this to the AF_SHIM, I > would expect to get only a list of ULIDs that the peer has because as an > application I'm not really interested of the locator anymore (that is the > whole point of of having shim layer). Maybe I have missed something. I got your point now. You just want the ulid field and not the locator field. You are also implicitly suggesting that the resolver (or local DNS proxy) communicates the IP addresses matching to the HIP daemon as a side effect of HIT resolving as in the legacy API draft. I guess you would solve the problem of manually configured HIT-to-IP mappings with setsockopt as in sections 5.6. or 5.10 of the SHIM6 API draft, right? http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt Having a single ULID field would perhaps be more aligned with SHIM6. On the other hand, the locator field could be just zeroes in this case. How would you suggest to handle the opportunistic mode? Would you just replace the ULID in sockaddr_shim with a routable IPv6 address? And perhaps a hint for the resolver to automatize this procedure. However, then we would end up again with redundantly routable addresses in the list. Having both ULID and locator fields has the drawback of exposing the application to a possibly outdated locator. Neverthless, this was preferred in the applications area. They felt that we should define a low level API that exposes everything to the application or higher level network programming library. The HIT-IP mappings should not be hidden from the application: http://www1.ietf.org/mail-archive/web/discuss/current/msg00533.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00520.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00546.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00537.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00497.html > If then again I would be a application that is interested both from ulids and > addresses I would then give hints AF_UNSPEC which would then result a list > containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None of the > structs would contain duplicated data, if we take again the same example as > earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. I have no strong objection against this, but it seems to conflict slightly with the apps area folks views. The original idea of "endpoint descriptor" was discarded because apps area folks wanted to expose everything to the applications. I used the word "slightly" because it is still possible to do manual locator handling in the application. If the application has only a single ULID field and not locator field in sockaddr_shim, the application can still query for the locators using a getsockopt() even before doing the actual connection, It could even call setsockopt() to overwrite the default peer locator before initial contact. I believe this would be more aligned with the SHIM6 API draft. If there are no strong objections, we can go towards Jan's approach. It just a matter whether we expose things in already in getaddrinfo() or later in socket options. I'd appreciate comments from other folks as well. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec n the legacy API draft. I guess you would solve the problem of manually configured HIT-to-IP mappings with setsockopt as in sections 5.6. or 5.10 of the SHIM6 API draft, right? http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt Having a single ULID field would perhaps be more aligned with SHIM6. On the other hand, the locator field could be just zeroes in this case. How would you suggest to handle the opportunistic mode? Would you just replace the ULID in sockaddr_shim with a routable IPv6 address? And perhaps a hint for the resolver to automatize this procedure. However, then we would end up again with redundantly routable addresses in the list. Having both ULID and locator fields has the drawback of exposing the application to a possibly outdated locator. Neverthless, this was preferred in the applications area. They felt that we should define a low level API that exposes everything to the application or higher level network programming library. The HIT-IP mappings should not be hidden from the application: http://www1.ietf.org/mail-archive/web/discuss/current/msg00533.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00520.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00546.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00537.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00497.html > If then again I would be a application that is interested both from ulids and > addresses I would then give hints AF_UNSPEC which would then result a list > containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None of the > structs would contain duplicated data, if we take again the same example as > earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in. I have no strong objection against this, but it seems to conflict slightly with the apps area folks views. The original idea of "endpoint descriptor" was discarded because apps area folks wanted to expose everything to the applications. I used the word "slightly" because it is still possible to do manual locator handling in the application. If the application has only a single ULID field and not locator field in sockaddr_shim, the application can still query for the locators using a getsockopt() even before doing the actual connection, It could even call setsockopt() to overwrite the default peer locator before initial contact. I believe this would be more aligned with the SHIM6 API draft. If there are no strong objections, we can go towards Jan's approach. It just a matter whether we expose things in already in getaddrinfo() or later in socket options. I'd appreciate comments from other folks as well. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 06:34:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaNl-0002vm-9q; Tue, 18 Sep 2007 06:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaNj-0002vg-Gd for hipsec@ietf.org; Tue, 18 Sep 2007 06:32:39 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXaNc-0003Ce-9s for hipsec@ietf.org; Tue, 18 Sep 2007 06:32:39 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B21BB212D1F; Tue, 18 Sep 2007 13:32:05 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 4A363212C54; Tue, 18 Sep 2007 13:32:05 +0300 (EEST) From: Jan Mikael Melen To: Miika Komu Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Tue, 18 Sep 2007 13:33:07 +0300 User-Agent: KMail/1.9.5 References: <46EE7426.5070600@nomadiclab.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709181333.07993.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, See inline.... On Tuesday 18 September 2007 10:30, Miika Komu wrote: > On Mon, 17 Sep 2007, Jan Mikael Melen wrote: > > > I don't understand the reasoning behind the logic why would we want to > > have the locator in the first place in the sockaddr_shim. Now the current > > daft suggests that if the application resolves peer's FQDN using hints > > AF_UNSPEC it will end up getting a struct sockadd_shim which contains the > > locator for the peer and addition to that you will get sockaddr_in/in6 > > which also contains locator to the peer. E.g. now if the peer has one (1) > > ipv4 address and two (2) ipv6 addresses and ulid the result as said in > > the current draft is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x > > sockaddr_in. > > > > Semantically I would expect that it would work as today. So my > > understanding is that if application resolves the FQDN using hints > > AF_INET it will get a list of ipv4 addresses and if using AF_INET6 the > > application will get the list of ipv6 addresses. If I now draw a line > > from this to the AF_SHIM, I would expect to get only a list of ULIDs that > > the peer has because as an application I'm not really interested of the > > locator anymore (that is the whole point of of having shim layer). Maybe > > I have missed something. > > I got your point now. You just want the ulid field and not the locator > field. You are also implicitly suggesting that the resolver (or local DNS > proxy) communicates the IP addresses matching to the HIP daemon as a side > effect of HIT resolving as in the legacy API draft. You are already stating that in your draft in the figure 2 in section 3.3. > I guess you would > solve the problem of manually configured HIT-to-IP mappings with > setsockopt as in sections 5.6. or 5.10 of the SHIM6 API draft, right? Yep, that is what I would expect that I would have to do if I'm a geek that does not use DNS or have some other weird application. > http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03. >txt > > Having a single ULID field would perhaps be more aligned with SHIM6. On > the other hand, the locator field could be just zeroes in this case. > How would you suggest to handle the opportunistic mode? Would you just > replace the ULID in sockaddr_shim with a routable IPv6 address? This you can do as well with the setsockopt and then just give a empty sockaddr_shim to the connect and other calls. Probably you we were anyway planning to give a sockaddr_shim where the ulid is empty in the case of opportunistic mode? > And > perhaps a hint for the resolver to automatize this procedure. However, > then we would end up again with redundantly routable addresses in the > list. > > Having both ULID and locator fields has the drawback of exposing the > application to a possibly outdated locator. Neverthless, this was > preferred in the applications area. They felt that we should define a low > level API that exposes everything to the application or higher level > network programming library. The HIT-IP mappings should not be hidden from > the application: > > http://www1.ietf.org/mail-archive/web/discuss/current/msg00533.html > http://www1.ietf.org/mail-archive/web/discuss/current/msg00520.html > http://www1.ietf.org/mail-archive/web/discuss/current/msg00546.html > http://www1.ietf.org/mail-archive/web/discuss/current/msg00537.html > http://www1.ietf.org/mail-archive/web/discuss/current/msg00497.html As I said in the mail I have probably missed something :-) Still I don't fully agree with the application guys. I would like to keep the design clean and do the setsockopt stuff for the geek's that want to have some kind of control of the locator. IMHO I think that in the generic case the application couldn't care less about the actual locator of the host. In the generic case the application and the user is more interested to whom it is talking to rather than where the application/user is located. Anyway, in case one of the peer hosts is mobile the HIT-IP mapping will hidden as soon as one of the peer host's moves. Or in case where the peer send's UPDATE packet giving new preferred locator. Or are you planning to make some new API for feeding the HIT-IP mapping updates to the application? > > If then again I would be a application that is interested both from ulids > > and addresses I would then give hints AF_UNSPEC which would then result a > > list containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None > > of the structs would contain duplicated data, if we take again the same > > example as earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x > > sockaddr_in. > > I have no strong objection against this, but it seems to conflict slightly > with the apps area folks views. The original idea of "endpoint descriptor" > was discarded because apps area folks wanted to expose everything to the > applications. > > I used the word "slightly" because it is still possible to do manual > locator handling in the application. If the application has only a single > ULID field and not locator field in sockaddr_shim, the application can > still query for the locators using a getsockopt() even before doing the > actual connection, It could even call setsockopt() to overwrite the > default peer locator before initial contact. I believe this would be more > aligned with the SHIM6 API draft. > > If there are no strong objections, we can go towards Jan's approach. It > just a matter whether we expose things in already in getaddrinfo() or > later in socket options. I'd appreciate comments from other folks as well. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 08:00:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXbjY-0003t4-7t; Tue, 18 Sep 2007 07:59:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXbjW-0003sv-0a for hipsec@ietf.org; Tue, 18 Sep 2007 07:59:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXbjR-0005Fg-4k for hipsec@ietf.org; Tue, 18 Sep 2007 07:59:13 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6D66E2D24; Tue, 18 Sep 2007 14:59:04 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EBBC22D16; Tue, 18 Sep 2007 14:58:53 +0300 (EEST) Date: Tue, 18 Sep 2007 14:58:53 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt In-Reply-To: <200709181333.07993.Jan.Melen@nomadiclab.com> Message-ID: References: <46EE7426.5070600@nomadiclab.com> <200709181333.07993.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 18 Sep 2007, Jan Mikael Melen wrote: Hi, >> I got your point now. You just want the ulid field and not the locator >> field. You are also implicitly suggesting that the resolver (or local DNS >> proxy) communicates the IP addresses matching to the HIP daemon as a side >> effect of HIT resolving as in the legacy API draft. > > You are already stating that in your draft in the figure 2 in section 3.3. Ah, good catch. The picture was based on older draft version. Anyway, I think I won't fix it until we resolve the issue locator vs. no locator issue. I am currently puzzled on how to proceed due to conflicting feedback. Perhaps others should voice out their opinions? > This you can do as well with the setsockopt and then just give a empty > sockaddr_shim to the connect and other calls. Works for me. > Probably you we were anyway planning to give a sockaddr_shim where the > ulid is empty in the case of opportunistic mode? Yes. Not really empty, but a ULID filled in with macro. > As I said in the mail I have probably missed something :-) Still I don't > fully agree with the application guys. I would like to keep the design > clean and do the setsockopt stuff for the geek's that want to have some > kind of control of the locator. IMHO I think that in the generic case > the application couldn't care less about the actual locator of the host. > In the generic case the application and the user is more interested to > whom it is talking to rather than where the application/user is located. True, especially in NATted environments. > Anyway, in case one of the peer hosts is mobile the HIT-IP mapping will > hidden as soon as one of the peer host's moves. Or in case where the > peer send's UPDATE packet giving new preferred locator. Or are you > planning to make some new API for feeding the HIT-IP mapping updates to > the application? See the SHIM6 API, section 6. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 08:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcPr-0001Fn-5B; Tue, 18 Sep 2007 08:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcPq-0001F4-D0 for hipsec@ietf.org; Tue, 18 Sep 2007 08:42:58 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcPk-00061I-1Q for hipsec@ietf.org; Tue, 18 Sep 2007 08:42:58 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8FE0A2D0F; Tue, 18 Sep 2007 15:42:51 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3F75B2D11; Tue, 18 Sep 2007 15:42:44 +0300 (EEST) Date: Tue, 18 Sep 2007 15:42:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jari Arkko In-Reply-To: <46EE7537.50503@piuha.net> Message-ID: References: <46EE5AF9.4070706@piuha.net> <46EE7537.50503@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: HIP , draft-ietf-hip-native-api@tools.ietf.org, Marcelo Bagnulo Braun Subject: [Hipsec] Re: review of draft-ietf-hip-native-api-02 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Jari Arkko wrote: Hi Jari, > Miika, > >> Not really because it has been just non-electoric discussions. > > Ok. Can you summarize then? Marcelo and Shinta, please correct me but I think that discussion has been never truly concluded. I recall that I suggested that the endpoint descriptor in 01 version draft might be useful for SHIM6 context forking. However, this debate is unnecessary now since I removed the whole concept of endpoint descriptors from the draft. >>> Anyway, what I see problematic from the point of >>> using for Shim6 is the following: >>> >>> - The resolution step does not distinguish ULIDs >>> from locators. >> >> ULIDs and locators have separate field in the sockaddr_shim structure. >> Please clarify? > > Yes, in your API. But in Shim6 there is no distinction. Of course. What do you think the proposal from Jan, i.e. having only the ULID field in the structure and no locator? >>> - Section 4.1 ULID comparison for Shim6 may >>> produce surprising results, given that >>> different connection attempts may result >>> in different ULIDs. >> >> This applies also to HITs as the application may receive multiple >> HITs. Please suggest text? > > I don't have a good suggestion. You may end up just > having to document the issue. Ok. >>> - I'm not sure how the deferred context creation >>> approach in Shim6 fits with this API. >>> >>> What's the role of this spec vs. the shim6 draft that you >>> have? >> >> Is this "rough" categorization helpful and should it be included in >> the draft? >> >> http://www1.ietf.org/mail-archive/web/hipsec/current/msg02222.html > > I think you said something along these lines in the draft already. > But I would like to see the current explanation expanded. Ok. >>> >>> I do not understand the difference. Please elaborate. >> >> Any means public or anonymous (perhaps this should be clarified?). >> Public and anonymous are described in the 03-pre2-version of the draft >> already: >> >> "In the case of HIP, anonymous identifiers refer to the anonymous >> identities in [RFC4423]. In the case of SHIM6, anonymous identifiers >> refer to the use of temporary IPv6 addresses as specified in [RFC3041]." > > Ok, I think. Ok. >>>> In both client and server based applications, the use of the >>>> SHIM_ANY* macro accepts also non-SHIM based communications to >>>> maximize backwards compatibility. When the application wants >>>> enforces the use of SHIM-based communications with ORCHID prefix >>>> [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags. >>>> Alternatively, the application accepts both ORCHID and non-ORCHID- >>>> based communications, but informs the difference e.g. to the user. >>>> In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro >>>> which inputs a pointer to a in6_addr and returns 1 when the address >>>> has orchid prefix and 0 otherwise. >>> >>> Is the use of Orchids the same or different issue from using >>> a Shim? I.e., do all Shims employ an Orchid? And if not, wouldn't >>> you want to enable/disable the use of non-shim communications >>> and Orchids separately? >> >> SHIM and Orchid are decoupled issues. The 03-pre2-version of the draft >> mentions: >> >> a) The flag AI_SHIM must be set, or otherwise the resolver does not >> return sockaddr_shim data structures. >> b) To distinguish between ORCHID [RFC4843] and non-ORCHID-based >> communications, it can call SHIM_IS_IPV6_ADDR_ORCHID macro. >> c) Alternatively, the application can set the flag SHIM_FLAG_ONLY_ORCHID >> in sshim_flags to allow only ORCHID-based communications. >> >> Should this be clarified? Suggest some text? >> > This is better, but let me ask a further question: how do > you control whether you want to talk to non-shim capable > hosts? Or is that in the draft-ietf-shim6-multihoming-api > draft? SHIM6 draft offers a "SHIM_DONTSHIM" socket option in section 5.2. We can use the same option for HIP. If AI_SHIM is not used, the extensions in the draft are not offered to the application. This situation is defined in the legacy HIP apps draft. The other way is to explicitly set the protocol either to IPPROTO_HIP or IPPROTO_SHIM6 in the resolver hints. With "0" protocol in the hints, I am not sure what to fill in the protocol field in the resolver output. Looking forward for some feedback on this issue. Particularly: is the IPPROTO_SHIM6 useful for SHIM6 at all? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 09:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcrG-0000ul-JC; Tue, 18 Sep 2007 09:11:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcrF-0000sT-3I for hipsec@ietf.org; Tue, 18 Sep 2007 09:11:17 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXcrE-0002Z4-Ax for hipsec@ietf.org; Tue, 18 Sep 2007 09:11:17 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D0FD02CEE; Tue, 18 Sep 2007 16:11:15 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D7DA32C27; Tue, 18 Sep 2007 16:11:07 +0300 (EEST) Date: Tue, 18 Sep 2007 16:11:07 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040497D0@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040497D0@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: HIP Subject: [Hipsec] Re: another review of draft-ietf-hip-native-api-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 17 Sep 2007, Henderson, Thomas R wrote: Hi Tom, > Hi Miika, > > Here are a few high-level comments, some of which have been touched upon > by other reviewers. > > My inclination would be to first describe what an API looks like that > modifies or extends the IPv6 API for HIP support only, and then later > consider whether and how it can be generalized to support other non-HIP > usage. The reason is that if you try to do the general solution first, > you may lose or obscure getting the HIP-specific concerns right. Right. > In a similar vein, I would like to see stated up front what are the > functional requirements or assumptions of this API. In particular, > before we get to syntactical issues, it should be more clear what name > or names (HIT, ORCHID, LSI, HI, RVS) the application is expected to deal > with, and what are the expected semantics of the API calls. As an > example, is the system expected to be able to handle the case when no > locator information is available in the connect call, or when there are > multiple locators, etc.? HITs and Orchids are already discussed in the draft. I don't see any reason to introduce the LSIs because the endpoint descriptor concept was also removed. HIs don't fit into socket address structures, so they should be polled using separate functions calls such as defined in the BTNS draft. I think the RVS vs. end-host locator type should be exposed to the application. I think we need an error value when there is no locator information (or an extra lookup returned nothing). With multiple locators, it is up to the system on whether sequentialize or parallelize I1 packets, but I think that is mostly an implementation issue, not an API issue. That is, unless we want to provide extra socket options for the application to set this explicitly. > We should also state what are the assumptions on policy that an > application may want to control. This seems to me to be underdeveloped > in the current draft; section 4.1 goes into some of this but I think > there are going to be more policy issues that need to be exposed. For > example, another possible option is to tell the system whether to > enforce the usage of HIP or whether to allow non-HIP communications if > the peer doesn't support HIP. The list is ordered so that HITs are in front of the list and routable addresses after it. The application either goes through the list sequentially (based on timeouts) or launches a parallel connections. In the latter case, it is up to the application to choose the fastest (usually non-SHIM) vs. securest (HIP) connection. Perhaps we should add some text regarding to this, but I am not sure yet what is the clearest way to do this (logic diagram, text or code examples). Contributions are welcome :) > Multihoming is also underdeveloped; I realize that there is a separate > shim6 multihoming API document which you are trying to leverage, but > again there probably are some dependencies to explore because that other > API draft, for instance, presumes that REAP is implemented, which is not > officially part of HIP. I think this is covered pretty much in the SHIM6 draft as you mentioned. The REAP related socket options should return an error when the protocol does not implement the corresponding feature. I think this could be added to the SHIM6 API draft directly. > We should also clarify more explicitly the assumptions and requirements > of how the resolver interacts differently with the system (for instance, > in Figure 2, the resolver/SHIM interaction steps d and e implies certain > assumptions on the sequence of events on how the pieces of the system > obtain binding information). This was also mentioned by Jan. The e. and d. arrows should not be in the draft as it is currently defined. However, I am looking for more feedback on the "mapping side effect" before I update the figure. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 12:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgKd-0005Rj-Tn; Tue, 18 Sep 2007 12:53:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgKd-0005Re-D6 for hipsec@ietf.org; Tue, 18 Sep 2007 12:53:51 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXgKc-0000V2-SZ for hipsec@ietf.org; Tue, 18 Sep 2007 12:53:51 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8IGrnQh001185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Sep 2007 11:53:49 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8IGrm44010532; Tue, 18 Sep 2007 09:53:48 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8IGrfso010219; Tue, 18 Sep 2007 09:53:46 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 09:53:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Tue, 18 Sep 2007 09:53:32 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040497D9@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Thread-Index: Acf5695AWM5nXg0CTNa63abOHwFuHAAC0FjQ From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 18 Sep 2007 16:53:40.0635 (UTC) FILETIME=[770366B0:01C7FA14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Tuesday, September 18, 2007 4:59 AM > To: Jan Mikael Melen > Cc: 'HIP WG' > Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt >=20 > On Tue, 18 Sep 2007, Jan Mikael Melen wrote: >=20 > Hi, >=20 > >> I got your point now. You just want the ulid field and not=20 > the locator > >> field. You are also implicitly suggesting that the=20 > resolver (or local DNS > >> proxy) communicates the IP addresses matching to the HIP=20 > daemon as a side > >> effect of HIT resolving as in the legacy API draft. > > > > You are already stating that in your draft in the figure 2=20 > in section 3.3. >=20 > Ah, good catch. The picture was based on older draft version.=20 > Anyway, I=20 > think I won't fix it until we resolve the issue locator vs.=20 > no locator=20 > issue. >=20 > I am currently puzzled on how to proceed due to conflicting feedback.=20 > Perhaps others should voice out their opinions? I would prefer Jan's suggestion because it seems cleaner/more explicit from a semantics standpoint to not bundle the identifier and locator into a giant sockaddr. I understand what you are trying to do to avoid requiring new socket calls or options, but I suspect it is not going to work out cleanly in the end due to multihoming, mobility, and NAT, as already mentioned. Plus, it seems counter to the HIP philosophy of shielding applications from having to know about locators (although I think everyone would agree that there is a requirement to give applications the option to specify locators if they want to). The downside to splitting them is that it either requires new setsockopts or new socket functions such as bindtoaddress() or sendtoaddress() where the argument is explicitly a sockaddr_in. Whether the function to add locator lists to the socket is a setsockopt or a new function call doesn't matter that much to me; I would be fine aligning it with whatever develops on the shim6 side of things. Regarding opportunistic mode, one could conceivably pass sockaddr_in6 in the connect() or sendto() of a HIP socket. That would probably work but may be less safe (prone to programming errors) if that is not what was really intended by the user. It may be cleaner to devise a general programming method that allows one to add, delete, and prioritize addresses that are associated with the localname and peername (HITs) of the socket, and use these calls everywhere, and just send to the SHIM_ANY (or HOST_ANY) address as the sockaddr if the application wants to invoke opportunistic mode. =20 Conversely, one could also design extensions to the AF_INET-based sockets to allow applications to use IP addresses at the socket calls and to set socket options to also associate host identities with the sockets, and use sockopt flags to invoke HIP. =20 >=20 > > As I said in the mail I have probably missed something :-)=20 > Still I don't=20 > > fully agree with the application guys. I would like to keep=20 > the design=20 > > clean and do the setsockopt stuff for the geek's that want=20 > to have some=20 > > kind of control of the locator. IMHO I think that in the=20 > generic case=20 > > the application couldn't care less about the actual locator=20 > of the host.=20 > > In the generic case the application and the user is more=20 > interested to=20 > > whom it is talking to rather than where the=20 > application/user is located. I think there is a distinction between exposing everything to the applications and overloading the existing function calls or structures to fit it all in within the existing set of functions. I support the former but I think it is better to do so by expanding the API. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 13:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXggk-0001Ei-Ro; Tue, 18 Sep 2007 13:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXggj-0001Ec-C8 for hipsec@ietf.org; Tue, 18 Sep 2007 13:16:41 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXggd-0004g3-7P for hipsec@ietf.org; Tue, 18 Sep 2007 13:16:41 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8IHGMQK017143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Sep 2007 12:16:22 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8IHGLB0026181; Tue, 18 Sep 2007 12:16:22 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8IHGL5J026145; Tue, 18 Sep 2007 12:16:21 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 10:16:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Sep 2007 10:15:30 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040497DA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AF_HOST or AF_ORCHID vs AF_SHIM Thread-Index: Acf59WZxnDhQswoSTKKzlxnfZusk7wAH22Ug From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 18 Sep 2007 17:16:15.0463 (UTC) FILETIME=[9E8DBF70:01C7FA17] X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: HIP WG Subject: [Hipsec] AF_HOST or AF_ORCHID vs AF_SHIM X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, One other comment is that it seems to me that we ought to distinguish between address family (namespace) and level in the stack where the function is applied (SHIM). The shim6 multihoming API draft uses SOL_SHIM but this is defined for the "level" field in the setsockopt and not the address family. So I don't think it would misalign things to use AF_HOST with SOL_SHIM, rather than AF_SHIM with SOL_SHIM. Two possible names to call this are AF_HOST or AF_ORCHID. I don't have a strong preference but would probably lean towards AF_HOST, because I am not sure whether ORCHIDs are thought to be part of AF_INET6 already, and because there has seemed to be some kind of experimental time limit on the use of the ORCHID prefix. =20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 18 23:21:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXq6e-0001JE-Rs; Tue, 18 Sep 2007 23:20:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXq6d-0001Ha-VV for hipsec@ietf.org; Tue, 18 Sep 2007 23:20:04 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXq6Y-0001Ac-KL for hipsec@ietf.org; Tue, 18 Sep 2007 23:19:58 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IXq6X-0003uY-2k; Tue, 18 Sep 2007 23:19:58 -0400 In-Reply-To: References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> <46EE7426.5070600@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <922ACF33-C926-4DA8-83B8-4FCCF3377848@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt Date: Tue, 18 Sep 2007 23:19:56 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > > If there are no strong objections, we can go towards Jan's > approach. It just a matter whether we expose things in already in > getaddrinfo() or later in socket options. I'd appreciate comments > from other folks as well. I think that there could easily be two or more locators associated with a HIT with no easy way to tell which one is the "best" or "primary". Furthermore, when NATs are involved, a locator will also include a encapsulation (e.g., UDP) and a port number. Also, a group of us are also investigating ways of finding a HIT by searching for it in an overlay, which suggests that the locator might be an OverlayID or similar. Jeffrey Arhenholz seems to be investigating similar ideas. It seems that these options would not be easily accommodated in your socket structure, and this suggests that socket options might be the better way to go. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 20 03:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYGav-0001NM-Vh; Thu, 20 Sep 2007 03:37:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYGau-0001Jq-L8 for hipsec@ietf.org; Thu, 20 Sep 2007 03:37:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYGas-0005m4-62 for hipsec@ietf.org; Thu, 20 Sep 2007 03:37:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 849D3210EA for ; Thu, 20 Sep 2007 09:37:01 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-e6-46f2231d0910 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 798E4210A6 for ; Thu, 20 Sep 2007 09:37:01 +0200 (CEST) Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:37:00 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ED4A02973 for ; Thu, 20 Sep 2007 10:09:31 +0300 (EEST) Message-ID: <46F21CAC.8010601@ericsson.com> Date: Thu, 20 Sep 2007 10:09:32 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Sep 2007 07:37:00.0715 (UTC) FILETIME=[07EF8FB0:01C7FB59] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Hipsec] Tool to submit Internet Drafts X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org FYI. Gonzalo From: "IETF Secretariat" Date: September 19, 2007 12:32:20 PM PDT To: "IETF Announcement list" Cc: , Subject: Deployment of the Internet-Draft Submission Tool Reply-To: The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Sep 20 03:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYGnb-0007hC-7G; Thu, 20 Sep 2007 03:50:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYGnZ-0007gl-Mq for hipsec@ietf.org; Thu, 20 Sep 2007 03:50:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYGnZ-00067O-3f for hipsec@ietf.org; Thu, 20 Sep 2007 03:50:09 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 90A76210AD; Thu, 20 Sep 2007 09:50:08 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-2f-46f22630cbb2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84D40210A0; Thu, 20 Sep 2007 09:50:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:50:08 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:50:07 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1429A2983; Thu, 20 Sep 2007 10:50:08 +0300 (EEST) Message-ID: <46F22630.7060806@ericsson.com> Date: Thu, 20 Sep 2007 10:50:08 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] NAT traversal design team References: <46E67E34.2090401@ericsson.com> In-Reply-To: <46E67E34.2090401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Sep 2007 07:50:07.0934 (UTC) FILETIME=[DD27A5E0:01C7FB5A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Folks, these will be the members of this design team: Hannes.Tschofenig@gmx.net thomas.r.henderson@boeing.com marcelo@it.uc3m.es jiang.x.f@huawei.com miika@iki.fi Jan.Melen@ericsson.com philip_matthews@magma.ca The design team will start working as soon as possible. Its members will be reporting periodically to this mailing list. Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > we would like to form a small design team to work on NAT traversal for > HIP, which, as you know, is one of our chartered work items. Design team > members will be expected to actively participate in conference calls and > may be required to write text for the draft. That is, if you want to > monitor the progress of this work, you do not need to be in the design > team. They will send periodic reports to the mailing list. On the other > hand, if you can commit cycles to actively work on this issue, you are > welcome to volunteer. > > The design team will take the three following drafts and the mailing > list discussions as its starting point. > > http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt > http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt > > If you want to volunteer, reply to this email (only to me; no need to > spam the list) letting me know. > > Thanks, > > Gonzalo > HIP co-chair > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Sep 23 21:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZczT-0005ZR-N8; Sun, 23 Sep 2007 21:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZczS-0005ZK-K0 for hipsec@lists.ietf.org; Sun, 23 Sep 2007 21:44:02 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZczL-00087G-VS for hipsec@lists.ietf.org; Sun, 23 Sep 2007 21:44:02 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOU00MSSNFNBF@szxga02-in.huawei.com> for hipsec@lists.ietf.org; Mon, 24 Sep 2007 09:42:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOU003N2NFMJS@szxga02-in.huawei.com> for hipsec@lists.ietf.org; Mon, 24 Sep 2007 09:42:58 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOU00JKMNFITB@szxml04-in.huawei.com> for hipsec@lists.ietf.org; Mon, 24 Sep 2007 09:42:58 +0800 (CST) Date: Mon, 24 Sep 2007 09:42:38 +0800 From: "John.zhao" Subject: RE:[Hipsec] NAT traversal design team In-reply-to: To: hipsec@lists.ietf.org Message-id: <006001c7fe4c$33c0ee40$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf0jPELCVh+fp4hQOujyKPvP10jlQJvqyeg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, Gonzalo May I ask you if I still can ask for joining in this design team? For some reason, I ignore this email until I just received that email you stated about the work starting of this design team. Maybe it isn't available. Anyway, I only try to volunteer to as this design team. Of course, if the time has past. No problem let's know. Thanks. Best Rgds, John.zhao > ------------------------------ > Date: Tue, 11 Sep 2007 14:38:28 +0300 > From: Gonzalo Camarillo > Subject: [Hipsec] NAT traversal design team > To: HIP > Message-ID: <46E67E34.2090401@ericsson.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Folks, > > we would like to form a small design team to work on NAT traversal for > HIP, which, as you know, is one of our chartered work items. Design team > members will be expected to actively participate in conference calls and > may be required to write text for the draft. That is, if you want to > monitor the progress of this work, you do not need to be in the design > team. They will send periodic reports to the mailing list. On the other > hand, if you can commit cycles to actively work on this issue, you are > welcome to volunteer. > > The design team will take the three following drafts and the mailing > list discussions as its starting point. > > http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt > http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt > > If you want to volunteer, reply to this email (only to me; no need to > spam the list) letting me know. > > Thanks, > > Gonzalo > HIP co-chair > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Sep 25 05:55:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia77m-0005zB-TV; Tue, 25 Sep 2007 05:54:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia77l-0005sX-CV for hipsec@ietf.org; Tue, 25 Sep 2007 05:54:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia77Y-0002U8-Ha for hipsec@ietf.org; Tue, 25 Sep 2007 05:54:24 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5196D212C52; Tue, 25 Sep 2007 12:54:22 +0300 (EEST) Received: from [193.234.219.70] (n70.nomadiclab.com [193.234.219.70]) by n2.nomadiclab.com (Postfix) with ESMTP id 1EE84212C4C; Tue, 25 Sep 2007 12:54:22 +0300 (EEST) Message-ID: <46F8DA9D.4000001@nomadiclab.com> Date: Tue, 25 Sep 2007 12:53:33 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt References: <200709051533.34704.julien.IETF@laposte.net> <46EE3F84.1080504@nomadiclab.com> <46EE7426.5070600@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, Miika Komu wrote: > If there are no strong objections, we can go towards Jan's approach. It > just a matter whether we expose things in already in getaddrinfo() or > later in socket options. I'd appreciate comments from other folks as well. I also agree with Jan and Philip that the socket options is a better way to do this. Yet, I think it is very important there is some (easy) way to define locators for HITs. Using HIT-locator pairs discovered from a P2P overlay is a good example where this kind of functionality is needed. -Ari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Sep 28 02:16:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib981-0000uA-FD; Fri, 28 Sep 2007 02:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib980-0000na-HY for hipsec@lists.ietf.org; Fri, 28 Sep 2007 02:15:08 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib97q-0005q0-9l for hipsec@lists.ietf.org; Fri, 28 Sep 2007 02:15:08 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8E6A32E33; Fri, 28 Sep 2007 09:14:42 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9F79B2C8D; Fri, 28 Sep 2007 09:14:34 +0300 (EEST) Date: Fri, 28 Sep 2007 09:14:34 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "John.zhao" Subject: RE:[Hipsec] NAT traversal design team In-Reply-To: <006001c7fe4c$33c0ee40$a864a8c0@china.huawei.com> Message-ID: References: <006001c7fe4c$33c0ee40$a864a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 24 Sep 2007, John.zhao wrote: Hi John, sorry for the delay. Unfortunately the design team is full. > Hi, Gonzalo > > May I ask you if I still can ask for joining in this design team? > For some reason, I ignore this email until I just received that email you > stated about the work starting of this design team. Maybe it isn't > available. Anyway, I only try to volunteer to as this design team. Of > course, if the time has past. No problem let's know. Thanks. > > Best Rgds, > John.zhao >> ------------------------------ >> Date: Tue, 11 Sep 2007 14:38:28 +0300 >> From: Gonzalo Camarillo >> Subject: [Hipsec] NAT traversal design team >> To: HIP >> Message-ID: <46E67E34.2090401@ericsson.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Folks, >> >> we would like to form a small design team to work on NAT traversal for >> HIP, which, as you know, is one of our chartered work items. Design team >> members will be expected to actively participate in conference calls and >> may be required to write text for the draft. That is, if you want to >> monitor the progress of this work, you do not need to be in the design >> team. They will send periodic reports to the mailing list. On the other >> hand, if you can commit cycles to actively work on this issue, you are >> welcome to volunteer. >> >> The design team will take the three following drafts and the mailing >> list discussions as its starting point. >> >> http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt >> http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt >> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >> >> If you want to volunteer, reply to this email (only to me; no need to >> spam the list) letting me know. >> >> Thanks, >> >> Gonzalo >> HIP co-chair >> > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec