From hipsec-bounces@lists.ietf.org Tue Oct 02 08:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchCX-00042s-6t; Tue, 02 Oct 2007 08:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IchCW-00042k-K2; Tue, 02 Oct 2007 08:50:12 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IchCW-000074-7E; Tue, 02 Oct 2007 08:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D2E9C26EAB; Tue, 2 Oct 2007 12:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IchCL-0000Fg-Oo; Tue, 02 Oct 2007 08:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 02 Oct 2007 08:50:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-base-09.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-09.txt Pages : 105 Date : 2007-10-02 This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, such as TCP and UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-02084807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-02084807.I-D\@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From hipsec-bounces@lists.ietf.org Wed Oct 03 06:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1BW-0003AL-Nb; Wed, 03 Oct 2007 06:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1BV-00039n-7W for hipsec@ietf.org; Wed, 03 Oct 2007 06:10:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id1BL-0007K5-VS for hipsec@ietf.org; Wed, 03 Oct 2007 06:10:26 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 30796204D9; Wed, 3 Oct 2007 12:10:09 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-ee-47036a81f961 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1EABD203FE; Wed, 3 Oct 2007 12:10:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 12:10:08 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 12:10:08 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A60AF2442; Wed, 3 Oct 2007 13:10:08 +0300 (EEST) Message-ID: <47036A80.9010007@ericsson.com> Date: Wed, 03 Oct 2007 13:10:08 +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: 03 Oct 2007 10:10:08.0399 (UTC) FILETIME=[9397A1F0:01C805A5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Hipsec] API draft 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, as you know, we are chartered to describe a native API for HIP. The current draft is the following: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt The current title of this draft is "Native Application Programming Interfaces for SHIM APIs". We have discussed the fact that this title is very general and covers more than HIP with our ADs. We have concluded that the API we describe in the HIP WG should focus on HIP. It is OK to align it as much as possible with other protocols such as shim6, but the draft should include a paragraph along the following lines with respect to its scope: "Note that the API specified in this document is specific to HIP. However, this API has been designed keeping generality in mind as much as possible so as not to preclude its use with other protocols. The use of this API with other protocols is, nevertheless, for further study." The title of the draft should, of course, also reflect its limited scope: Native Application Programming Interfaces for HIP Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Oct 03 08:41:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3X9-0000MM-Li; Wed, 03 Oct 2007 08:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3X7-0000L4-Ve for hipsec@ietf.org; Wed, 03 Oct 2007 08:40:57 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3X6-0003BI-54 for hipsec@ietf.org; Wed, 03 Oct 2007 08:40:57 -0400 Received: from [IPv6:2001:380:633:2:20b:cdff:fefb:2a8] (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 58BEE4D951 for ; Wed, 3 Oct 2007 21:40:35 +0900 (JST) Message-ID: <47038DC2.5060402@sfc.wide.ad.jp> Date: Wed, 03 Oct 2007 21:40:34 +0900 From: Shinta Sugimoto User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Subject: [Hipsec] comments on 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 and all, Let me send my comments on draft-ietf-hip-native-api-02.txt. I amware that there have been many discussions about the draft and I went through the all emails posted on the ML. Hope that I am not writing things that have already been discussed/ resolved. At first, I'd like to mention that I am the editor of another API draft which is being worked in the SHIM6 WG: draft-ietf-shim6-multihome-shim-api-03 (hereafter, I call this draft "multihome shim API"). The multihome shim API draft aims to define a common set of socket API extensions that are useful for applications that run in a multihomed environment. So, the scope of the draft ranges in multihoming capability of HIP and SHIM6. More specifically, the common set are about locator management and control of failure detection. To put it in the other way, anything specific to each protocol should be eliminated from the multihome shim API draft. In the light of this, we should try to align the two API documents (Miika's draft and multihome shim API draft) each other. At least, the two documents should not be contradicting each other. Duplication should be avoided. My comments: - To me, the goals and objectives of the document were not clear. I mean, I could not understand what are unique properties of HIP aware application from the document. Maybe I am missing something but I think it should be quite easy for reader to understand. My suggestion is to put a new section between Section 2 and 3, stating the goals and objectives of the draft. - As Thomas suggested, I think it would be better to design the API specific to HIP. To me, the scope of the draft seems to be too broad. I don't think the newly defined API is useful for SHIM6 scenario because the design of SHIM6 is based on the assumption that the identifier is chosen from locator, i.e., the namespace of identifier is identical to that of locator. - Section 4.1: I found it difficult to understand the reason behind the design of the sockaddr_shim data structure. More specifically, I could not see why identifier and locator need to be packed in a single data structure. (I realized that this issue has been resolved) - Section 4.2: I have some detailed comments. Please find them inline: > 4.2. Resolver > > The SHIM API uses the getaddrinfo resolver function which the > application uses to query both ULIDs and locators. The resolver > introduces a new data structure, which is used both as the input and > output argument for the resolver. The addrinfo data structure is not new, so the above sentence sounds misleading. > The data structure is illustrated > in Figure 4. > > 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, such > as 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. 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. > > 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. The document should specify what error (EAI_???) should be returned if a requested protocol is not available on the system. > > ai_addrlen is the size of the structure pointed by ai_addr. > > 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]. > > > > Komu Expires January 8, 2008 [Page 8] > > Internet-Draft Native SHIM APIs July 2007 > > > 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(). What about gethostbyname() and getservbyname()? > 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 above paragraph gives general explanation of getaddrinfo. Maybe it would be more helpful to provide implications of the use of getaddrinfo by the HIP aware application. For instance, suppose a server program calls getaddrinfo. To my knowledge, typical server program specifies AI_PASSIVE flag in hints->ai_flags, and the returned values will be the unspecified addresses (e.g. 0.0.0.0 in IPv4 case). But in a HIP aware server case, what should be the result of getaddrinfo? I suppose only HIT(s) should be returned even if AI_PASSIVE is specified. Or simultaneous use of AI_PASSIVE and AI_SHIM is prohibited? > 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. Wouldn't it be more efficient to introduce a new flag in ai_flags rather than setting SHIM_ANY_ANON flag in a sockaddr_shim data structure? > > The output argument res is dynamically allocated by the resolver. > The application must free 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. > > 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. (the rest of the draft is snipped) Regards, Shinta _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Oct 29 15:23: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 1ImaCI-0005W0-Jv; Mon, 29 Oct 2007 15:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImaCH-0005U0-5P for hipsec@ietf.org; Mon, 29 Oct 2007 15:22:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ima9t-0000w1-GY for hipsec@ietf.org; Mon, 29 Oct 2007 15:22:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C2B2A2EA1; Mon, 29 Oct 2007 21:20:10 +0200 (EET) 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 671A52E73; Mon, 29 Oct 2007 21:20:03 +0200 (EET) Date: Mon, 29 Oct 2007 21:20:03 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo In-Reply-To: <47036A80.9010007@ericsson.com> Message-ID: References: <47036A80.9010007@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: HIP Subject: [Hipsec] Re: API draft 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, 3 Oct 2007, Gonzalo Camarillo wrote: Hi, > Folks, > > as you know, we are chartered to describe a native API for HIP. The current > draft is the following: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt > > The current title of this draft is "Native Application Programming Interfaces > for SHIM APIs". We have discussed the fact that this title is very general > and covers more than HIP with our ADs. We have concluded that the API we > describe in the HIP WG should focus on HIP. It is OK to align it as much as > possible with other protocols such as shim6, but the draft should include a > paragraph along the following lines with respect to its scope: > > "Note that the API specified in this document is specific to HIP. However, > this API has been designed keeping generality in mind as much as possible so > as not to preclude its use with other protocols. The use of this API with > other protocols is, nevertheless, for further study." > > The title of the draft should, of course, also reflect its limited scope: > Native Application Programming Interfaces for HIP the feedback for the draft is here: http://www1.ietf.org/mail-archive/web/hipsec/current/msg02250.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02224.html I believe that I have addressed all of the comments in the next preversion of the draft: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre3.txt A quick summary of the changes: * The locator was removed from the HIT data structure * Replaced SHIM generalization with just "HIP" * Dependencies to SHIM6 removed and/or referenced better now * AI_PASSIVE clafications; added AI_PASSIVE_PUB and AI_PASSIVE_ANON * Added HIP_IS_IPV6_ADDR_ANON_HIT macro * Comments on hostname mapping to multiple HITs * Comments on HIT mapping to multiple locators * Rewording and hopefully better explanations Thanks for the reviewers and looking forward for further comments. -- 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 Oct 30 07:40: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 1ImpS8-0008AY-J9; Tue, 30 Oct 2007 07:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImpS6-0007vk-Sa; Tue, 30 Oct 2007 07:40:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImpS6-0006oo-Fq; Tue, 30 Oct 2007 07:40:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 56D7026EE8; Tue, 30 Oct 2007 11:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ImpRy-0005ND-8S; Tue, 30 Oct 2007 07:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 30 Oct 2007 07:40:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-base-10.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-10.txt Pages : 108 Date : 2007-10-30 This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, such as TCP and UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-30073315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-30073315.I-D\@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From hipsec-bounces@lists.ietf.org Wed Oct 31 07:45: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 1InBzp-0002hV-RS; Wed, 31 Oct 2007 07:44:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBzl-0002gU-T1 for hipsec@ietf.org; Wed, 31 Oct 2007 07:44:25 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InBzj-0000Ac-68 for hipsec@ietf.org; Wed, 31 Oct 2007 07:44:23 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6C004208C0; Wed, 31 Oct 2007 12:44:22 +0100 (CET) X-AuditID: c1b4fb3c-ae67bbb0000007e1-f1-47286a96b8dc Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 53433203A5; Wed, 31 Oct 2007 12:44:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 12:44:21 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 12:44:21 +0100 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4CB332462; Wed, 31 Oct 2007 13:44:21 +0200 (EET) Message-ID: <47286A95.5000102@ericsson.com> Date: Wed, 31 Oct 2007 13:44:21 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miika Komu References: <47036A80.9010007@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2007 11:44:21.0533 (UTC) FILETIME=[60B06CD0:01C81BB3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: HIP Subject: [Hipsec] Re: API draft 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, thanks for putting this together. It would be great if the original reviewers of this draft could have a look at this new revision and let the mailing list know whether or not their comments have been properly addressed. Regarding my comments below, note that you have rephrased the text I suggested and have introduced a few language problems when doing it. Cheers, Gonzalo Miika Komu wrote: > On Wed, 3 Oct 2007, Gonzalo Camarillo wrote: > > Hi, > >> Folks, >> >> as you know, we are chartered to describe a native API for HIP. The >> current draft is the following: >> >> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt >> >> The current title of this draft is "Native Application Programming >> Interfaces for SHIM APIs". We have discussed the fact that this title >> is very general and covers more than HIP with our ADs. We have >> concluded that the API we describe in the HIP WG should focus on HIP. >> It is OK to align it as much as possible with other protocols such as >> shim6, but the draft should include a paragraph along the following >> lines with respect to its scope: >> >> "Note that the API specified in this document is specific to HIP. >> However, this API has been designed keeping generality in mind as much >> as possible so as not to preclude its use with other protocols. The >> use of this API with other protocols is, nevertheless, for further >> study." >> >> The title of the draft should, of course, also reflect its limited >> scope: Native Application Programming Interfaces for HIP > > the feedback for the draft is here: > > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02250.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02224.html > > I believe that I have addressed all of the comments in the next > preversion of the draft: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre3.txt > > A quick summary of the changes: > > * The locator was removed from the HIT data structure > * Replaced SHIM generalization with just "HIP" > * Dependencies to SHIM6 removed and/or referenced better now > * AI_PASSIVE clafications; added AI_PASSIVE_PUB and AI_PASSIVE_ANON * > Added HIP_IS_IPV6_ADDR_ANON_HIT macro > * Comments on hostname mapping to multiple HITs > * Comments on HIT mapping to multiple locators > * Rewording and hopefully better explanations > > Thanks for the reviewers and looking forward for further comments. > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec