From hipsec-bounces@lists.ietf.org Thu Nov 01 07:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InY7F-00074w-TJ; Thu, 01 Nov 2007 07:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InY7F-00074r-Fy for hipsec@ietf.org; Thu, 01 Nov 2007 07:21:37 -0400 Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InY78-0004oT-Fb for hipsec@ietf.org; Thu, 01 Nov 2007 07:21:37 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69D041EF7DA; Thu, 1 Nov 2007 13:21:24 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:212:3fff:fe16:205b] (unknown [IPv6:2001:14b8:400:101:212:3fff:fe16:205b]) by n2.nomadiclab.com (Postfix) with ESMTP id 37B701EF1A4; Thu, 1 Nov 2007 13:21:24 +0200 (EET) Message-ID: <4729B6B5.2030607@nomadiclab.com> Date: Thu, 01 Nov 2007 13:21:25 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Re: API draft References: <47036A80.9010007@ericsson.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: -1.4 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, It was a bit unclear to me from the latest revision of the draft (03-pre3) how the application can now create a HIT to locator mapping in case they are found by some other means than DNS. Is the idea now to use shim6-multihome-shim-api-03 draft's setsockopt with SHIM_LOC_PEER_PREF or similar? I guess that's in line with the discussion we had earlier but I'd rather see it stated more explicitly. Then some minor issues and nits (they are in the order as they appear in the draft): The wrong definition of Locator is still in the Table 1 (now it's defined twice). The draft text and the Figure 3 aren't consistent. In the text (before the figure) you have "hip_family", "sins_port" and "sins_hit", while in the Figure 3 they are apparently called "ship_family", "ship_port" and "ship_hit". Is the definition of "hip_locator_t" in the Figure 3 needed anymore? If it is, perhaps it should be in the summary table (Table 3) too. "The application can HIP_HIT_ " s/can/can use the/ "The ai_family field is set to AF_HIP the addrinfo structure when" s/AF_HIP the/AF_HIP in the/ Also, in the comments of the struct it says that the value could be e.g., PF_HIP. It might be better to use either AF or PF consistently. -Ari Miika Komu wrote: > 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 From hipsec-bounces@lists.ietf.org Fri Nov 09 17:18: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 1IqcBe-0000dV-P1; Fri, 09 Nov 2007 17:18:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqcBd-0000by-CL for hipsec@ietf.org; Fri, 09 Nov 2007 17:18:49 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqcBc-0007fD-Tm for hipsec@ietf.org; Fri, 09 Nov 2007 17:18:49 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A381B2D92; Sat, 10 Nov 2007 00:18:47 +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 2F8312D89; Sat, 10 Nov 2007 00:18:40 +0200 (EET) Date: Sat, 10 Nov 2007 00:18:40 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [Hipsec] Re: API draft In-Reply-To: <4729B6B5.2030607@nomadiclab.com> Message-ID: References: <47036A80.9010007@ericsson.com> <4729B6B5.2030607@nomadiclab.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-1194646720=:15457" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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-342241519-1194646720=:15457 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Thu, 1 Nov 2007, Ari Ker=E4nen wrote: Ari, appreciate your comments. Some comments below. > Hi Miika, > > It was a bit unclear to me from the latest revision of the draft (03-pr= e3)=20 > how the application can now create a HIT to locator mapping in case the= y are=20 > found by some other means than DNS. Is the idea now to use=20 > shim6-multihome-shim-api-03 draft's setsockopt with SHIM_LOC_PEER_PREF = or=20 > similar? I guess that's in line with the discussion we had earlier but = I'd=20 > rather see it stated more explicitly. When the application implements its own locator policies, it can control=20 the locators bindings with SHIM_LOC_PEER_PREF socket option as defined in= =20 [I-D.ietf-shim6-multihome-shim-api]. > Then some minor issues and nits (they are in the order as they appear i= n the=20 > draft): > > The wrong definition of Locator is still in the Table 1 (now it's defin= ed=20 > twice). Now it is: | Locator | Routable IPv4 or IPv6 address used at the lower layers | > > The draft text and the Figure 3 aren't consistent. In the text (before = the=20 > figure) you have "hip_family", "sins_port" and "sins_hit", while in the= =20 > Figure 3 they are apparently called "ship_family", "ship_port" and=20 > "ship_hit". Fixed. > Is the definition of "hip_locator_t" in the Figure 3 needed anymore? If= it=20 > is, perhaps it should be in the summary table (Table 3) too. > > "The application can HIP_HIT_ " > s/can/can use the/ > > "The ai_family field is set to AF_HIP the addrinfo structure when" > s/AF_HIP the/AF_HIP in the/ > Also, in the comments of the struct it says that the value could be e.g= .,=20 > PF_HIP. It might be better to use either AF or PF consistently. Fixed. The next preversion of the draft is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre4.txt --=20 Miika Komu http://www.iki.fi/miika/ ---559023410-342241519-1194646720=:15457 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-342241519-1194646720=:15457-- From hipsec-bounces@lists.ietf.org Sat Nov 10 00:51: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 1IqjFs-00079B-Af; Sat, 10 Nov 2007 00:51:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqjFq-00078d-Q0 for hipsec@ietf.org; Sat, 10 Nov 2007 00:51:38 -0500 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 1IqjFl-0004Ng-UW for hipsec@ietf.org; Sat, 10 Nov 2007 00:51:38 -0500 Received: from [192.168.1.100] (softbank219197236013.bbtec.net [219.197.236.13]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AA3CE4D8A8; Sat, 10 Nov 2007 14:51:30 +0900 (JST) Date: Sat, 10 Nov 2007 14:51:09 +0900 From: Shinta Sugimoto To: Miika Komu Subject: Re: [Hipsec] Re: API draft In-Reply-To: References: <47036A80.9010007@ericsson.com> Message-Id: <20071110141206.88D6.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 2.1 (++) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 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, Thank you for updating the draft. I checked it and I am basically fine with the content of the draft. There are some minor comments (mostly editorial). Please find them inline: > Host Identity Protocol M. Komu > Internet-Draft Helsinki Institute for Information > Intended status: Informational Technology > Expires: May 1, 2008 October 29, 2007 > > > Native Application Programming Interfaces (APIs) for Host Identity > Protocol (HIP) > draft-ietf-hip-native-api-03 > (snip) > Abstract > > This document defines extensions to the current sockets API for Host > Identity Protocol (HIP). The extensions focus on the initial > discovery of public-key based identifiers. Using the extensions, the > application can verify that the identifier is a Host Identity Tag > > > > Komu Expires May 1, 2008 [Page 1] > > Internet-Draft Native APIs for HIP October 2007 > > > (HIT) and it can require the system resolver to return only HITs from > DNS. The application can also to explicitly allow more relaxed > security models where the communication can be non-HIP based in the > absence of a peer identifiers, or that the application allows peer > identity to be discovered after initial contact directly with the > peer. > > > Table of Contents > > 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. Design Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. Layering Model . . . . . . . . . . . . . . . . . . . . . . 4 > 3.2. Namespace Model . . . . . . . . . . . . . . . . . . . . . 5 > 3.3. Interaction with the Resolver . . . . . . . . . . . . . . 5 > > 4. API Syntax and Semantics . . . . . . . . . . . . . . . . . . . 6 > 4.1. Socket Family and Address Structure Extensions . . . . . . 7 > 4.2. Resolver Extensions . . . . . . . . . . . . . . . . . . . 8 > > 5. Summary of New Definitions . . . . . . . . . . . . . . . . . . 10 > > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 > > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 > > 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 > > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 > Intellectual Property and Copyright Statements . . . . . . . . . . 14 > (snip) > > Komu Expires May 1, 2008 [Page 2] > > Internet-Draft Native APIs for HIP October 2007 > > > 1. Terminology > > The terms used in this document are summarized in Table 1. > > +---------+---------------------------------------------------------+ > | Term | Explanation | > +---------+---------------------------------------------------------+ > | HIP | Host Identity Protocol | > | Locator | Non-routable IPv4 or IPv6 address used at the lower | > | | layers | s/Non-routable/Routable/ > | FQDN | Fully Qualified Domain Name | I guess abbreviation of FQDN is widely known. > | HIT | Host Identity Tag, a 100-bit hash of a public key with | > | | a 28 bit prefix | > | LSI | Local Scope Identifier, a local, 32-bit descriptor for | > | | a given public key. | > | Locator | Routable IPv4 or IPv6 address | > +---------+---------------------------------------------------------+ definition of "Locator" is given twice in the table. > > Table 1 > > > 2. Introduction > > The Host Identity Protocol (HIP) [RFC4423] proposes a new > cryptographic namespace by separating the roles of end-point > identifiers and locators by introducing a new "SHIM" layer to the > TCP/IP stack. SHIM6 [I-D.ietf-shim6-proto] is another protocol based > on identity-locator split. The API specified in this document is > specific to HIP but it has been designed keeping generality in mind > as much as possible so as not to preclude compatibility with other > protocols. The use of this API in the context with other protocols > is, nevertheless, for further study. > > Applications can observe the HIP layer and its identifiers in the > networking stacks with varying degrees of visibility. > [I-D.henderson-hip-applications] discusses the lowest levels of > visibility in which applications are completely unaware of underlying > the HIP layer. Such HIP-unaware applications use HIP-based > identifiers, such as LSIs or HITs, instead of IPv4 or IPv6 addresses > and cannot observe the identifier-locator bindings. > > This document defines C-based sockets API extensions for handling > HIP-based identifiers explicitly in HIP-aware applications. It is up > to the applications, or a high-level programming languages or > libraries, to manage the identifiers. The extensions in this > document are mainly related to the initial discovery of the > identifiers, i.e., DNS resolution step. > > > > > Komu Expires May 1, 2008 [Page 3] > > Internet-Draft Native APIs for HIP October 2007 > > > The API extensions introduce a new address family, AF_HIP, and a new > socket address structure for sockets using Host Identity Tags (HITs) > explicitly. PF_HIP is used as an alias for AF_HIP in this document > because the distinction between PF and AF has been lost in the > practice. > > 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" as > described later in this document. > > There are two related API documents. Multihoming and explicit > locator-handling related APIs are defined in > [I-D.ietf-shim6-multihome-shim-api]. IPsec related policy attributes > and channel bindings APIs are defined in [I-D.ietf-btns-c-api]. The > extensions defined in this document can be used independently of the > two mentioned related API documents. > > To recap, the extensions in this document have two goals. First goal > is to allow HIP-aware applications to resolve HITs explicitly. > Second goal is to allow an application to explicitly accept > communications with an unknown peer identifier. > > > 3. Design Model > > In this section, the native HIP APIs design is described from a > design point of view. We describe the layering and namespace models. > We conclude the discussion with a description of the resolver 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 HIP APIs 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. > > > > > > > > > > > > > Komu Expires May 1, 2008 [Page 4] > > Internet-Draft Native APIs for HIP October 2007 > > > +--------------------------------+ > Application Layer | Application | > +----------+----------+----------+ > Socket Layer | IPv4 API | IPv6 API | HIP API | > +----------+----+-----+----------+ > Transport Layer | TCP | UDP | > +---------------+----------------+ > HIP Layer | HIP | > +---------------+----------------+ > Network Layer | IPv4 | IPv6 | > +---------------+----------------+ > Link Layer | Ethernet | Etc | > +---------------+----------------+ > > Figure 1 > > The HIP layer is as a shim/wedge layer between the transport and > network layers. The datagrams delivered between the transport and > network layers are intercepted by the HIP layer for transformation > from from identifiers to locators or vice versa. > > 3.2. Namespace Model > > The namespace model is shown in Table 2 from HIP point of view. The > namespace identifiers are described in this section. > > +-------------------+---------------------------+ > | Layer | Identifier | > +-------------------+---------------------------+ > | User Interface | Relative hostname or FQDN | > | Application Layer | HIT, port and protocol | > | Transport Layer | HIT, port | > | HIP Layer | HIT or HI | > | Network Layer | Locator | > +-------------------+---------------------------+ > > Table 2 > > User interfaces input human-readable names and translate them to > machine-readable names. In native APIs for HIP, the machine readable > names are HITs. The HITs are present at the application layer, and > transport-layer pseudo checksums are based on HITs. The HIP layer > transforms the HITs to locators for the network layer and vice versa. > > 3.3. Interaction with the Resolver > > Before an application can establish network communications with the > entity named by a given FQDN or relative host name, the application > > > > Komu Expires May 1, 2008 [Page 5] > > Internet-Draft Native APIs for HIP October 2007 > > > must translate the 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 a list of HITs and a set of > locators (step c.). Optionally (in step d.), the resolver caches the > HIT to locator mapping to the HIP module. The resolver returns the > HITs to the application in step e. Finally, the application selects > one HIT and uses it in a socket call such as connect() in step e. > > +----------+ > | | > | DNS | > | | > +----------+ > ^ | > b. | | c. | v = HITs+locs> > +-------------+ a. getaddrinfo() +----------+ > | |------------------------>| | > | Application | | Resolver | > | |<------------------------| | > +-------------+ e. +----------+ > | | > | | > | f. connect() | d. > v v > +----------+ +----------+ > | | | | > | Stack | | HIP | > | | | | > +----------+ +----------+ s/Stack/TCP\/IP Stack/ > > Figure 2 > > In practice, the resolver functionality can implemented in different s/can/can be/ > ways. For example, it may be implemented in existing resolver > libraries or as a DNS proxy. > > > 4. API Syntax and Semantics > > In this section, we describe the native HIP APIs using the syntax of > the C programming language. We limit the description to the > interfaces and data structures that are either modified or completely > new, because the native HIP APIs is otherwise identical to the s/is/are/ > sockets API [POSIX]. when you refer to "API" in the document, I think singular form is more suitable. > > > > > > Komu Expires May 1, 2008 [Page 6] > > Internet-Draft Native APIs for HIP October 2007 > > > 4.1. Socket Family and Address Structure Extensions > > The sockets API extensions define a new protocol family, PF_HIP, and > a new address family, AF_HIP. The AF_HIP and PF_HIP are aliases to > each other. The use of the PF_HIP constant is mandatory with the > socket() function when application uses the native HIP APIs. The > application gives the PF_HIP constant as the first argument (domain) > to the socket() function. > > The application can also use the new AF_HIP family to detect HIP > support in the local host. Namely, the application creates a socket > by calling socket() function with the first argument (domain) as > AF_HIP. The system returns a positive integer representing a socket > descriptor when the system supports HIP. Otherwise, the system > returns -1 and sets errno to EAFNOSUPPORT. > > A HIT is contained in a sockaddr_hip structure, which is shown in > Figure 3. The family of the socket, hip_family, is set to PF_HIP. > The port number sins_port is two octets and the sins_hit is four > octets. The HIT value is an IPv6 address and it is stored in network > byte order. > > #include > > typedef struct in6_addr hip_hit_t; > typedef struct in6_addr hip_locator_t; > > struct sockaddr_hip { > uint8_t ship_len; > uint8_t ship_family; > uint16_t ship_port; > uint64_t ship_flags; > hip_hit_t ship_hit; > uint8_t reserved[16]; > } > > Figure 3 > > The application usually sets the ship_hit field using the resolver. > However, the application can use three special wildcard macros to set > a value directly into the ship_hit field. The macros are > HIP_HIT_ANY, HIP_HIT_ANY_PUB and HIP_HIT_ANY_ANON. They denote a HIT > value associated with a wildcard HIT of any, public, or anonymous > type. The HIP_HIT_ANY means HIP_HIT_ANY_PUB or HIP_HIT_ANY_ANON. > The anonymous identifiers refer to the use anonymous identifiers as > specified in [RFC4423]. > > The application can use macro HIP_IS_IPV6_ADDR_ANON_HIT to verify > > > > Komu Expires May 1, 2008 [Page 7] > > Internet-Draft Native APIs for HIP October 2007 > > > whether a HIT is anonymous or public. The macro inputs a pointer to > a hip_hit_t structure and returns an integer (int) set to one when > the corresponding HIT is anonymous and zero when it is public. The > macro returns -1 when the anonymity status is not available. > > The application can HIP_HIT_ macros to accept incoming communications > to all of the HITs of the local host. Incoming communications refers > here to the functions such as bind(), recvfrom() and recvmsg(). The > HIP_HIT_ macros correspond to the sockets API macros INADDR_ANY and > IN6ADDR_ANY_INIT, but they are applicable at the HIP layer. After > initial contact with the peer, the local and peer HITs can be > discovered using getsockname() and getpeername() calls for connection > oriented sockets. > > The application uses also the the HIP_HIT_ANY macro in ship_hit field s/uses also/also uses/ > to establish outgoing communications in Opportunistic mode > [I-D.ietf-hip-base], when the application knows the remote peer > locator but not the HIT. Outgoing communications refers here to the > use of functions such as connect(), sendto() and sendmsg(). After > initial contact with the peer, the local and peer HITs can be > discovered using getsockname() and getpeername() calls for > connection-oriented sockets. > > The HIP_HIT_ANY_ macros allow also non-ORCHID based communications to s/allow also/also allow/ > maximize backwards compatibility. To distinguish between ORCHID > [RFC4843] and non-ORCHID-based communications, it can call > HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a pointer to an > in6_addr structure and returns 1 when the address has orchid prefix > and 0 otherwise. Alternatively, the application can set the flag > HIP_FLAG_ONLY_ORCHID in ship_flags to allow only ORCHID-based > communications. > > Applications can also implement access control using the HITs. In > such a case, the application can compare two HITs using memcmp() or > similar function. It should be noticed that different connection > attempts between the same two hosts can result in different HITs > because a host is allowed to have multiple HITs. > > 4.2. Resolver Extensions > > The HIP API introduces a new addrinfo flag, AI_HIP, to be used by > application to query for both HIT and locator information via the > getaddrinfo() resolver function [RFC3493]. The getaddrinfo() > function uses a data structure used for both input to and output from > the resolver. The data structure is illustrated in Figure 4. > > > > > > > Komu Expires May 1, 2008 [Page 8] > > Internet-Draft Native APIs for HIP October 2007 > > > #include > > struct addrinfo { > int ai_flags; /* e.g. AI_HIP */ > int ai_family; /* e.g. PF_HIP */ > int ai_socktype; /* e.g. SOCK_STREAM */ > int ai_protocol; /* 0 or IPPROTO_HIP */ > size_t ai_addrlen; /* size of *ai_addr */ > struct sockaddr *ai_addr; /* sockaddr_hip */ > char *ai_canonname; /* canon. name of the host */ > struct addrinfo *ai_next; /* next endpoint */ > }; > > Figure 4 > > The flag AI_HIP must be set to the ai_flags, or otherwise the > resolver does not return sockaddr_hip data structures. The > simultaneous use of both AI_HIP and AI_PASSIVE flags equals to the > use HIP_HIT_ANY macro as described in section Section 4.1. > Similarly, the use of AI_PASSIVE_PUB and AI_PASSIVE_ANON flag equals > to the use of HIP_HIT_ANY_PUB and HIP_HIT_ANY_ANON. maybe you had better provide a table which enumerates the newly defined ai_flags for HIP with brief explanation (rather than showing everything in Table 3). > > The ai_family field is set to AF_HIP the addrinfo structure when > ai_addr points to a sockaddr_hip structure. > > When ai_protocol field is set to zero, the resolver returns also s/returns also/also returns/ > locators in sockaddr_in and sockaddr_in6 structures in addition to > sockaddr_hip structures. The resolver returns only sockaddr_hip s/returns only/only returns/ > structures when ai_protocol field is set to IPPROTO_HIP or a > sockaddr_hip structure is given as the hint argument to the resolver. > > A HIP-aware application creates the sockaddr_hip structures manually > or obtains them from the resolver. The manual configuration is > described in [I-D.ietf-shim6-proto]. This document defines resolver > extensions for getaddrinfo resolver [RFC3493]. > > #include > > 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 > > > > Komu Expires May 1, 2008 [Page 9] > > Internet-Draft Native APIs for HIP October 2007 > > > 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 s/acts/act/ > attributes required from the resolved endpoints. A NULL hints > argument indicates that any kind of endpoints are acceptable. > > 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_hip structures only when the input > argument has the AI_HIP flag set. The resolver inserts HITs before > any locators. > > Resolving of a hostname can result in a HIT which maps to multiple s/Resolving of/Resolution of/ > locators. The resolver may cache the locator mappings to the HIP > module. The HIP module manages the multiple locators according to > local policies of the host. When the application implements its own > locator policies, it can control the locators bindings with the > extensions defined in [I-D.ietf-shim6-proto]. should be [I-D.ietf-shim6-multihome-shim-api], instead of [I-D.ietf-shim6-protocol]. That's it from me. Hope it helps. Regards, Shinta _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Nov 11 09:51: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 1IrEAG-0005L2-60; Sun, 11 Nov 2007 09:51:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrEAE-0005Jv-GT for hipsec@ietf.org; Sun, 11 Nov 2007 09:51:54 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrEAE-0002pC-7B for hipsec@ietf.org; Sun, 11 Nov 2007 09:51:54 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 850C420502 for ; Sun, 11 Nov 2007 15:51:53 +0100 (CET) X-AuditID: c1b4fb3c-ae67bbb0000007e1-cb-473717093b7a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F9922042E for ; Sun, 11 Nov 2007 15:51:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 15:51:53 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 15:51:52 +0100 Received: from [131.160.126.92] (rvi2-126-92.lmf.ericsson.se [131.160.126.92]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AC69525F7 for ; Sun, 11 Nov 2007 16:51:52 +0200 (EET) Message-ID: <47371708.8050202@ericsson.com> Date: Sun, 11 Nov 2007 16:51:52 +0200 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 Nov 2007 14:51:52.0450 (UTC) FILETIME=[654D5E20:01C82472] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] Agenda requests, IETF 70 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, you can send me your agenda requests if you want to present something in the session in Vancouver. 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 Sun Nov 11 10:43: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 1IrEy5-0003Rq-O6; Sun, 11 Nov 2007 10:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrEy4-0003RL-LB for hipsec@ietf.org; Sun, 11 Nov 2007 10:43:24 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrEy0-0006xV-Gn for hipsec@ietf.org; Sun, 11 Nov 2007 10:43:24 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C33372E0E; Sun, 11 Nov 2007 17:43:19 +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 08D3D2E03; Sun, 11 Nov 2007 17:43:10 +0200 (EET) Date: Sun, 11 Nov 2007 17:43:10 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Shinta Sugimoto Subject: Re: [Hipsec] Re: API draft In-Reply-To: <20071110141206.88D6.SHINTA@sfc.wide.ad.jp> Message-ID: References: <47036A80.9010007@ericsson.com> <20071110141206.88D6.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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, 10 Nov 2007, Shinta Sugimoto wrote: > Hi Miika, > > Thank you for updating the draft. I checked it and I am basically fine with > the content of the draft. There are some minor comments (mostly editorial). > Please find them inline: Thanks Shinta for the review, I adjusted the draft according to your suggestions and the new version is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre5.txt >> | Term | Explanation | >> +---------+---------------------------------------------------------+ >> | HIP | Host Identity Protocol | >> | Locator | Non-routable IPv4 or IPv6 address used at the lower | >> | | layers | > > s/Non-routable/Routable/ > >> | FQDN | Fully Qualified Domain Name | > > I guess abbreviation of FQDN is widely known. > >> | HIT | Host Identity Tag, a 100-bit hash of a public key with | >> | | a 28 bit prefix | >> | LSI | Local Scope Identifier, a local, 32-bit descriptor for | >> | | a given public key. | >> | Locator | Routable IPv4 or IPv6 address | >> +---------+---------------------------------------------------------+ > > definition of "Locator" is given twice in the table. Ok. >> | | | | >> | Stack | | HIP | >> | | | | >> +----------+ +----------+ > > s/Stack/TCP\/IP Stack/ > >> >> Figure 2 >> >> In practice, the resolver functionality can implemented in different > > s/can/can be/ > >> ways. For example, it may be implemented in existing resolver >> libraries or as a DNS proxy. >> >> >> 4. API Syntax and Semantics >> >> In this section, we describe the native HIP APIs using the syntax of >> the C programming language. We limit the description to the >> interfaces and data structures that are either modified or completely >> new, because the native HIP APIs is otherwise identical to the > > s/is/are/ Ok. >> sockets API [POSIX]. > > when you refer to "API" in the document, I think singular form is more > suitable. It depends how one wants to think about it. Originally Nikander suggested plular. I guess APIs in plular is more approate if each interface (function call) is though as a separate API. Neverthless, I think what matters is that the plularity is used consistently in the document. > s/uses also/also uses/ > >> to establish outgoing communications in Opportunistic mode >> [I-D.ietf-hip-base], when the application knows the remote peer >> locator but not the HIT. Outgoing communications refers here to the >> use of functions such as connect(), sendto() and sendmsg(). After >> initial contact with the peer, the local and peer HITs can be >> discovered using getsockname() and getpeername() calls for >> connection-oriented sockets. >> >> The HIP_HIT_ANY_ macros allow also non-ORCHID based communications to > > s/allow also/also allow/ Ok. > maybe you had better provide a table which enumerates the newly defined > ai_flags for HIP with brief explanation (rather than showing everything > in Table 3). I think there would too much redundancy because there are descriptions already both in the text and in appendix. >> The ai_family field is set to AF_HIP the addrinfo structure when >> ai_addr points to a sockaddr_hip structure. >> >> When ai_protocol field is set to zero, the resolver returns also > > s/returns also/also returns/ > >> locators in sockaddr_in and sockaddr_in6 structures in addition to >> sockaddr_hip structures. The resolver returns only sockaddr_hip > > s/returns only/only returns/ > >> 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 > > s/acts/act/ Ok. >> attributes required from the resolved endpoints. A NULL hints >> argument indicates that any kind of endpoints are acceptable. >> >> 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_hip structures only when the input >> argument has the AI_HIP flag set. The resolver inserts HITs before >> any locators. >> >> Resolving of a hostname can result in a HIT which maps to multiple > > s/Resolving of/Resolution of/ Change to active, Resolver can return a HIT which maps to multiple locators. >> locators. The resolver may cache the locator mappings to the HIP >> module. The HIP module manages the multiple locators according to >> local policies of the host. When the application implements its own >> locator policies, it can control the locators bindings with the >> extensions defined in [I-D.ietf-shim6-proto]. > > should be [I-D.ietf-shim6-multihome-shim-api], instead of > [I-D.ietf-shim6-protocol]. Ok. > That's it from me. Hope it helps. I appreciate your review. Thanks! -- 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 Nov 11 11:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFth-0008JE-0B; Sun, 11 Nov 2007 11:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFtf-0008J7-Lg for hipsec@ietf.org; Sun, 11 Nov 2007 11:42:55 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrFta-0000eW-8u for hipsec@ietf.org; Sun, 11 Nov 2007 11:42:55 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2865920689; Sun, 11 Nov 2007 17:42:49 +0100 (CET) X-AuditID: c1b4fb3c-b1681bb0000007e1-25-473731094879 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08A8A2005B; Sun, 11 Nov 2007 17:42:49 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 17:42:48 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 17:42:48 +0100 Received: from [131.160.126.92] (rvi2-126-92.lmf.ericsson.se [131.160.126.92]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0FFA325F7; Sun, 11 Nov 2007 18:42:48 +0200 (EET) Message-ID: <4737310A.8050509@ericsson.com> Date: Sun, 11 Nov 2007 18:42:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Re: API draft References: <47036A80.9010007@ericsson.com> <20071110141206.88D6.SHINTA@sfc.wide.ad.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2007 16:42:48.0509 (UTC) FILETIME=[E49F5ED0:01C82481] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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, a few comments on this pre-version. Expand API in the Introduction as well. Fix grammar: "The application can also to explicitly allow..." The draft says: "Note that the APIs specified in this document are not specific to HIP" The 'not' should be removed (check the text I sent to the list a while ago, which was agreed with the ADs). Please, fix these and submit the draft before the cut-off date. I will WG last call the version you submit so that the group has a last chance to provide comments. Cheers, Gonzalo Miika Komu wrote: > On Sat, 10 Nov 2007, Shinta Sugimoto wrote: > >> Hi Miika, >> >> Thank you for updating the draft. I checked it and I am basically >> fine with >> the content of the draft. There are some minor comments (mostly >> editorial). >> Please find them inline: > > Thanks Shinta for the review, > > I adjusted the draft according to your suggestions and the new version > is here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre5.txt > >>> | Term | Explanation | >>> +---------+---------------------------------------------------------+ >>> | HIP | Host Identity Protocol | >>> | Locator | Non-routable IPv4 or IPv6 address used at the lower | >>> | | layers | >> >> s/Non-routable/Routable/ >> >>> | FQDN | Fully Qualified Domain Name | >> >> I guess abbreviation of FQDN is widely known. >> >>> | HIT | Host Identity Tag, a 100-bit hash of a public key with | >>> | | a 28 bit prefix | >>> | LSI | Local Scope Identifier, a local, 32-bit descriptor for | >>> | | a given public key. | >>> | Locator | Routable IPv4 or IPv6 address | >>> +---------+---------------------------------------------------------+ >> >> definition of "Locator" is given twice in the table. > > Ok. > >>> | | | | >>> | Stack | | HIP | >>> | | | | >>> +----------+ +----------+ >> >> s/Stack/TCP\/IP Stack/ >> >>> >>> Figure 2 >>> >>> In practice, the resolver functionality can implemented in different >> >> s/can/can be/ >> >>> ways. For example, it may be implemented in existing resolver >>> libraries or as a DNS proxy. >>> >>> >>> 4. API Syntax and Semantics >>> >>> In this section, we describe the native HIP APIs using the syntax of >>> the C programming language. We limit the description to the >>> interfaces and data structures that are either modified or completely >>> new, because the native HIP APIs is otherwise identical to the >> >> s/is/are/ > > Ok. > >>> sockets API [POSIX]. >> >> when you refer to "API" in the document, I think singular form is more >> suitable. > > It depends how one wants to think about it. Originally Nikander > suggested plular. I guess APIs in plular is more approate if each > interface (function call) is though as a separate API. Neverthless, I > think what matters is that the plularity is used consistently in the > document. > >> s/uses also/also uses/ >> >>> to establish outgoing communications in Opportunistic mode >>> [I-D.ietf-hip-base], when the application knows the remote peer >>> locator but not the HIT. Outgoing communications refers here to the >>> use of functions such as connect(), sendto() and sendmsg(). After >>> initial contact with the peer, the local and peer HITs can be >>> discovered using getsockname() and getpeername() calls for >>> connection-oriented sockets. >>> >>> The HIP_HIT_ANY_ macros allow also non-ORCHID based communications to >> >> s/allow also/also allow/ > > Ok. > >> maybe you had better provide a table which enumerates the newly defined >> ai_flags for HIP with brief explanation (rather than showing everything >> in Table 3). > > I think there would too much redundancy because there are descriptions > already both in the text and in appendix. > >>> The ai_family field is set to AF_HIP the addrinfo structure when >>> ai_addr points to a sockaddr_hip structure. >>> >>> When ai_protocol field is set to zero, the resolver returns also >> >> s/returns also/also returns/ >> >>> locators in sockaddr_in and sockaddr_in6 structures in addition to >>> sockaddr_hip structures. The resolver returns only sockaddr_hip >> >> s/returns only/only returns/ >> >>> 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 >> >> s/acts/act/ > > Ok. > >>> attributes required from the resolved endpoints. A NULL hints >>> argument indicates that any kind of endpoints are acceptable. >>> >>> 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_hip structures only when the input >>> argument has the AI_HIP flag set. The resolver inserts HITs before >>> any locators. >>> >>> Resolving of a hostname can result in a HIT which maps to multiple >> >> s/Resolving of/Resolution of/ > > Change to active, Resolver can return a HIT which maps to multiple > locators. > >>> locators. The resolver may cache the locator mappings to the HIP >>> module. The HIP module manages the multiple locators according to >>> local policies of the host. When the application implements its own >>> locator policies, it can control the locators bindings with the >>> extensions defined in [I-D.ietf-shim6-proto]. >> >> should be [I-D.ietf-shim6-multihome-shim-api], instead of >> [I-D.ietf-shim6-protocol]. > > Ok. > >> That's it from me. Hope it helps. > > I appreciate your review. Thanks! > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 12 02:39: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 1IrTsx-0000NQ-Mh; Mon, 12 Nov 2007 02:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrTsw-0000Lc-Q0 for hipsec@ietf.org; Mon, 12 Nov 2007 02:39:06 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrTst-0005jb-1I for hipsec@ietf.org; Mon, 12 Nov 2007 02:39:06 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 788222D9C; Mon, 12 Nov 2007 09:39:02 +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 D63622D63; Mon, 12 Nov 2007 09:38:55 +0200 (EET) Date: Mon, 12 Nov 2007 09:38:55 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo Subject: Re: [Hipsec] Re: API draft In-Reply-To: <4737310A.8050509@ericsson.com> Message-ID: References: <47036A80.9010007@ericsson.com> <20071110141206.88D6.SHINTA@sfc.wide.ad.jp> <4737310A.8050509@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Sun, 11 Nov 2007, Gonzalo Camarillo wrote: Hi Gonzalo, the new version based on your comments is in here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre6.txt > Hi Miika, > > a few comments on this pre-version. > > Expand API in the Introduction as well. > > Fix grammar: "The application can also to explicitly allow..." The second goal is that applications can explicitly accept communications with unknown peer identifiers. > The draft says: > > "Note that the APIs specified in this document are not specific to HIP" > > The 'not' should be removed (check the text I sent to the list a while ago, > which was agreed with the ADs). Removed "not". Please tell explicitly if there are other problems with this. I mentioned this already in the summary of changes on the mailing list, but I removed the SHIM generalization in lack of any other concrete examples where the generalization could be useful. Also, I think it is better to explicitly specify the SHIM protocol to avoid ambiguous protocol bindings. Nobody seemed to object against this change. > Please, fix these and submit the draft before the cut-off date. I will WG > last call the version you submit so that the group has a last chance to > provide comments. Cut-off is in one week. Comments are still welcome. -- 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 Nov 12 13:30: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 1Ire36-0007Yz-5d; Mon, 12 Nov 2007 13:30:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ire34-0007Xf-AP for hipsec@ietf.org; Mon, 12 Nov 2007 13:30:14 -0500 Received: from mta-2.ms.rz.rwth-aachen.de ([134.130.7.73]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ire33-0004Im-EP for hipsec@ietf.org; Mon, 12 Nov 2007 13:30:14 -0500 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JRE00GM4OQCMN60@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 12 Nov 2007 19:30:12 +0100 (CET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 12 Nov 2007 19:30:12 +0100 Received: from [137.226.12.161] (dhcp161.informatik.RWTH-Aachen.DE [137.226.12.161]) by relay.rwth-aachen.de (8.13.7/8.13.3/1) with ESMTP id lACIUBsJ001394; Mon, 12 Nov 2007 19:30:11 +0100 (MET) Date: Mon, 12 Nov 2007 19:30:09 +0100 From: Tobias Heer To: hipsec-rg@honor.trusecure.com, hip WG Message-id: <238EADAE-FCE2-49B4-B47D-356DCF83E543@cs.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) X-IronPort-AV: E=Sophos;i="4.21,406,1188770400"; d="p7s'?scan'208,217";a="34048399" X-Spam-Score: 1.3 (+) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Subject: [Hipsec] (no subject) 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: , Content-Type: multipart/mixed; boundary="===============1702272797==" Errors-To: hipsec-bounces@lists.ietf.org --===============1702272797== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--310838502; protocol="application/pkcs7-signature" --Apple-Mail-19--310838502 Content-Type: multipart/alternative; boundary=Apple-Mail-18--310838569 --Apple-Mail-18--310838569 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed There is a new HIP-related Internet draft. Filename: draft-heer-hip-middle-auth Revision: 00 Title: End-Host Authentication for HIP Middleboxes Creation_date: 2007-11-11 WG ID: Independent Submission Number_of_pages: 17 Abstract: The Host Identity Protocol is a signaling protocol for secure communication, mobility, and multihoming by introducing a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension enables middleboxes to verify the liveness and freshness of a HIP association and, thus, enables reliable and secure access control in middleboxes. http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt Comments are highly appreciated. Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer --Apple-Mail-18--310838569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 There is a new HIP-related = Internet draft.

Filename: = draft-heer-hip-middle-auth
= 00
Title: End-Host = Authentication for HIP Middleboxes
= 2007-11-11
WG ID: = Independent Submission
Number_of_pages: = 17

Abstract:
The Host = Identity Protocol is a signaling protocol for secure
communication, mobility, and multihoming by = introducing a
cryptographic namespace.=A0 This = document specifies an extension for
HIP that = enables middleboxes to unambiguously verify the identities
of hosts that communicate across them.=A0 This = extension enables
middleboxes to verify the = liveness and freshness of a HIP association
and, = thus, enables reliable and secure access control in = middleboxes.

http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt=
=
Comments are highly = appreciated.

Best = regards,

Tobias


--=A0=A0
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group=A0
RWTH Aachen University, Germany




 =

= --Apple-Mail-18--310838569-- --Apple-Mail-19--310838502 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQjCCAvsw ggJkoAMCAQICEC1IEZFFsMbqCTfVL3CGGP8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNjA2NDQ0MloXDTA4MDcwNTA2NDQ0 MlowXTENMAsGA1UEBBMESGVlcjEPMA0GA1UEKhMGVG9iaWFzMRQwEgYDVQQDEwtUb2JpYXMgSGVl cjElMCMGCSqGSIb3DQEJARYWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMw9OUSRfF10zWkVrIsXsjCC8hsCRqg7NLKWYPr1M7CfJyk/0B14o8Eu PK1qUfjl1w/E5rlHIuC3rbok9tV2hHsWqPV9+tAAr4g5QJVNrou9BCD7vHPuCMJ/7WTWMcEewmS2 +U0762iVFK/bLSKwPvaaQWQV1ULUy9zJaLPHQQIAVooBQSypQy+wtxJ3PIn6nfQQnE8hc+hhz5gd 8jLoGozYz0Xv75W4YSYRjH+/R+JLS60do+V2Si1BUaOjQPS+PBSI3uNmWQQCJOb/3LBFDiUBNWe5 PoVe+HiHZi+L4s0wimzu9O/y7IUme6U5kWQTcMYdVTqxkHDk/TbcAjniyE0CAwEAAaMzMDEwIQYD VR0RBBowGIEWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAD+gsUZ2GBKOG8XHPo8vGSBn85ucmwhiY7CHF+B9EvLKX1QebGCg7TooQLvJOighEUCt d5L59l4kjM6u3PrwcHlUkDeImHW3LP2bOvkXhmpYKTLz1QxlnV3WtyydO0JvNQz9pLSI2DAwuPx1 8E7q/XdJ5IWg6J1acNpiNhMuXOrhMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAtSBGRRbDG6gk31S9whhj/MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTExMjE4MzAxMFowIwYJKoZIhvcNAQkEMRYEFCHZ15W2zmrO y2u5iAJ1JWwSYDigMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY/zCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY /zANBgkqhkiG9w0BAQEFAASCAQA1hLtCQ05Srfskhg7BSkQm8Cq41+/47081hgyDsrOyMo9HaInt /whFBDiH2/jMSC8Iya8mbeKZ8Ctko5Zm8qUKrMbxp1Cwh1kagRVA0pkreKFCF3MPZRw2bYfE5oP4 5BxIrI9PgwsVN3XRRyeeYaHPPDSTPCn2oLQ4QBnS3iScD0w3F4UmjovyTGCDKZwbft19+zeRhnRP iteO53z99Mx+mRo0iexv2V86rQkmWeCiye1oBGQdIBU1boSioVfSuhzJbuBXYaOBP2NRcPsuxFXo 1w58ZIe3ioqQzFTikZkIzWSTWylbdkbtjKy8++gb5SPFdWYwI/vYD1Wn2EuHtbfGAAAAAAAA --Apple-Mail-19--310838502-- --===============1702272797== 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 --===============1702272797==-- From hipsec-bounces@lists.ietf.org Mon Nov 12 14:06: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 1IrecA-0007ML-8V; Mon, 12 Nov 2007 14:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irec8-0007LI-Nn for hipsec@ietf.org; Mon, 12 Nov 2007 14:06:28 -0500 Received: from mail-i4.informatik.rwth-aachen.de ([137.226.12.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irec4-0000Zy-CB for hipsec@ietf.org; Mon, 12 Nov 2007 14:06:28 -0500 Received: from info-4.informatik.rwth-aachen.de (cronos.info-4.informatik.rwth-aachen.de [137.226.12.31]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 4BE97980EE for ; Mon, 12 Nov 2007 20:06:23 +0100 (CET) Received: from [137.226.12.160] ([137.226.12.160]) by info-4.informatik.rwth-aachen.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 20:06:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: hipsec-rg@honor.trusecure.com, hip WG Message-Id: <770312FD-5FFE-4582-8263-BC837D4579BC@cs.rwth-aachen.de> From: Tobias Heer Date: Mon, 12 Nov 2007 20:06:21 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Nov 2007 19:06:23.0045 (UTC) FILETIME=[1DB2FF50:01C8255F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Hipsec] New HIP-related Internet 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: , Content-Type: multipart/mixed; boundary="===============1883234338==" Errors-To: hipsec-bounces@lists.ietf.org --===============1883234338== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-43--308666380; protocol="application/pkcs7-signature" --Apple-Mail-43--308666380 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sorry for having sent the previous mail without subject. I'm resending it to avoid that it gets stuck in some aggressive spam filters. Sorry for receiving multiple copies. There is a new HIP-related Internet draft. Filename: draft-heer-hip-middle-auth Revision: 00 Title: End-Host Authentication for HIP Middleboxes Creation_date: 2007-11-11 WG ID: Independent Submission Number_of_pages: 17 Abstract: The Host Identity Protocol is a signaling protocol for secure communication, mobility, and multihoming by introducing a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension enables middleboxes to verify the liveness and freshness of a HIP association and, thus, enables reliable and secure access control in middleboxes. http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt Comments are highly appreciated. Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Apple-Mail-43--308666380 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQjCCAvsw ggJkoAMCAQICEC1IEZFFsMbqCTfVL3CGGP8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNjA2NDQ0MloXDTA4MDcwNTA2NDQ0 MlowXTENMAsGA1UEBBMESGVlcjEPMA0GA1UEKhMGVG9iaWFzMRQwEgYDVQQDEwtUb2JpYXMgSGVl cjElMCMGCSqGSIb3DQEJARYWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMw9OUSRfF10zWkVrIsXsjCC8hsCRqg7NLKWYPr1M7CfJyk/0B14o8Eu PK1qUfjl1w/E5rlHIuC3rbok9tV2hHsWqPV9+tAAr4g5QJVNrou9BCD7vHPuCMJ/7WTWMcEewmS2 +U0762iVFK/bLSKwPvaaQWQV1ULUy9zJaLPHQQIAVooBQSypQy+wtxJ3PIn6nfQQnE8hc+hhz5gd 8jLoGozYz0Xv75W4YSYRjH+/R+JLS60do+V2Si1BUaOjQPS+PBSI3uNmWQQCJOb/3LBFDiUBNWe5 PoVe+HiHZi+L4s0wimzu9O/y7IUme6U5kWQTcMYdVTqxkHDk/TbcAjniyE0CAwEAAaMzMDEwIQYD VR0RBBowGIEWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAD+gsUZ2GBKOG8XHPo8vGSBn85ucmwhiY7CHF+B9EvLKX1QebGCg7TooQLvJOighEUCt d5L59l4kjM6u3PrwcHlUkDeImHW3LP2bOvkXhmpYKTLz1QxlnV3WtyydO0JvNQz9pLSI2DAwuPx1 8E7q/XdJ5IWg6J1acNpiNhMuXOrhMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAtSBGRRbDG6gk31S9whhj/MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTExMjE5MDYyMlowIwYJKoZIhvcNAQkEMRYEFB/B4rVH2aoh 3wqt1EkVZsMD/45kMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY/zCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY /zANBgkqhkiG9w0BAQEFAASCAQBoSBDQlZl7x1s3RYTkrtCpfB7bDshEZvuVdH5ggN0roaUw/1jY PrNjSV/XJZWpFGyMKtg+kQ+ERUe2DFFFGYNgC2pQS0KE9xo4nu2hghvzaA+fjQHyCSeiWrLw1P4O X8vayVelrEIpMHLPy+RsEjCoGPXproXSAWe56kGZ+SmsgUVHCRrKUSXtS8DmHvNzoGQjJjFgGkkS wbDWfEkGvzLnanDk1bjuAwnbcLF5arfOqvvDvRFAhtZUTSw9r5OT/UivbG1F+WHQbSzYVNbaK15r Y1Dj7kJGrvjthuil0wfSf71a4qLhCK7v6tsmGH4wGO+MBw4x0xgnXRbN29Ftk43wAAAAAAAA --Apple-Mail-43--308666380-- --===============1883234338== 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 --===============1883234338==-- From hipsec-bounces@lists.ietf.org Mon Nov 12 15:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfhB-0007mM-3m; Mon, 12 Nov 2007 15:15:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfh9-0007hj-ER for hipsec@ietf.org; Mon, 12 Nov 2007 15:15:43 -0500 Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irfh8-00036F-V3 for hipsec@ietf.org; Mon, 12 Nov 2007 15:15:43 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 334E41EF132; Mon, 12 Nov 2007 22:15:42 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id BDA1D1EF101; Mon, 12 Nov 2007 22:15:41 +0200 (EET) Message-ID: <4738B45A.3050106@nomadiclab.com> Date: Mon, 12 Nov 2007 22:15:22 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] Agenda requests, IETF 70 References: <47371708.8050202@ericsson.com> In-Reply-To: <47371708.8050202@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Gonzalo, I'd like to present our ongoing work on integrating the concepts of the Six/One site multi-homing solution into HIP. A 5- to 10-minutes slot would be sufficient. Six/One is one of the main proposals currently being discussed in IRTF's Routing research group. Interested folks find the proposal here: http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt Thanks! - Christian _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 19 03:10: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 1Iu1iG-0002cX-59; Mon, 19 Nov 2007 03:10:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu1iE-0002YV-Bp; Mon, 19 Nov 2007 03:10:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu1iB-0005go-VP; Mon, 19 Nov 2007 03:10:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D9429328F4; Mon, 19 Nov 2007 08:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu1hh-0006rt-OS; Mon, 19 Nov 2007 03:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 03:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-applications-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 --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 : Using the Host Identity Protocol with Legacy Applications Author(s) : T. Henderson, et al. Filename : draft-ietf-hip-applications-02.txt Pages : 18 Date : 2007-11-19 This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. >From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.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-applications-02.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-applications-02.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-11-19030929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-applications-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-applications-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19030929.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 Mon Nov 19 07:26: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 1Iu5he-0001EJ-86; Mon, 19 Nov 2007 07:26:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5hd-0001Da-GR for hipsec@ietf.org; Mon, 19 Nov 2007 07:26:13 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu5hc-0003V4-Sh for hipsec@ietf.org; Mon, 19 Nov 2007 07:26:13 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3508720982; Mon, 19 Nov 2007 13:26:10 +0100 (CET) X-AuditID: c1b4fb3c-b1e1ebb000002c9b-bb-474180e249af Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C3DE2057A; Mon, 19 Nov 2007 13:26:10 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:26:10 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:26:09 +0100 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9079F2461; Mon, 19 Nov 2007 14:26:09 +0200 (EET) Message-ID: <474180E1.10106@ericsson.com> Date: Mon, 19 Nov 2007 14:26:09 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tobias Heer Subject: Re: [Hipsec] New HIP-related Internet draft. References: <770312FD-5FFE-4582-8263-BC837D4579BC@cs.rwth-aachen.de> In-Reply-To: <770312FD-5FFE-4582-8263-BC837D4579BC@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 12:26:09.0877 (UTC) FILETIME=[5DA09850:01C82AA7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: hipsec-rg@honor.trusecure.com, 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, note that the HIP WG is chartered to work on mechanisms to traverse existing NATs. HIP-aware NATs fall into the scope of the research group. Cheers, Gonzalo Tobias Heer wrote: > Sorry for having sent the previous mail without subject. I'm resending > it to avoid that it gets stuck in some aggressive spam filters. Sorry > for receiving multiple copies. > > There is a new HIP-related Internet draft. > > Filename: draft-heer-hip-middle-auth > Revision: 00 > Title: End-Host Authentication for HIP Middleboxes > Creation_date: 2007-11-11 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > The Host Identity Protocol is a signaling protocol for secure > communication, mobility, and multihoming by introducing a > cryptographic namespace. This document specifies an extension for > HIP that enables middleboxes to unambiguously verify the identities > of hosts that communicate across them. This extension enables > middleboxes to verify the liveness and freshness of a HIP association > and, thus, enables reliable and secure access control in middleboxes. > > http://www.ietf.org/internet-drafts/draft-heer-hip-middle-auth-00.txt > > Comments are highly appreciated. > > Best regards, > > Tobias > > > -- Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group > RWTH Aachen University, Germany > http://ds.cs.rwth-aachen.de/members/heer > > > > > > _______________________________________________ > 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 Mon Nov 19 07:50: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 1Iu65C-0004eF-8a; Mon, 19 Nov 2007 07:50:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004dr-0c; Mon, 19 Nov 2007 07:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu65A-0004fM-Jr; Mon, 19 Nov 2007 07:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 797CD2AC5E; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001oh-7t; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-api-03.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 : Native Application Programming Interfaces (APIs) for Host Identity Protocol (HIP) Author(s) : M. Komu Filename : draft-ietf-hip-native-api-03.txt Pages : 14 Date : 2007-11-19 This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the initial discovery of public-key based identifiers. Using the extensions, the application can verify that the identifier is a Host Identity Tag (HIT) and it can require the system resolver to return only HITs from DNS. The application can also to explicitly allow more relaxed security models where the communication can be non-HIP based in the absence of a peer identifiers, or that the application allows peer identity to be discovered after initial contact directly with the peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.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-native-api-03.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-native-api-03.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-11-19074307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074307.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 Mon Nov 19 08:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6lP-000886-Ao; Mon, 19 Nov 2007 08:34:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6lN-00087y-Nn for hipsec@ietf.org; Mon, 19 Nov 2007 08:34:09 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6lN-0007QY-Bw for hipsec@ietf.org; Mon, 19 Nov 2007 08:34:09 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BAC9B2050E; Mon, 19 Nov 2007 14:34:08 +0100 (CET) X-AuditID: c1b4fb3e-b2038bb0000007e1-1e-474190d0a402 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AB28120256; Mon, 19 Nov 2007 14:34:08 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:34:08 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:34:07 +0100 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5FED72460; Mon, 19 Nov 2007 15:34:07 +0200 (EET) Message-ID: <474190CF.4030708@ericsson.com> Date: Mon, 19 Nov 2007 15:34:07 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 13:34:07.0929 (UTC) FILETIME=[DC55F290:01C82AB0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Hipsec] Draft agenda for 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, this is the draft agenda for Vancouver: http://www3.ietf.org/proceedings/07dec/agenda/hip.html Comments are welcome. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 19 10: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 1Iu8hM-0008TZ-TR; Mon, 19 Nov 2007 10:38:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8hL-0008TP-Bi for hipsec@ietf.org; Mon, 19 Nov 2007 10:38:07 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu8hL-0000OX-1M for hipsec@ietf.org; Mon, 19 Nov 2007 10:38:07 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lAJFc0gH012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Nov 2007 09:38:05 -0600 (CST) 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 lAJFbx1T002618; Mon, 19 Nov 2007 07:37:59 -0800 (PST) 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 lAJFbvcK002550; Mon, 19 Nov 2007 07:37:59 -0800 (PST) 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, 19 Nov 2007 07:37:57 -0800 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] Re: API draft Date: Mon, 19 Nov 2007 07:37:56 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049998@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Re: API draft Thread-Index: Acgk/x4XEBdjiCcXSkKMtsOzWofyXgFwn4gg References: <47036A80.9010007@ericsson.com><20071110141206.88D6.SHINTA@sfc.wide.ad.jp><4737310A.8050509@ericsson.com> From: "Henderson, Thomas R" To: "HIP" X-OriginalArrivalTime: 19 Nov 2007 15:37:57.0307 (UTC) FILETIME=[289710B0:01C82AC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 I posted some comments on the API draft to Miika privately, and am reposting the more substantive ones here for any WG list discussion of them. - overall, I think it is improved without so much shim6 reliance, but perhaps more dependency needs to be removed? (next comment) - referring to Figure 2, the biggest piece that seems to be missing in the draft is a discussion about step f (connect). The draft basically implies that the application deals only with HITs, but I think that the API should also support passing locators along with HITs. These locators need not be learned in the resolution step. The draft needs to be extended to spell out the details (how are locators conveyed, and associated with a HIT, and what are semantics if the HIT is not reachable at those locators). =20 It may be that you feel it is out of scope (section 2, para.3) but I think it needs to be in scope, or if you feel that it is in shim6-multihome, more of an overview presented here. =20 - Also, what happens when the application has skipped the resolution step and passes a HIT that cannot be successfully resolved? - step e, I think it is correct to pass back only HITs, but the draft ought to have more to say about how an application finds locator bindings that may have been in the DNS but hidden from the application. There is only a reference to shim6 that it can control the bindings with LOC_PEER_PREF. - section 4.2, I do not see why it is important to support non-ORCHID HITs for backward compatibility. Maybe for forward compatibility? I would just suggest to remove that paragraph, though. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Nov 19 10:46: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 1Iu8pt-0006bY-QY; Mon, 19 Nov 2007 10:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8ps-0006aR-Ef for hipsec@ietf.org; Mon, 19 Nov 2007 10:46:56 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8pn-0002hS-3i for hipsec@ietf.org; Mon, 19 Nov 2007 10:46:56 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 819F12F5D; Mon, 19 Nov 2007 17:46:50 +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 61AA82F57; Mon, 19 Nov 2007 17:46:43 +0200 (EET) Date: Mon, 19 Nov 2007 17:46:43 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Thomas Henderson Subject: RE: [Hipsec] Re: API draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049995@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049995@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: 2bf730a014b318fd3efd65b39b48818c Cc: hipsec@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 Sat, 17 Nov 2007, Henderson, Thomas R wrote: Tom, thanks for your feedback. Your comments are included in the current version of the draft: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt Unfortunately there was no time to iterate the issues more on the mailing list because the comments came on the cut-off day. > - overall, I think it is improved without so much shim6 reliance, but > perhaps more dependency needs to be removed? (next comment) I tried to remove some of the dependency by introducing some redundancy to the SHIM6 and also by including discussions about error handling. > - referring to Figure 2, the biggest piece that seems to be missing in > the draft is a discussion about step f (connect). The draft basically > implies that the application deals only with HITs, but I think that the > API should also support passing locators along with HITs. These > locators need not be learned in the resolution step. The draft needs to > be extended to spell out the details (how are locators conveyed, and > associated with a HIT, and what are semantics if the HIT is not > reachable at those locators). Added more text to section 3.2. "Interaction with the Resolver": The extensions in this document focus on the use of the resolver to map host names to HITs and locators in HIP-aware applications. The resolver associates implicitly the the HIT with the locator(s). However, it is possible that an application operates directly with a peer HIT without interacting with the resolver. In such a case, the application may resort to the system to map the peer HIT to an IP address. Alternatively, the application can explicitly map the HIT to an IP address as specified in [I-D.ietf-shim6-multihome-shim-api]. Both of these two approaches may be more prone to errors than the use resolver with host names. Hence, HIP-aware applications should prefer to use the resolver with host names. > It may be that you feel it is out of scope (section 2, para.3) but I > think it needs to be in scope, or if you feel that it is in > shim6-multihome, more of an overview presented here. I think this is out of scope. The multihoming APIs are briefly introduced in the sixth paragraph and currently I don't see urgent need to go into more details. The main feature that this API needs from the multihoming APIs are socket options for getting and setting the locators. If you disagree, please suggest some text. > - Also, what happens when the application has skipped the resolution > step and passes a HIT that cannot be successfully resolved? Added section 4.3. "Manual Handling of Locators" to the draft, see below. > - step e, I think it is correct to pass back only HITs, but the draft > ought to have more to say about how an application finds locator > bindings that may have been in the DNS but hidden from the application. > There is only a reference to shim6 that it can control the bindings with > LOC_PEER_PREF. More text now in section 4.3: The system resolver, or the HIP module, maps HITs to locators implicitly. However, some applications may want to specify initial locator mappings explicitly. In such a case, the application first creates a socket with PF_HIP as the domain argument. Second, the application binds the socket to a local or peer locator with the setsockopt function with either SHIM_LOC_LOCAL_PREF or SHIM_LOC_PEER_PREF as the socket option name as defined in [I-D.ietf-shim6-multihome-shim-api]. Third, the application creates a valid sockaddr_hip structure. Finally, the application associates the socket also with the sockaddr_hip structure by calling some socket-related function, such as connect or bind. The function returns EINVALIDLOCATOR when the HIT is not reachable at the specified locator. It should be noticed that the application may just configure the HIT manually without setting the locator. In this scenario, the application relies on the system to map the HIT to an IP address. When the system fails to provide the mapping, it returns EADDRNOTAVAIL in the called sockets API function to the application and sets errno to indicate the error. > - section 4.2, I do not see why it is important to support non-ORCHID > HITs for backward compatibility. Maybe for forward compatibility? I > would just suggest to remove that paragraph, though. I repharased the text: The HIP_HIT_ANY_ macros also allow non-ORCHID based communications. To distinguish between ORCHID [RFC4843] and non-ORCHID-based communications in the case of the HIP_HIT_ANY_ macros, the application calls getsockname() and getpeername() to discover the actual identifiers used for the communications and verifies orchid prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a pointer to an in6_addr structure and returns 1 when the address has orchid prefix and 0 otherwise. Alternatively, the application can set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow only ORCHID- based communications. My point is that HIP_HIT_ANY macros would accept also normal TCP/IP communications by default. I hope my point is now more understandable? > section 1: > > s/by introducing a new "SHIM" layer to the TCP/IP stack/by introducing a > new namespace to the TCP/IP stack. > > s/underlying the HIP/the underlying HIP Fixed. > section 3: > > Figure 1 is a bit simplistic. It is below IPsec which is in the network > layer. I do not see why this Layering overview needs to be in the draft > anyway. It would suffice IMO if the draft were just a black box look at > the stack from an API perspective and did not go into these issues such > as Figure 1 and Table 2. Removed the section with figure 1. I kept table 2 because I think the identifiers and naming should be somehow still introduced in the text. > s/datagrams... are intercepted by the HIP layer../are intercepted by the > system/ Fixed. > Section 4: > > would it be a more faithful syntactical alignment to avoid "ship" and > just say: > > sockaddr_hip.sa_len > sockaddr_hip.sa_family (where "sa" stands for sockaddr and not for > sock...hip) I don't like the "ship" either but it is the standard sockets API style and I don't see why HIP should make an exception. > I think you should clarify that anonymous identifiers may be designated > by the system as metadata associated with a HIT regarding whether it has > been published or not, but that from the HIP protocol perspective, there > is no difference in the classes of HITs. Added roughly the text that you proposed: The system may designate anonymous identifiers as meta data associated with a HIT regarding whether it has been published or not, but that from the HIP protocol perspective, there is no difference in the classes of HITs. > application can use macro/application can use the macro Fixed. > Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR" portion of > the string? For two reasons of which are not very strong reasons IMHO. First, the other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it would be nice if both of the accessor macros share the same prefix. Second, the naming of the macro indicates that the macro checks an ipv6 address. In later extensions, we could have a macro that does the same for a public key. Would you still prefer e.g. HIP_IS_ANON_HIT? > Section 4.2: > s/must be set to the ai_flags/must be set in the ai_flags/ > > s/locators bindings/locator bindings Fixed. > I-D.henderson-hip-applications is now ietf-hip-applications Ah, forgot to change this from the submitted version. I included in my version control and this will be visible in the next (pre?) 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 Mon Nov 19 11:48: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 1Iu9nY-0002cT-HJ; Mon, 19 Nov 2007 11:48:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9nX-0002cB-7Y for hipsec@ietf.org; Mon, 19 Nov 2007 11:48:35 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu9nW-0007Aq-M3 for hipsec@ietf.org; Mon, 19 Nov 2007 11:48:35 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C251C2F67; Mon, 19 Nov 2007 18:48:33 +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 D89F52F3F for ; Mon, 19 Nov 2007 18:48:26 +0200 (EET) Date: Mon, 19 Nov 2007 18:48:26 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Hipsec] Re: [hipsec ]I-D Action:draft-ietf-hip-native-api-03.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, > 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 : Using the Host Identity Protocol with Legacy > Applications > Author(s) : T. Henderson, et al. > Filename : draft-ietf-hip-applications-02.txt > Pages : 18 > Date : 2007-11-19 > > This document is an informative overview of how legacy applications > can be made to work with the Host Identity Protocol (HIP). HIP > proposes to add a cryptographic name space for network stack names. > From an application viewpoint, HIP-enabled systems support a new > address family of host identifiers, but it may be a long time until > such HIP-aware applications are widely deployed even if host systems > are upgraded. This informational document discusses implementation > and Application Programming Interface (API) issues relating to using > HIP in situations in which the system is HIP-aware but the > applications are not, and is intended to aid implementors and early > adopters in thinking about and locally solving systems issues > regarding the incremental deployment of HIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.txt here is a summary of the changes between 02 and 03 version: * Clarifications to the use of opportunistic mode * Replaced SHIM generalization with just "HIP" * The locator was removed from the HIT data structure * Discussion on error handling in section 4.3 * Removed section "Layering Model" * New section 4.3 "Manual Handling of Locators" * Added a summary of new definitions to the appendix * Comments on hostname mapping to multiple HITs * Comments on HIT mapping to multiple locators * HITs are now compared now with memcmp (no more endpoint descriptors) * Clarified the ordering of identifiers returned by the resolver * Added a reserved field to sockaddr_hip for forwards compatibility * Added #include statements to the code blocks * 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 * Lot's of editorial nits and corrections to spelling * Updated references (note: the reference to I-D.henderson-hip-applications is still outdated) For details, please dig in here: http://www1.ietf.org/mail-archive/web/hipsec/current/msg02249.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02224.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg02187.html Thanks for the reviewers for great comments! Please post further comments to the mailing list. -- 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 Nov 19 12:29: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 1IuAQe-0001Na-Dk; Mon, 19 Nov 2007 12:29:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuALi-0008Jy-0X for hipsec@ietf.org; Mon, 19 Nov 2007 12:23:54 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuAHC-0003LZ-Tu for hipsec@ietf.org; Mon, 19 Nov 2007 12:19:24 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6D3402F6F; Mon, 19 Nov 2007 19:19:14 +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 73EF52F55 for ; Mon, 19 Nov 2007 19:19:07 +0200 (EET) Date: Mon, 19 Nov 2007 19:19:07 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Hipsec] Re: [hipsec ]I-D Action:draft-ietf-hip-native-api-03.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, 19 Nov 2007, Miika Komu wrote: Hi, sorry, the draft pointer was incorrect. The current version is number three and it is here: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt The summary of draft changes applies to version three. > Hi, > >> 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 : Using the Host Identity Protocol with Legacy >> Applications >> Author(s) : T. Henderson, et al. >> Filename : draft-ietf-hip-applications-02.txt >> Pages : 18 >> Date : 2007-11-19 >> >> This document is an informative overview of how legacy applications >> can be made to work with the Host Identity Protocol (HIP). HIP >> proposes to add a cryptographic name space for network stack names. >> From an application viewpoint, HIP-enabled systems support a new >> address family of host identifiers, but it may be a long time until >> such HIP-aware applications are widely deployed even if host systems >> are upgraded. This informational document discusses implementation >> and Application Programming Interface (API) issues relating to using >> HIP in situations in which the system is HIP-aware but the >> applications are not, and is intended to aid implementors and early >> adopters in thinking about and locally solving systems issues >> regarding the incremental deployment of HIP. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.txt > > here is a summary of the changes between 02 and 03 version: > > * Clarifications to the use of opportunistic mode > * Replaced SHIM generalization with just "HIP" > * The locator was removed from the HIT data structure > * Discussion on error handling in section 4.3 > * Removed section "Layering Model" > * New section 4.3 "Manual Handling of Locators" > * Added a summary of new definitions to the appendix > * Comments on hostname mapping to multiple HITs > * Comments on HIT mapping to multiple locators > * HITs are now compared now with memcmp (no more endpoint descriptors) > * Clarified the ordering of identifiers returned by the resolver > * Added a reserved field to sockaddr_hip for forwards compatibility > * Added #include statements to the code blocks > * 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 > * Lot's of editorial nits and corrections to spelling > * Updated references (note: the reference > to I-D.henderson-hip-applications is still outdated) > > For details, please dig in here: > > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02249.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02224.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02230.html > http://www1.ietf.org/mail-archive/web/hipsec/current/msg02187.html > > Thanks for the reviewers for great comments! Please post further comments to > the mailing list. > > -- > Miika Komu http://www.iki.fi/miika/ > -- 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 Nov 19 17:07: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 1IuEmE-0005n3-0l; Mon, 19 Nov 2007 17:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEmC-0005gK-Sk for hipsec@ietf.org; Mon, 19 Nov 2007 17:07:32 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuEmA-00066K-IS for hipsec@ietf.org; Mon, 19 Nov 2007 17:07:32 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRR008YCXGI7G@usaga01-in.huawei.com> for hipsec@ietf.org; Mon, 19 Nov 2007 14:07:30 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRR00CSDXGHCS@usaga01-in.huawei.com> for hipsec@ietf.org; Mon, 19 Nov 2007 14:07:30 -0800 (PST) Date: Mon, 19 Nov 2007 16:07:20 -0600 From: Spencer Dawkins To: HIP Working Group Message-id: <08ae01c82af8$8e8eac30$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Philip Matthews Subject: [Hipsec] HIP checksum dtaft 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 asked Gonzalo for an opportunity to present a short draft in Vancouver (http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum-coverage-00.txt), and we're on the agenda for 10 minutes. Since that's a short interval, I'd like to ask people to provide impressions before the meeting - on-list is fine. The short summary of the draft is: - HIP (NAT traversal and RVS) and other working groups (P2PSIP HIPHOP) are working on applications that expect to relay HIP packets, - the current HIP checksums will terminate coverage at a HIP relay/NAT/HIPHOP peer. this requires the intermediate HIP(-aware) node to recalculate the pseudoheader checksum, and provides no end-to-end checksum coverage, so transmission errors introduced at the intermediate node can't be detected by checksum failures, - if the HIP checksums were based on the HIP header and payload, excluding any traditional transport pesudo-header fields (especially IP addresses), checksum coverage would be end-to-end, and - (somewhat orthogonal to this) HIPHOP is planning to use HIP in realtime signaling applications, and SIGTRAN (in the same space) moved from the traditional "ones-complement-sum of the one's complement" 16-bit checksum to a CRC32c checksum - so perhaps this checksum calculation would be appropriate for HIP as well. That's the high-level overview. The details are in the draft. The authors care what you think. Please let us know. Thanks, Spencer _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 21 18:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyuJ-0001pO-Aq; Wed, 21 Nov 2007 18:22:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyuG-0001fS-GQ for hipsec@ietf.org; Wed, 21 Nov 2007 18:22:57 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuyuF-0007UY-T7 for hipsec@ietf.org; Wed, 21 Nov 2007 18:22:56 -0500 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 lALNMssN019445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2007 15:22:54 -0800 (PST) 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 lALNMsWm013364; Wed, 21 Nov 2007 15:22:54 -0800 (PST) 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 lALNMsGn013361; Wed, 21 Nov 2007 15:22:54 -0800 (PST) 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); Wed, 21 Nov 2007 15:22:53 -0800 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: FW: [Hipsec] I-D Action:draft-ietf-hip-applications-02.txt Date: Wed, 21 Nov 2007 15:22:53 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040499BA@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] I-D Action:draft-ietf-hip-applications-02.txt Thread-Index: Acgqg7kPsPS8EKUVTCWeey6lLJ7NsACD6dwg From: "Henderson, Thomas R" To: "HIP" X-OriginalArrivalTime: 21 Nov 2007 23:22:53.0839 (UTC) FILETIME=[710B89F0:01C82C95] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 I would like to update the WG on the status of this draft, a revision of which was posted this week. This draft went through IESG last call, and received a number of comments from that process and also from Gen-ART review, DNS directorate review, and mobility and secdir reviews. I believe that all have been successfully addressed. I've added a section to the draft (Appendix A.1) to detail the changes that have been made since the -01 version. In addition, we invited Miika Komu to be an author based on his history of contributing several small text sections and participating heavily in the revisions. As a result of the accumulation of a large number of small edits, it has been suggested that the draft would benefit from some rewriting. I haven't taken that step yet, but would be willing to take a stab at such a revision in the future. For now, you can view the diffs by clicking on the "Diff1" or "Diff2" links for the draft at: http://tools.ietf.org/html/draft-ietf-hip-applications-02 - Tom -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, November 19, 2007 12:10 AM To: i-d-announce@ietf.org Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-applications-02.txt=20 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 : Using the Host Identity Protocol with Legacy Applications Author(s) : T. Henderson, et al. Filename : draft-ietf-hip-applications-02.txt Pages : 18 Date : 2007-11-19 This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. >From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-02.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=20 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=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then "get draft-ietf-hip-applications-02.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-applications-02.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. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 23 13:33: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 1IvdLa-0004UZ-71; Fri, 23 Nov 2007 13:33:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdLX-0004Oy-UT for hipsec@ietf.org; Fri, 23 Nov 2007 13:33:48 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvdLX-0003Bu-0B for hipsec@ietf.org; Fri, 23 Nov 2007 13:33:47 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lANIXjLR011965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Nov 2007 10:33:45 -0800 (PST) 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 lANIXjwQ001418; Fri, 23 Nov 2007 12:33:45 -0600 (CST) 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 lANIXiYY001408; Fri, 23 Nov 2007 12:33:44 -0600 (CST) 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); Fri, 23 Nov 2007 10:33:44 -0800 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] Re: API draft Date: Fri, 23 Nov 2007 10:33:43 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040499C4@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Re: API draft Thread-Index: Acgqw2jBDdAuNK+NSoKiqooJOsecGwDOX48w References: <77F357662F8BFA4CA7074B0410171B6D04049995@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 23 Nov 2007 18:33:44.0263 (UTC) FILETIME=[60B7D570:01C82DFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: hipsec@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 Miika, some responses below:=20 >=20 > Added more text to section 3.2. "Interaction with the Resolver": >=20 > The extensions in this document focus on the use of the=20 > resolver to > map host names to HITs and locators in HIP-aware=20 > applications. The > resolver associates implicitly the the HIT with the locator(s). > However, it is possible that an application operates=20 > directly with a > peer HIT without interacting with the resolver. In such=20 > a case, the > application may resort to the system to map the peer HIT to an IP > address. Alternatively, the application can explicitly=20 > map the HIT > to an IP address as specified in=20 > [I-D.ietf-shim6-multihome-shim-api]. > Both of these two approaches may be more prone to errors=20 > than the use > resolver with host names. Hence, HIP-aware applications should > prefer to use the resolver with host names. Can you specify which errors the resolver-less approach is more prone to? >=20 > > It may be that you feel it is out of scope (section 2, para.3) but I > > think it needs to be in scope, or if you feel that it is in > > shim6-multihome, more of an overview presented here. >=20 > I think this is out of scope. The multihoming APIs are=20 > briefly introduced=20 > in the sixth paragraph and currently I don't see urgent need=20 > to go into=20 > more details. The main feature that this API needs from the=20 > multihoming=20 > APIs are socket options for getting and setting the locators. If you=20 > disagree, please suggest some text. I will look at this issue some more and perhaps propose something if it cannot be covered adequately by the shim6 multihome API draft. It may need to be more clearly stated that this draft is only a subset of the complete picture and that portions of the shim6 draft must also be implemented for completeness. =20 >=20 > > - Also, what happens when the application has skipped the resolution > > step and passes a HIT that cannot be successfully resolved? >=20 > Added section 4.3. "Manual Handling of Locators" to the=20 > draft, see below. >=20 > > - step e, I think it is correct to pass back only HITs, but=20 > the draft > > ought to have more to say about how an application finds locator > > bindings that may have been in the DNS but hidden from the=20 > application. > > There is only a reference to shim6 that it can control the=20 > bindings with > > LOC_PEER_PREF. >=20 > More text now in section 4.3: >=20 > The system resolver, or the HIP module, maps HITs to locators > implicitly. However, some applications may want to=20 > specify initial > locator mappings explicitly. In such a case, the=20 > application first > creates a socket with PF_HIP as the domain argument. Second, the > application binds the socket to a local or peer locator with the > setsockopt function with either SHIM_LOC_LOCAL_PREF or > SHIM_LOC_PEER_PREF as the socket option name as defined in > [I-D.ietf-shim6-multihome-shim-api]. Third, the=20 > application creates > a valid sockaddr_hip structure. Finally, the application=20 > associates > the socket also with the sockaddr_hip structure by calling some > socket-related function, such as connect or bind. The function > returns EINVALIDLOCATOR when the HIT is not reachable at the > specified locator. >=20 > It should be noticed that the application may just=20 > configure the HIT > manually without setting the locator. In this scenario, the > application relies on the system to map the HIT to an IP address. > When the system fails to provide the mapping, it returns > EADDRNOTAVAIL in the called sockets API function to the=20 > application > and sets errno to indicate the error. >=20 > > - section 4.2, I do not see why it is important to support=20 > non-ORCHID > > HITs for backward compatibility. Maybe for forward=20 > compatibility? I > > would just suggest to remove that paragraph, though. >=20 > I repharased the text: >=20 > The HIP_HIT_ANY_ macros also allow non-ORCHID based=20 > communications. > To distinguish between ORCHID [RFC4843] and non-ORCHID-based > communications in the case of the HIP_HIT_ANY_ macros, the > application calls getsockname() and getpeername() to discover the > actual identifiers used for the communications and verifies orchid > prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a > pointer to an in6_addr structure and returns 1 when the=20 > address has > orchid prefix and 0 otherwise. Alternatively, the application can > set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow=20 > only ORCHID- > based communications. >=20 > My point is that HIP_HIT_ANY macros would accept also normal TCP/IP=20 > communications by default. I hope my point is now more understandable? OK, I didn't understand that you meant non-ORCHID to mean IP addresses. I think this section is still not clear with regard to what is passed in the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator passed?). >=20 > > section 1: > > > > s/by introducing a new "SHIM" layer to the TCP/IP stack/by=20 > introducing a > > new namespace to the TCP/IP stack. > > > > s/underlying the HIP/the underlying HIP >=20 > Fixed. >=20 > > section 3: > > > > Figure 1 is a bit simplistic. It is below IPsec which is=20 > in the network > > layer. I do not see why this Layering overview needs to be=20 > in the draft > > anyway. It would suffice IMO if the draft were just a=20 > black box look at > > the stack from an API perspective and did not go into these=20 > issues such > > as Figure 1 and Table 2. >=20 > Removed the section with figure 1. I kept table 2 because I think the=20 > identifiers and naming should be somehow still introduced in the text. >=20 > > s/datagrams... are intercepted by the HIP layer../are=20 > intercepted by the > > system/ >=20 > Fixed. >=20 > > Section 4: > > > > would it be a more faithful syntactical alignment to avoid=20 > "ship" and > > just say: > > > > sockaddr_hip.sa_len > > sockaddr_hip.sa_family (where "sa" stands for sockaddr and not for > > sock...hip) >=20 > I don't like the "ship" either but it is the standard sockets=20 > API style=20 > and I don't see why HIP should make an exception. OK, I agree now ("sa" is generic to sockaddr). >=20 > > I think you should clarify that anonymous identifiers may=20 > be designated > > by the system as metadata associated with a HIT regarding=20 > whether it has > > been published or not, but that from the HIP protocol=20 > perspective, there > > is no difference in the classes of HITs. >=20 > Added roughly the text that you proposed: >=20 > The system may designate anonymous identifiers as meta=20 > data associated > with a HIT regarding whether it has been published or=20 > not, but that > from the HIP protocol perspective, there is no difference in the > classes of HITs. >=20 > > application can use macro/application can use the macro >=20 > Fixed. >=20 > > Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR"=20 > portion of > > the string? >=20 > For two reasons of which are not very strong reasons IMHO. First, the=20 > other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it=20 > would be nice if=20 > both of the accessor macros share the same prefix. Second,=20 > the naming of=20 > the macro indicates that the macro checks an ipv6 address. In later=20 > extensions, we could have a macro that does the same for a public key. >=20 > Would you still prefer e.g. HIP_IS_ANON_HIT? I do not see why HIP_IS_IPV6_ADDR_ORCHID needs it either, and yes, I would still prefer to drop it. The macro is checking a 128-bit quantity that is not necessarily an address. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 23 14:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdu4-0007sA-Gr; Fri, 23 Nov 2007 14:09:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdu4-0007rk-2P for hipsec@ietf.org; Fri, 23 Nov 2007 14:09:28 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivdtz-00030o-Nb for hipsec@ietf.org; Fri, 23 Nov 2007 14:09:28 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lANJ9I7H017468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Nov 2007 11:09:19 -0800 (PST) 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 lANJ9IE9027042; Fri, 23 Nov 2007 13:09:18 -0600 (CST) 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 lANJ9H91027031; Fri, 23 Nov 2007 13:09:18 -0600 (CST) 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); Fri, 23 Nov 2007 11:09:17 -0800 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] HIP checksum dtaft Date: Fri, 23 Nov 2007 11:09:17 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040499C5@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <08ae01c82af8$8e8eac30$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] HIP checksum dtaft Thread-Index: Acgq+JuB6VLAIOWMR0yqLXqWIYWPgwDCuWcg References: <08ae01c82af8$8e8eac30$6601a8c0@china.huawei.com> From: "Henderson, Thomas R" To: "Spencer Dawkins" , "HIP Working Group" X-OriginalArrivalTime: 23 Nov 2007 19:09:17.0572 (UTC) FILETIME=[5844F440:01C82E04] X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 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 Spencer, I had a question about your recently published draft:=20 > (http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum-coverage-00.txt ) It seems to me that your proposal would make the HIP checksum fully redundant with signature and HMAC, which also cover HIP header + HIP parameters. So would it be better to do away with the checksum altogether?=20 - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Nov 24 04:57: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 1Ivrl4-0004Vs-Ql; Sat, 24 Nov 2007 04:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivrl3-0004VV-Ci for hipsec@ietf.org; Sat, 24 Nov 2007 04:57:05 -0500 Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivrl2-0003b7-4f for hipsec@ietf.org; Sat, 24 Nov 2007 04:57:05 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 22F261EF126; Sat, 24 Nov 2007 11:57:03 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id BF90D1EF120; Sat, 24 Nov 2007 11:57:02 +0200 (EET) In-Reply-To: <08ae01c82af8$8e8eac30$6601a8c0@china.huawei.com> References: <08ae01c82af8$8e8eac30$6601a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F4A0408-8C50-4AE7-8A5A-F91B523438A8@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] HIP checksum dtaft Date: Sat, 24 Nov 2007 11:57:02 +0200 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: HIP Working Group , 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 Spencer, I think we need to think very carefully about the purpose of the checksum. In the previous HIP drafts, the checksum was very carefully designed and placed so that it should be a trivial modification to make existing NAT-accelerators to update also HIP checksum if they can update the UDP checksum. That is, the checksum was in the same location and and computed in the same way as in UDP. At some point the location was chanced -- I don't remember any more why, perhaps due to pressure from SHIM6. But the computational characteristics should still be the same -- if they are not, that is a bug that should be fixed. I think it is important here to understand that there are well- established incremental algorithms that allow the checksum to be updated when the source and destination addresses in the pseudo header are updated. That's what all NAT boxes do for UDP and TCP. So, there is nothing new from that point of view. The same algorithms can be applied, and as I mentioned above, also in some cases the existing hardware accelerators can be updated. From a computational complexity point of view, updating the IP addresses in the real IP header take probably from maybe 15 to a few tens of instructions on a typical general purpose CPU. Read address to register (1), use it as an index to a hash table (5-10), read the hash bucket (3), write back the result (1). Looking at the trivial algorithm in RFC 1631, I get the impression that for fixed length update (as in this case), an optimised checksum update will take about 30 instructions. Other than those two, I would expect that a typical implementation CPU-based will use a few hundred machine instructions to handle a NATed packet. Hence, removing the pseudo-header from the checksum would reduce the computational load on a typical CPU-based NAT maybe 10%, at most. But take that figure with a grain of salt -- I didn't read through any specific kernel-based NAT code, just used my general knowledge about IP-layer programming. For hardware-based implementations, the biggest hurdle is the placement of the checksum. However, my understanding is that most hardware implementations are already flexible about the location of the checksum, since they must be able to cover both TCP and UDP, which have the checksum fields at different locations in the packet. Hence, I have a reason to believe that most hardware accelerations should be trivially upgradable to support HIP checksums. Given that, and given that all HIP packets but I1 either include an HMAC, a signature, or both, I don't see any real reason for the kind of checksums that you are proposing. In my opinion, it is either best to be as close to existing implementations as possible, or to remove checksums altogether, if they are no longer considered important. --Pekka Nikander On 20 Nov 2007, at 00:07, Spencer Dawkins wrote: > I asked Gonzalo for an opportunity to present a short draft in > Vancouver (http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum- > coverage-00.txt), and we're on the agenda for 10 minutes. > > Since that's a short interval, I'd like to ask people to provide > impressions before the meeting - on-list is fine. > > The short summary of the draft is: > > - HIP (NAT traversal and RVS) and other working groups (P2PSIP > HIPHOP) are working on applications that expect to relay HIP packets, > > - the current HIP checksums will terminate coverage at a HIP relay/ > NAT/HIPHOP peer. this requires the intermediate HIP(-aware) node to > recalculate the pseudoheader checksum, and provides no end-to-end > checksum coverage, so transmission errors introduced at the > intermediate node can't be detected by checksum failures, > > - if the HIP checksums were based on the HIP header and payload, > excluding any traditional transport pesudo-header fields > (especially IP addresses), checksum coverage would be end-to-end, and > > - (somewhat orthogonal to this) HIPHOP is planning to use HIP in > realtime signaling applications, and SIGTRAN (in the same space) > moved from the traditional "ones-complement-sum of the one's > complement" 16-bit checksum to a CRC32c checksum - so perhaps this > checksum calculation would be appropriate for HIP as well. > > That's the high-level overview. The details are in the draft. The > authors care what you think. Please let us know. > > Thanks, > > Spencer > > > _______________________________________________ > 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 Nov 24 06:36: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 1IvtJa-0008WJ-QA; Sat, 24 Nov 2007 06:36:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJY-0008V2-VL; Sat, 24 Nov 2007 06:36:49 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtJX-0001GM-Ug; Sat, 24 Nov 2007 06:36:48 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2b474835bb; Sat, 24 Nov 2007 19:49:45 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb74741a863; Mon, 19 Nov 2007 21:53:07 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 21:53:07 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65E-0004eK-80; Mon, 19 Nov 2007 07:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004dr-0c; Mon, 19 Nov 2007 07:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu65A-0004fM-Jr; Mon, 19 Nov 2007 07:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 797CD2AC5E; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001oh-7t; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-api-03.txt X-BeenThere: hipsec@lists.ietf.org Reply-To: internet-drafts@ietf.org 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 : Native Application Programming Interfaces (APIs) for Host Identity Protocol (HIP) Author(s) : M. Komu Filename : draft-ietf-hip-native-api-03.txt Pages : 14 Date : 2007-11-19 This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the initial discovery of public-key based identifiers. Using the extensions, the application can verify that the identifier is a Host Identity Tag (HIT) and it can require the system resolver to return only HITs from DNS. The application can also to explicitly allow more relaxed security models where the communication can be non-HIP based in the absence of a peer identifiers, or that the application allows peer identity to be discovered after initial contact directly with the peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.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-native-api-03.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-native-api-03.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-11-19074307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074307.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Nov 28 16:21: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 1IxULv-0002W5-9r; Wed, 28 Nov 2007 16:21:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxULt-0002Ve-LK for hipsec@ietf.org; Wed, 28 Nov 2007 16:21:49 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxULt-0007dB-8h for hipsec@ietf.org; Wed, 28 Nov 2007 16:21:49 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6973920476; Wed, 28 Nov 2007 22:21:48 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-62-474ddbec3ef0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5BFE42041F; Wed, 28 Nov 2007 22:21:48 +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, 28 Nov 2007 22:21:47 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 22:21:47 +0100 Received: from [131.160.126.196] (rvi2-126-196.lmf.ericsson.se [131.160.126.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4F27B262E; Wed, 28 Nov 2007 23:21:47 +0200 (EET) Message-ID: <474DDBFA.1050509@ericsson.com> Date: Wed, 28 Nov 2007 23:22:02 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 21:21:47.0625 (UTC) FILETIME=[AEEF8590:01C83204] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Hipsec] WGLC: draft-ietf-hip-native-api-03.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 Folks, I would like to WGLC the following draft: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt This WGLC will end on December 19th. Send your comments to the author and this list. 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 Wed Nov 28 18:23: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 1IxWFT-0006wa-Sw; Wed, 28 Nov 2007 18:23:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWFT-0006wK-1P for hipsec@ietf.org; Wed, 28 Nov 2007 18:23:19 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxWFS-0005Ti-6Z for hipsec@ietf.org; Wed, 28 Nov 2007 18:23:18 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 37FC22EE8; Thu, 29 Nov 2007 01:23:17 +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 F1555320A; Thu, 29 Nov 2007 01:23:09 +0200 (EET) Date: Thu, 29 Nov 2007 01:23:09 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] Re: API draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040499C4@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049995@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D040499C4@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: b22590c27682ace61775ee7b453b40d3 Cc: hipsec@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 Fri, 23 Nov 2007, Henderson, Thomas R wrote: Hi Tom, and sorry for the late response. > Miika, some responses below: > >> >> Added more text to section 3.2. "Interaction with the Resolver": >> >> The extensions in this document focus on the use of the >> resolver to >> map host names to HITs and locators in HIP-aware >> applications. The >> resolver associates implicitly the the HIT with the locator(s). >> However, it is possible that an application operates >> directly with a >> peer HIT without interacting with the resolver. In such >> a case, the >> application may resort to the system to map the peer HIT to an IP >> address. Alternatively, the application can explicitly >> map the HIT >> to an IP address as specified in >> [I-D.ietf-shim6-multihome-shim-api]. >> Both of these two approaches may be more prone to errors >> than the use >> resolver with host names. Hence, HIP-aware applications should >> prefer to use the resolver with host names. > > Can you specify which errors the resolver-less approach is more prone > to? The main concern is wow to map a HIT to an IP address in the current state of HIP deployment in DNS. Do you suggest to move the last two sentences? >>> It may be that you feel it is out of scope (section 2, para.3) but I >>> think it needs to be in scope, or if you feel that it is in >>> shim6-multihome, more of an overview presented here. >> >> I think this is out of scope. The multihoming APIs are >> briefly introduced >> in the sixth paragraph and currently I don't see urgent need >> to go into >> more details. The main feature that this API needs from the >> multihoming >> APIs are socket options for getting and setting the locators. If you >> disagree, please suggest some text. > > I will look at this issue some more and perhaps propose something if it > cannot be covered adequately by the shim6 multihome API draft. It may > need to be more clearly stated that this draft is only a subset of the > complete picture and that portions of the shim6 draft must also be > implemented for completeness. Is it ok if I reference the needed SHIM6 draft functionality in "5. Summary of New Definitions" ? >>> - section 4.2, I do not see why it is important to support >> non-ORCHID >>> HITs for backward compatibility. Maybe for forward >> compatibility? I >>> would just suggest to remove that paragraph, though. >> >> I repharased the text: >> >> The HIP_HIT_ANY_ macros also allow non-ORCHID based >> communications. >> To distinguish between ORCHID [RFC4843] and non-ORCHID-based >> communications in the case of the HIP_HIT_ANY_ macros, the >> application calls getsockname() and getpeername() to discover the >> actual identifiers used for the communications and verifies orchid >> prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a >> pointer to an in6_addr structure and returns 1 when the >> address has >> orchid prefix and 0 otherwise. Alternatively, the application can >> set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow >> only ORCHID- >> based communications. >> >> My point is that HIP_HIT_ANY macros would accept also normal TCP/IP >> communications by default. I hope my point is now more understandable? > > OK, I didn't understand that you meant non-ORCHID to mean IP addresses. We could also just use IN6ADDR_ANY if it would make things more clear? Unfortunately, this would mean that we'd discard the anon vs. public separation. > I think this section is still not clear with regard to what is passed in > the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator > passed?). Good catch. I was thinking about setsockopt with SHIM_LOC_PEER_PREF but I missed it in the text. The resolver cannot really do this on the behalf of the application because it does not have the socket. The thing that I don't like about this is that setsockopt introduces manual operation for opportunistic connections. The resolver is there to automatize things but I don't really see a clean solution for this in the resolver. Tom, are you ok with adding a sentence about the setsockopt? > > > Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR" > > portion of > > > the string? > > >> For two reasons of which are not very strong reasons IMHO. First, the >> other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it >> would be nice if >> both of the accessor macros share the same prefix. Second, >> the naming of >> the macro indicates that the macro checks an ipv6 address. In later >> extensions, we could have a macro that does the same for a public key. >> >> Would you still prefer e.g. HIP_IS_ANON_HIT? > > I do not see why HIP_IS_IPV6_ADDR_ORCHID needs it either, and yes, I > would still prefer to drop it. The macro is checking a 128-bit quantity > that is not necessarily an address. THIP_IS_IPV6_ADDR_ORCHID was suggested by Julien. Anyway, this is a minor issue and I can drop the IPV6_ADDR prefix from both the macros. -- 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 Nov 29 16:43: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 1IxrAP-0005XI-VA; Thu, 29 Nov 2007 16:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrAP-0005X7-2G for hipsec@ietf.org; Thu, 29 Nov 2007 16:43:29 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrAO-0005vo-7Z for hipsec@ietf.org; Thu, 29 Nov 2007 16:43:29 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lATLhEIc027901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2007 13:43:20 -0800 (PST) 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 lATLhEZt017265; Thu, 29 Nov 2007 13:43:14 -0800 (PST) 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 lATLhDxq017149; Thu, 29 Nov 2007 13:43:14 -0800 (PST) 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); Thu, 29 Nov 2007 13:43:11 -0800 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] Re: API draft Date: Thu, 29 Nov 2007 13:42:30 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040499D8@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Re: API draft Thread-Index: AcgyFak+lTKjD6l7SsOzzgMPePgBLQAuReSw References: <77F357662F8BFA4CA7074B0410171B6D04049995@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D040499C4@XCH-NW-5V1.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 29 Nov 2007 21:43:11.0957 (UTC) FILETIME=[D6DEC850:01C832D0] X-Spam-Score: -4.0 (----) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: hipsec@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 Miika, responses inline=20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Wednesday, November 28, 2007 3:23 PM > To: Henderson, Thomas R > Cc: hipsec@ietf.org > Subject: RE: [Hipsec] Re: API draft >=20 > On Fri, 23 Nov 2007, Henderson, Thomas R wrote: >=20 > Hi Tom, >=20 > and sorry for the late response. >=20 > > Miika, some responses below: > > > >> > >> Added more text to section 3.2. "Interaction with the Resolver": > >> > >> The extensions in this document focus on the use of the > >> resolver to > >> map host names to HITs and locators in HIP-aware > >> applications. The > >> resolver associates implicitly the the HIT with the locator(s). > >> However, it is possible that an application operates > >> directly with a > >> peer HIT without interacting with the resolver. In such > >> a case, the > >> application may resort to the system to map the peer=20 > HIT to an IP > >> address. Alternatively, the application can explicitly > >> map the HIT > >> to an IP address as specified in > >> [I-D.ietf-shim6-multihome-shim-api]. > >> Both of these two approaches may be more prone to errors > >> than the use > >> resolver with host names. Hence, HIP-aware applications should > >> prefer to use the resolver with host names. > > > > Can you specify which errors the resolver-less approach is=20 > more prone > > to? >=20 > The main concern is wow to map a HIT to an IP address in the=20 > current state=20 > of HIP deployment in DNS. Do you suggest to move the last two=20 > sentences? I just want to understand what the assumed error risk is. You seem to be saying that indirecting through the DNS is less error prone than directly providing the HIT to IP address binding at the API. Is that because you are assuming that handling HITs is an error prone operation (as compared with DNS names) for either applications or users? =20 I think it should either be more specified to state what the presumed error is, or else remove the last two sentences. >=20 > >>> It may be that you feel it is out of scope (section 2,=20 > para.3) but I > >>> think it needs to be in scope, or if you feel that it is in > >>> shim6-multihome, more of an overview presented here. > >> > >> I think this is out of scope. The multihoming APIs are > >> briefly introduced > >> in the sixth paragraph and currently I don't see urgent need > >> to go into > >> more details. The main feature that this API needs from the > >> multihoming > >> APIs are socket options for getting and setting the=20 > locators. If you > >> disagree, please suggest some text. > > > > I will look at this issue some more and perhaps propose=20 > something if it > > cannot be covered adequately by the shim6 multihome API=20 > draft. It may > > need to be more clearly stated that this draft is only a=20 > subset of the > > complete picture and that portions of the shim6 draft must also be > > implemented for completeness. >=20 > Is it ok if I reference the needed SHIM6 draft functionality in "5.=20 > Summary of New Definitions" ? That would be fine for now. It should be clearly stated that to completely implement this native API, you need to implement this draft plus sections of another draft. >=20 > >>> - section 4.2, I do not see why it is important to support > >> non-ORCHID > >>> HITs for backward compatibility. Maybe for forward > >> compatibility? I > >>> would just suggest to remove that paragraph, though. > >> > >> I repharased the text: > >> > >> The HIP_HIT_ANY_ macros also allow non-ORCHID based > >> communications. > >> To distinguish between ORCHID [RFC4843] and non-ORCHID-based > >> communications in the case of the HIP_HIT_ANY_ macros, the > >> application calls getsockname() and getpeername() to=20 > discover the > >> actual identifiers used for the communications and=20 > verifies orchid > >> prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a > >> pointer to an in6_addr structure and returns 1 when the > >> address has > >> orchid prefix and 0 otherwise. Alternatively, the=20 > application can > >> set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow > >> only ORCHID- > >> based communications. > >> > >> My point is that HIP_HIT_ANY macros would accept also normal TCP/IP > >> communications by default. I hope my point is now more=20 > understandable? > > > > OK, I didn't understand that you meant non-ORCHID to mean=20 > IP addresses. >=20 > We could also just use IN6ADDR_ANY if it would make things=20 > more clear?=20 > Unfortunately, this would mean that we'd discard the anon vs. public=20 > separation. Can you specify one or more use cases where HIP_HIT_ANY macro would be used to allow TCP/IP communications (what would be the sequence of calls and setting of the sockaddr_hip fields)? The phrase "backward compatibility" is a bit too vague. >=20 > > I think this section is still not clear with regard to what=20 > is passed in > > the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator > > passed?). >=20 > Good catch. I was thinking about setsockopt with=20 > SHIM_LOC_PEER_PREF but I=20 > missed it in the text. The resolver cannot really do this on=20 > the behalf of=20 > the application because it does not have the socket. >=20 > The thing that I don't like about this is that setsockopt introduces=20 > manual operation for opportunistic connections. The resolver is there=20 > to automatize things but I don't really see a clean solution for=20 > this in the resolver. >=20 > Tom, are you ok with adding a sentence about the setsockopt? Yes, I think that it needs to be there, since there are no locators in the proposed sockaddr_hip structure. >=20 > > > > Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR" > > > portion of > > > > the string? > > > > >> For two reasons of which are not very strong reasons IMHO.=20 > First, the > >> other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it > >> would be nice if > >> both of the accessor macros share the same prefix. Second, > >> the naming of > >> the macro indicates that the macro checks an ipv6 address. In later > >> extensions, we could have a macro that does the same for a=20 > public key. > >> > >> Would you still prefer e.g. HIP_IS_ANON_HIT? > > > > I do not see why HIP_IS_IPV6_ADDR_ORCHID needs it either, and yes, I > > would still prefer to drop it. The macro is checking a=20 > 128-bit quantity > > that is not necessarily an address. >=20 > THIP_IS_IPV6_ADDR_ORCHID was suggested by Julien. Anyway,=20 > this is a minor=20 > issue and I can drop the IPV6_ADDR prefix from both the macros. >=20 OK, I would be in favor of that. Tom >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Nov 30 19:13: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 1IyFzD-0004MD-Dn; Fri, 30 Nov 2007 19:13:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFzB-0004LY-B5 for hipsec@ietf.org; Fri, 30 Nov 2007 19:13:33 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyFzA-0008Am-A2 for hipsec@ietf.org; Fri, 30 Nov 2007 19:13:33 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AB25733DA; Sat, 1 Dec 2007 02:13:31 +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 A0F3F33DA; Sat, 1 Dec 2007 02:13:24 +0200 (EET) Date: Sat, 1 Dec 2007 02:13:24 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] Re: API draft In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040499D8@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049995@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D040499C4@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D040499D8@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: bacfc6c7290e34d410f9bc22b825ce96 Cc: hipsec@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, 29 Nov 2007, Henderson, Thomas R wrote: Hi, >>> Miika, some responses below: >>> >>>> >>>> Added more text to section 3.2. "Interaction with the Resolver": >>>> >>>> The extensions in this document focus on the use of the >>>> resolver to >>>> map host names to HITs and locators in HIP-aware >>>> applications. The >>>> resolver associates implicitly the the HIT with the locator(s). >>>> However, it is possible that an application operates >>>> directly with a >>>> peer HIT without interacting with the resolver. In such >>>> a case, the >>>> application may resort to the system to map the peer >> HIT to an IP >>>> address. Alternatively, the application can explicitly >>>> map the HIT >>>> to an IP address as specified in >>>> [I-D.ietf-shim6-multihome-shim-api]. >>>> Both of these two approaches may be more prone to errors >>>> than the use >>>> resolver with host names. Hence, HIP-aware applications should >>>> prefer to use the resolver with host names. >>> >>> Can you specify which errors the resolver-less approach is >> more prone >>> to? >> >> The main concern is wow to map a HIT to an IP address in the >> current state >> of HIP deployment in DNS. Do you suggest to move the last two >> sentences? > > I just want to understand what the assumed error risk is. You seem to > be saying that indirecting through the DNS is less error prone than > directly providing the HIT to IP address binding at the API. Is that > because you are assuming that handling HITs is an error prone operation > (as compared with DNS names) for either applications or users? > > I think it should either be more specified to state what the presumed > error is, or else remove the last two sentences. Will remove them. > >>>>> It may be that you feel it is out of scope (section 2, >> para.3) but I >>>>> think it needs to be in scope, or if you feel that it is in >>>>> shim6-multihome, more of an overview presented here. >>>> >>>> I think this is out of scope. The multihoming APIs are >>>> briefly introduced >>>> in the sixth paragraph and currently I don't see urgent need >>>> to go into >>>> more details. The main feature that this API needs from the >>>> multihoming >>>> APIs are socket options for getting and setting the >> locators. If you >>>> disagree, please suggest some text. >>> >>> I will look at this issue some more and perhaps propose >> something if it >>> cannot be covered adequately by the shim6 multihome API >> draft. It may >>> need to be more clearly stated that this draft is only a >> subset of the >>> complete picture and that portions of the shim6 draft must also be >>> implemented for completeness. >> >> Is it ok if I reference the needed SHIM6 draft functionality in "5. >> Summary of New Definitions" ? > > That would be fine for now. It should be clearly stated that to > completely implement this native API, you need to implement this draft > plus sections of another draft. Ok. >>>>> - section 4.2, I do not see why it is important to support >>>> non-ORCHID >>>>> HITs for backward compatibility. Maybe for forward >>>> compatibility? I >>>>> would just suggest to remove that paragraph, though. >>>> >>>> I repharased the text: >>>> >>>> The HIP_HIT_ANY_ macros also allow non-ORCHID based >>>> communications. >>>> To distinguish between ORCHID [RFC4843] and non-ORCHID-based >>>> communications in the case of the HIP_HIT_ANY_ macros, the >>>> application calls getsockname() and getpeername() to >> discover the >>>> actual identifiers used for the communications and >> verifies orchid >>>> prefix with HIP_IS_IPV6_ADDR_ORCHID macro. The macro inputs a >>>> pointer to an in6_addr structure and returns 1 when the >>>> address has >>>> orchid prefix and 0 otherwise. Alternatively, the >> application can >>>> set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow >>>> only ORCHID- >>>> based communications. >>>> >>>> My point is that HIP_HIT_ANY macros would accept also normal TCP/IP >>>> communications by default. I hope my point is now more >> understandable? >>> >>> OK, I didn't understand that you meant non-ORCHID to mean >> IP addresses. >> >> We could also just use IN6ADDR_ANY if it would make things >> more clear? >> Unfortunately, this would mean that we'd discard the anon vs. public >> separation. > > Can you specify one or more use cases where HIP_HIT_ANY macro would be > used to allow TCP/IP communications (what would be the sequence of calls > and setting of the sockaddr_hip fields)? Well the use case is that you want to run e.g. http server in a port that serves both HIP and non-HIP-based communications. 1) Via resolver struct addrinfo hints, *res; struct sockaddr_hip *ship; int sock; hints.ai_flags = AI_HIP hints.ai_socktype = SOCK_STREAM; getaddrinfo(NULL, "http", &hints, &res); ship = (struct sockaddr_hip *) (*res)->ai_addr; sock = socket((*res)->ai_family, (*res)->ai_socktype, 0); bind((sock, (*res)->ai_addr, (*res)->ai_addrlen,); listen(..); accept(..) 2) Manually struct sockaddr_hip ship; memset(&ship, 0, sizeof(ship)); ship.ship_len = sizeof(ship)); ship.ship_family = PF_HIP; ship.ship_port = htons(80); ship_hit.hit = { HIP_HIT_ANY }; bind((sock, &ship, sizeof(ship)); listen(..); accept(..) > The phrase "backward compatibility" is a bit too vague. I removed the prase it from the rephrased text above. >>> I think this section is still not clear with regard to what >> is passed in >>> the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator >>> passed?). >> >> Good catch. I was thinking about setsockopt with >> SHIM_LOC_PEER_PREF but I >> missed it in the text. The resolver cannot really do this on >> the behalf of >> the application because it does not have the socket. >> >> The thing that I don't like about this is that setsockopt introduces >> manual operation for opportunistic connections. The resolver is there >> to automatize things but I don't really see a clean solution for >> this in the resolver. >> >> Tom, are you ok with adding a sentence about the setsockopt? > > Yes, I think that it needs to be there, since there are no locators in > the proposed sockaddr_hip structure. Ok. >>>>> Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR" >>>> portion of >>>>> the string? >>>> >>>> For two reasons of which are not very strong reasons IMHO. >> First, the >>>> other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it >>>> would be nice if >>>> both of the accessor macros share the same prefix. Second, >>>> the naming of >>>> the macro indicates that the macro checks an ipv6 address. In later >>>> extensions, we could have a macro that does the same for a >> public key. >>>> >>>> Would you still prefer e.g. HIP_IS_ANON_HIT? >>> >>> I do not see why HIP_IS_IPV6_ADDR_ORCHID needs it either, and yes, I >>> would still prefer to drop it. The macro is checking a >> 128-bit quantity >>> that is not necessarily an address. >> >> THIP_IS_IPV6_ADDR_ORCHID was suggested by Julien. Anyway, >> this is a minor >> issue and I can drop the IPV6_ADDR prefix from both the macros. >> > > OK, I would be in favor of that. Ok. The changes that you suggested can be found from the next preversion: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-04-pre1.txt -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec