From ticsa-info-admin@honor.trusecure.com Sat Jan 1 05:01:19 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04661 for ; Sat, 1 Jan 2005 05:01:19 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id ED5447316 for ; Sat, 1 Jan 2005 05:00:43 -0500 (EST) Date: Sat, 01 Jan 2005 05:00:43 -0500 Message-ID: <20050101100043.14439.19734.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: mailman-owner@honor.icsalabs.com To: hip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: ticsa-info-admin@honor.trusecure.com Errors-To: ticsa-info-admin@honor.trusecure.com X-BeenThere: ticsa-info@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your honor.trusecure.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hipsec-request@honor.trusecure.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@honor. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@honor.trusecure.com fewefo http://honor.trusecure.com/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-admin@honor.trusecure.com Tue Jan 4 04:47:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27342 for ; Tue, 4 Jan 2005 04:47:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9FD727313; Tue, 4 Jan 2005 04:47:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from nairobi.ucdavis.edu (nairobi.ucdavis.edu [169.237.104.168]) by honor.icsalabs.com (Postfix) with ESMTP id D2910730C for ; Tue, 4 Jan 2005 04:46:04 -0500 (EST) Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by nairobi.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j049k1K1022767 for ; Tue, 4 Jan 2005 01:46:02 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j049k1vc006362 for ; Tue, 4 Jan 2005 01:46:01 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id j049k1Xk006361; Tue, 4 Jan 2005 01:46:01 -0800 (PST) Message-Id: <200501040946.j049k1Xk006361@phaenicia.ucdavis.edu> To: hipsec@honor.trusecure.com From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 Subject: [Hipsec] Call for Papers: IEEE JSAC MRNM Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 4 Jan 2005 01:46:01 -0800 (PST) Date: Tue, 4 Jan 2005 01:46:01 -0800 (PST) PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 05:00:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00541 for ; Fri, 7 Jan 2005 05:00:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 712E672E6; Fri, 7 Jan 2005 05:00:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id E7E0B72E2 for ; Fri, 7 Jan 2005 04:59:03 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j079x4Vu023360 for ; Fri, 7 Jan 2005 02:59:05 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9X00HNVYEGP6@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 07 Jan 2005 02:59:04 -0700 (MST) Received: from [10.0.0.68] ([83.145.97.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9X00HGJYEE9I@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 07 Jan 2005 02:59:04 -0700 (MST) From: Julien Laganier In-reply-to: To: hipsec@honor.trusecure.com, Pekka Nikander Cc: Tschofenig Hannes , Andrei Gurtov , Teemu Koponen Message-id: <200501071101.08553.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <2A8DB02E3018D411901B009027FD3A3F0550B916@mchp905a.mch.sbs.de> <200501061451.43560.julien.laganier@sun.com> Subject: [Hipsec] Re: Service Definition (Was: question on the hip registration protocol) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 07 Jan 2005 11:01:08 +0100 Date: Fri, 07 Jan 2005 11:01:08 +0100 Content-Transfer-Encoding: 7BIT Folks, We were privately discussing the definition of a service in the context of the HIP registration: A HIP node (the requester) register for a service (such as Rendezvous, or Firewall traversal) at another HIP node (the registrar). In the discussion below, we were trying to came up with an appropriate definition of service in this specific context. On Friday 07 January 2005 08:06, Pekka Nikander wrote: > > Julien Laganier wrote: > > > In the terminoly section, we miss the definition of a service; I > > propose we use: > > > > Service: A facility supplying some public demand (e.g. Firewall > > traversal, Rendezvous, etc.) > > I agree that we seem to need such a definition, but I also think > that we need to be more careful here. Basically, we don't want > all kinds of "services" to be served through the HIP protocol. > (Or do we?) That is, at least for the time being, we should > explicitly limit the services to ones that enhance the capabilities > of HIP. Firewall traversal and Rendezvous are good example. > E-mail notifications or Instant Messaging would be bad examples. I fully agree with Pekka's opinion; i.e. we don't want all kinds of "services" to be served through the HIP protocol. Here's a new definition matching your proposal: Service: A facility supplying enhanced capabilities to the HIP protocol (e.g. Firewall traversal, Rendezvous, etc.). What do you think? --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 05:16:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01672 for ; Fri, 7 Jan 2005 05:16:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 386B672F2; Fri, 7 Jan 2005 05:16:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 945C872E2 for ; Fri, 7 Jan 2005 05:15:53 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j07AFudt009187 for ; Fri, 7 Jan 2005 03:15:56 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0I9X00IMAZ6J2F@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 07 Jan 2005 03:15:56 -0700 (MST) Received: from [10.0.0.68] ([83.145.97.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0I9X00H4WZ6H94@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 07 Jan 2005 03:15:55 -0700 (MST) From: Julien Laganier In-reply-to: To: hipsec@honor.trusecure.com, Pekka Nikander Cc: Tschofenig Hannes , Andrei Gurtov , Teemu Koponen Message-id: <200501071118.00285.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <2A8DB02E3018D411901B009027FD3A3F0550B916@mchp905a.mch.sbs.de> <200501061113.03122.julien.laganier@sun.com> Subject: [Hipsec] Re: Registration vs. Association (Was: question on the hip registration protocol) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 07 Jan 2005 11:17:59 +0100 Date: Fri, 07 Jan 2005 11:17:59 +0100 Content-Transfer-Encoding: 7BIT Folks, Another private discussion we had, dealing with the differences between an association and a registration in the context of HIP. Basically a registration is an association, plus some other state related to the service for which the requester has sign-up at the registrar. In the firewall traversal case, the registration-specific state might be the protocol and port numbers allowed to pass through. I was wondering if a registration might be a degraded association, i.e. it has less state (keying material) or less capabilities (update of locators or rekeying). Your thoughts on the subject are welcomed. On Friday 07 January 2005 08:15, Pekka Nikander wrote: > > > What make a registration different from an association? Is it > > only the fact that the requester register for some services, i.e. > > it establish some additional states in the parties involved? > > In my opinion, yes. I think that crux is the additional state. Ok. > > Or is the > > registration a lightweight, soft-state HIP association in which > > selective parts of the HIP state are thrown away, resulting in an > > association which has less capabilities (e.g. it can't be > > rekeyed). > > Well, that might be a side effect of *some* services, but IMHO > that would be orthogonal to the basic registration. If we > see that as a component common to many services that rely on > the registration, most probably we should write another draft > defining such a mechanism. However, right now I feel that such > a thing would be premature. That's fine with me. So we'd specify that a registration _is_ an association _plus_ some state. Then, another specification (e.g. Rendezvous) may specify other requirements rendering the registration they define something less than a full blown association... But such behavior would be registration-type specific and would not be specified in the the registration protocol document, like you proposed. > > Here are the excerpts and discussion: > > > > -- The management of the registrations requires a REG_REQUEST - > > REG_RESPONSE exchange over a pair of UPDATE packets -- > > > > ==> Perhaps "(...) over a pair of UPDATE packets which does not > > request rekeying of the association" > > Well, as ESP is being split out from the base spec, the base spec > does not even mention rekeying any more. Ok. > > -- However, the presence of the registration parameters defined > > in this specification SHOULD NOT render the usage of the HIP > > association impossible for other purposes. In other words, the > > registration parameters enhance the base exchange, but they do > > not change its basic meaning. -- > > Well, I still need to think more about this, but my initial > reaction is that SHOULD NOT sounds like the right level. But I am > also open to leaving this unspecified, i.e., removing this piece of > text out from the draft. > > > ==> Perhaps s/SHOULD/MAY/. I have the feeling that some > > registrations might not maintain a HIP association but only the > > registration state. > > That would make it pretty hard to use UPDATE to renew the state. > Unless the state is very long lasting (expiration time in days or > longer), I don't really see any reason why the registrar should > through out the keying material. After thinking more about this, I agree with you. SHOULD NOT sounds like the appropriate requirement level, and leave the opportunity for a future 'service/registration' specification to specify selective deletion of parts of the association state, and specific restrictions in place. > > For example, in the rendezvous case, the parties would only > > retains symmetric integrity keys, and requester HIT and IP > > address. That would allow a RVS to support more requesters > > because it does not have to store their public keys. > > AFAIK, you don't need to store the public keys to keep up the HIP > association. All the messages besides the first few also contain > the HMAC, which should be sufficient, and verifying the SIG in > the presence of HMAC is OPTIONAL. Or isn't it so? Maybe I have > missed something? Ooops, I was talking about the D-H Kij needed to rekey. Anyway perhaps it's not that important to save a few kBs per registration; I have no strong feeling on the question. Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 05:35:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02751 for ; Fri, 7 Jan 2005 05:35:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 83C48730C; Fri, 7 Jan 2005 05:35:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by honor.icsalabs.com (Postfix) with ESMTP id DDA3772E2 for ; Fri, 7 Jan 2005 05:34:40 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j07AYbVi020930; Fri, 7 Jan 2005 11:34:37 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j07AYaUt027380; Fri, 7 Jan 2005 11:34:36 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Jan 2005 11:34:36 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550BA7E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Julien Laganier , hipsec@honor.trusecure.com, Pekka Nikander Cc: Andrei Gurtov , Teemu Koponen MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Hipsec] RE: Registration vs. Association (Was: question on the hip regist ration protocol) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 7 Jan 2005 11:34:27 +0100 Date: Fri, 7 Jan 2005 11:34:27 +0100 hi julien, thanks for raising this issue. please see my comment below: > Folks, > > Another private discussion we had, dealing with the > differences between an association and a registration in the > context of HIP. > > Basically a registration is an association, plus some other > state related to the service for which the requester has > sign-up at the registrar. In the firewall traversal case, the > registration-specific state might be the protocol and port > numbers allowed to pass through. > > I was wondering if a registration might be a degraded > association, i.e. it has less state (keying material) or less > capabilities (update of locators or rekeying). there are two types of state established with a registration (or association protocol): - security related state: this is state established with the "modified" hip protocol (minus ipsec sa establishment). basically it contains of information negotiated with the HIP_TRANSFORM and keying material. there is no reason why this should have a "lower" quality than in the base hip protocol. - state related to the "service": you are right that in case of firewall signaling this will be information related to source/destination ip address and spi (if you want to allow ipsec protected data traffic to traverse). a separate question is regarding the usage of certain features of the registreation protocol. i think that it would be good to reuse the capabilities of the base protocol and extensions (e.g., multi-homing and mobility). ciao hannes > > Your thoughts on the subject are welcomed. > > On Friday 07 January 2005 08:15, Pekka Nikander wrote: > > > > > What make a registration different from an association? > Is it only > > > the fact that the requester register for some services, i.e. > > > it establish some additional states in the parties involved? > > > > In my opinion, yes. I think that crux is the additional state. > > Ok. > > > > Or is the > > > registration a lightweight, soft-state HIP association in which > > > selective parts of the HIP state are thrown away, resulting in an > > > association which has less capabilities (e.g. it can't be > rekeyed). > > > > Well, that might be a side effect of *some* services, but IMHO that > > would be orthogonal to the basic registration. If we see that as a > > component common to many services that rely on the > registration, most > > probably we should write another draft defining such a mechanism. > > However, right now I feel that such a thing would be premature. > > That's fine with me. So we'd specify that a registration _is_ > an association _plus_ some state. Then, another specification (e.g. > Rendezvous) may specify other requirements rendering the > registration they define something less than a full blown > association... > > But such behavior would be registration-type specific and > would not be specified in the the registration protocol > document, like you proposed. > > > > Here are the excerpts and discussion: > > > > > > -- The management of the registrations requires a REG_REQUEST - > > > REG_RESPONSE exchange over a pair of UPDATE packets -- > > > > > > ==> Perhaps "(...) over a pair of UPDATE packets which does not > > > request rekeying of the association" > > > > Well, as ESP is being split out from the base spec, the > base spec does > > not even mention rekeying any more. > > Ok. > > > > -- However, the presence of the registration parameters > defined in > > > this specification SHOULD NOT render the usage of the HIP > > > association impossible for other purposes. In other words, the > > > registration parameters enhance the base exchange, but > they do not > > > change its basic meaning. -- > > > > Well, I still need to think more about this, but my initial > reaction > > is that SHOULD NOT sounds like the right level. But I am > also open to > > leaving this unspecified, i.e., removing this piece of text > out from > > the draft. > > > > > ==> Perhaps s/SHOULD/MAY/. I have the feeling that some > > > registrations might not maintain a HIP association but only the > > > registration state. > > > > That would make it pretty hard to use UPDATE to renew the state. > > Unless the state is very long lasting (expiration time in days or > > longer), I don't really see any reason why the registrar should > > through out the keying material. > > After thinking more about this, I agree with you. SHOULD NOT > sounds like the appropriate requirement level, and leave the > opportunity for a future 'service/registration' specification > to specify selective deletion of parts of the association > state, and specific restrictions in place. > > > > For example, in the rendezvous case, the parties would > only retains > > > symmetric integrity keys, and requester HIT and IP address. That > > > would allow a RVS to support more requesters because it does not > > > have to store their public keys. > > > > AFAIK, you don't need to store the public keys to keep up the HIP > > association. All the messages besides the first few also > contain the > > HMAC, which should be sufficient, and verifying the SIG in the > > presence of HMAC is OPTIONAL. Or isn't it so? Maybe I have missed > > something? > > Ooops, I was talking about the D-H Kij needed to rekey. > > Anyway perhaps it's not that important to save a few kBs per > registration; I have no strong feeling on the question. > > Thanks, > > --julien > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 05:44:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03135 for ; Fri, 7 Jan 2005 05:44:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D8B48730C; Fri, 7 Jan 2005 05:44:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by honor.icsalabs.com (Postfix) with ESMTP id 245B172F2 for ; Fri, 7 Jan 2005 05:43:46 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j07AhnVi027320; Fri, 7 Jan 2005 11:43:49 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j07AhmUt001760; Fri, 7 Jan 2005 11:43:48 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Jan 2005 11:43:48 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550BA81@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Teemu Koponen , Julien Laganier Cc: Pekka Nikander , Andrei Gurtov , hipsec@honor.trusecure.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Hipsec] RE: Registration vs. Association Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 7 Jan 2005 11:43:37 +0100 Date: Fri, 7 Jan 2005 11:43:37 +0100 Content-Transfer-Encoding: quoted-printable hi, i don't quite understand the difference between registration and association.=20 it might only be a terminology issue but what we need is:=20 * a protocol that allows an entity a to communicate with an entity b to = - authenticate/authorize each other - establish a security association (not an ipsec sa) - "only" keying material & algorithms the protocol should provide some basic security features, such as dos protection.=20 obviously the protocol should be "lighweight".=20 * only creating registration protocol specific state is fun (to protect signaling messages between entity a and entity b) but there will = typically be a little bit more about it. in the rvs draft you describe the = additional pieces that are required for rvs to work. for middleboxes the = information will again be different and for hi3 it will be different again.=20 from this point of view i think it would be good to keep the = registration protocol simple and generic. it seems to be useful in some scenarios. the fact that we want to reuse the hip protocol as a registration = protocol (and an existing protocol in general) makes the description fairly = short. this is also good. there are certainly other candidates as well but i personally prefer hip.=20 ciao hannes > -----Original Message----- > From: Teemu Koponen [mailto:tkoponen@iki.fi]=20 > Sent: Freitag, 07. J=E4nner 2005 11:32 > To: Julien Laganier > Cc: Tschofenig Hannes; Pekka Nikander; Andrei Gurtov;=20 > hipsec@honor.trusecure.com > Subject: Re: Registration vs. Association >=20 > On Jan 7, 2005, at 12:17, Julien Laganier wrote: >=20 > >> Well, that might be a side effect of *some* services, but=20 > IMHO that=20 > >> would be orthogonal to the basic registration. If we see=20 > that as a=20 > >> component common to many services that rely on the=20 > registration, most=20 > >> probably we should write another draft defining such a mechanism. = > >> However, right now I feel that such a thing would be premature. > > > > That's fine with me. So we'd specify that a registration _is_ an=20 > > association _plus_ some state. Then, another specification (e.g. > > Rendezvous) may specify other requirements rendering the=20 > registration=20 > > they define something less than a full blown association... > > > > But such behavior would be registration-type specific and=20 > would not be=20 > > specified in the the registration protocol document, like you=20 > > proposed. >=20 > I am more prone to see registration and association as=20 > separate matters. While the registration specification is=20 > about explicit registering, I think it might be wise to=20 > consider implicit registering too. That is, not to include it=20 > to the registration specification, but not to forget it when=20 > defining these terms. I see registration protocol to be only=20 > a single path, but not the only one, to establish a=20 > registration (state) that is required to deliver service(s)=20 > for a HIP host. >=20 > Teemu >=20 > -- >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 08:26:39 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12649 for ; Fri, 7 Jan 2005 08:26:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 74FA572F2; Fri, 7 Jan 2005 08:26:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 263B472E6 for ; Fri, 7 Jan 2005 08:25:29 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D3EFF212DAC; Fri, 7 Jan 2005 15:25:18 +0200 (EET) In-Reply-To: <6BA0A8B1-6097-11D9-AD2B-000D933B530A@iki.fi> References: <2A8DB02E3018D411901B009027FD3A3F0550B916@mchp905a.mch.sbs.de> <200501061113.03122.julien.laganier@sun.com> <200501071118.00285.julien.laganier@sun.com> <6BA0A8B1-6097-11D9-AD2B-000D933B530A@iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9928E2EC-60AF-11D9-A508-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Tschofenig Hannes , Julien Laganier , Andrei Gurtov , hipsec@honor.trusecure.com From: Pekka Nikander To: Teemu Koponen X-Mailer: Apple Mail (2.619) Subject: [Hipsec] Re: Registration vs. Association Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 7 Jan 2005 15:25:28 +0200 Date: Fri, 7 Jan 2005 15:25:28 +0200 Content-Transfer-Encoding: 7bit > I am more prone to see registration and association as separate > matters. From a pure architectural point of view, I agree with you, but I fail to get your point. In practise, in 99% of the cases that I can foresee, you need authentication etc. before you can do registration. Hence, maybe in 99% of those 99% cases, you most probably want to use a registration protocol that is based on the base exchange. > While the registration specification is about explicit registering, I > think it might be wise to consider implicit registering too. That is, > not to include it to the registration specification, but not to forget > it when defining these terms. I see registration protocol to be only a > single path, but not the only one, to establish a registration (state) > that is required to deliver service(s) for a HIP host. What's the news here? Even if you have the world's best hammer, it is still sometimes better to use a screwdriver, isn't it? The fact that you *standardize* A doesn't mean that you can't use B. (Here I must admit that I've seen people claiming that if A is a standard you can't use B, but I consider such claims utterly silly. And then, market dynamics is a third matter, still separate from what is standardised and what can or cannot be used.) --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 08:30:32 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12877 for ; Fri, 7 Jan 2005 08:30:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 59FFD72F2; Fri, 7 Jan 2005 08:30:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id CA64072E6 for ; Fri, 7 Jan 2005 08:29:17 -0500 (EST) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 85298212DAC for ; Fri, 7 Jan 2005 15:29:18 +0200 (EET) Message-ID: <41DE8EAE.9040300@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base HIP: 02 PRE1 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 07 Jan 2005 15:29:18 +0200 Date: Fri, 07 Jan 2005 15:29:18 +0200 Content-Transfer-Encoding: 7bit Folks, You can find the current pre-version, draft-ietf-hip-base-02-pre1, of the base draft in: http://hip4inter.net/drafts.php There are txt and html versions as well as the diff from -01 version. The major edition is the removal of the ESP stuff (including rekeying) from it. There are still some XXXs where text is missing / needs some attention. Please read and comment (and provide text if you feel so). The removed ESP text is moved to a new draft. I will be back with that draft next week. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 09:02:32 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15274 for ; Fri, 7 Jan 2005 09:02:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 89CA2730C; Fri, 7 Jan 2005 09:02:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 1858B72F2 for ; Fri, 7 Jan 2005 08:47:32 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B82542F6F; Fri, 7 Jan 2005 15:47:32 +0200 (EET) Received: from [IPv6???1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E83AE2F6F; Fri, 7 Jan 2005 15:47:31 +0200 (EET) In-Reply-To: <9928E2EC-60AF-11D9-A508-000D9331AFB0@nomadiclab.com> References: <2A8DB02E3018D411901B009027FD3A3F0550B916@mchp905a.mch.sbs.de> <200501061113.03122.julien.laganier@sun.com> <200501071118.00285.julien.laganier@sun.com> <6BA0A8B1-6097-11D9-AD2B-000D933B530A@iki.fi> <9928E2EC-60AF-11D9-A508-000D9331AFB0@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Tschofenig Hannes , Julien Laganier , Andrei Gurtov , hipsec@honor.trusecure.com From: Teemu Koponen To: Pekka Nikander X-Mailer: Apple Mail (2.619) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.0-niksula20040914 (2004-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.0-niksula20040914 Subject: [Hipsec] Re: Registration vs. Association Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 7 Jan 2005 15:47:31 +0200 Date: Fri, 7 Jan 2005 15:47:31 +0200 Content-Transfer-Encoding: 7bit On Jan 7, 2005, at 15:25, Pekka Nikander wrote: >> I am more prone to see registration and association as separate >> matters. > > From a pure architectural point of view, I agree with you, but I fail > to get your point. In practise, in 99% of the cases that I can > foresee, you need authentication etc. before you can do registration. > Hence, maybe in 99% of those 99% cases, you most probably want to use > a registration protocol that is based on the base exchange. I was too inaccurate it seems, as I do fully agree with you (and Hannes) about using a base exchange based registration protocol. I was merely (over-) emphasizing that the additional state spanning over requester, (registrar,) *and* service is something that may also emerge by other means, which is of course out of context from the HIP registration protocol point of view. So, it was just a little nuance that the plus sign Julien used raised within me. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 7 09:04:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15513 for ; Fri, 7 Jan 2005 09:04:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id ECA3F730C; Fri, 7 Jan 2005 09:04:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 236E172E2 for ; Fri, 7 Jan 2005 05:32:23 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C4FBD3009; Fri, 7 Jan 2005 12:32:25 +0200 (EET) Received: from [IPv6???1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 394682FD1; Fri, 7 Jan 2005 12:32:25 +0200 (EET) In-Reply-To: <200501071118.00285.julien.laganier@sun.com> References: <2A8DB02E3018D411901B009027FD3A3F0550B916@mchp905a.mch.sbs.de> <200501061113.03122.julien.laganier@sun.com> <200501071118.00285.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6BA0A8B1-6097-11D9-AD2B-000D933B530A@iki.fi> Content-Transfer-Encoding: 7bit Cc: Tschofenig Hannes , Pekka Nikander , Andrei Gurtov , hipsec@honor.trusecure.com From: Teemu Koponen To: Julien Laganier X-Mailer: Apple Mail (2.619) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.0-niksula20040914 (2004-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.0-niksula20040914 Subject: [Hipsec] Re: Registration vs. Association Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 7 Jan 2005 12:32:24 +0200 Date: Fri, 7 Jan 2005 12:32:24 +0200 Content-Transfer-Encoding: 7bit On Jan 7, 2005, at 12:17, Julien Laganier wrote: >> Well, that might be a side effect of *some* services, but IMHO >> that would be orthogonal to the basic registration. If we >> see that as a component common to many services that rely on >> the registration, most probably we should write another draft >> defining such a mechanism. However, right now I feel that such >> a thing would be premature. > > That's fine with me. So we'd specify that a registration _is_ an > association _plus_ some state. Then, another specification (e.g. > Rendezvous) may specify other requirements rendering the registration > they define something less than a full blown association... > > But such behavior would be registration-type specific and would not be > specified in the the registration protocol document, like you > proposed. I am more prone to see registration and association as separate matters. While the registration specification is about explicit registering, I think it might be wise to consider implicit registering too. That is, not to include it to the registration specification, but not to forget it when defining these terms. I see registration protocol to be only a single path, but not the only one, to establish a registration (state) that is required to deliver service(s) for a HIP host. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 11 07:03:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16149 for ; Tue, 11 Jan 2005 07:03:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 988167322; Tue, 11 Jan 2005 07:03:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 39B07731F for ; Tue, 11 Jan 2005 07:02:42 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7AEF4212CF0; Tue, 11 Jan 2005 14:02:37 +0200 (EET) In-Reply-To: <41DE8EAE.9040300@nomadiclab.com> References: <41DE8EAE.9040300@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Petri Jokela From: Pekka Nikander Subject: Re: [Hipsec] Base HIP: 02 PRE1 To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 11 Jan 2005 14:02:50 +0200 Date: Tue, 11 Jan 2005 14:02:50 +0200 Content-Transfer-Encoding: 7bit > You can find the current pre-version, draft-ietf-hip-base-02-pre1, of > the base draft in: > > http://hip4inter.net/drafts.php > > There are txt and html versions as well as the diff from -01 version. > > The major edition is the removal of the ESP stuff (including rekeying) > from it. There are still some XXXs where text is missing / needs some > attention. Please read and comment (and provide text if you feel so). I have now reviewed about the first third of the new draft in detail, and browsed the rest, at so far it looks pretty good. I've made a few editorial and other changes; the editorial ones I'll send directly to Petri, and the other's I'll try to summarise here later. So far I have came up with two more substantial issues: 1. The order of user data transmission formats. The current idea in the draft (IIRC this this idea was mine, and hence my mistake) is that different user data transmission formats are indicated with distinct HIP parameters. Obviously, ESP_TRANSFORM is the first of these. The idea is also that the formats are placed in the HIP message in the preference order, if there are several. Unfortunately, this does not work, for two reasons: - the hosts may desire to have multiple user data associations at the same time - the preference order and the parameter type order may be different Hence, something more flexible must be invented for this. Maybe a new USER_DATA_FORMAT parameter, which then carries a number of more specific parameters (also in TLV format?)? Opinions? 2. UPDATE packet processing rules. The new base draft contains very little about how to process UPDATEs. I think it should specify, very exactly, how to use SEQ and ACK, how to retransmit outstanding but unacknowledged UPDATEs, etc. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 11 11:20:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05125 for ; Tue, 11 Jan 2005 11:20:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A61D57307; Tue, 11 Jan 2005 11:20:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp.uol.com.br (smtpout3.uol.com.br [200.221.4.194]) by honor.icsalabs.com (Postfix) with ESMTP id 952177305 for ; Tue, 11 Jan 2005 11:19:26 -0500 (EST) Received: from [192.168.1.3] (c906c03c.virtua.com.br [201.6.192.60]) by scorpion3.uol.com.br (Postfix) with ESMTP id 6A3457E77; Tue, 11 Jan 2005 14:19:19 -0200 (BRST) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.6.10]); Tue, 11 Jan 2005 14:19:22 -0200 From: "Marcio Augusto de Lima e Silva" To: Message-ID: X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcT3+U94Gxkw0pAoSDWMyuIvRtPdyw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=======AVGMAIL-41E3FC8A4E74=======" Subject: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 11 Jan 2005 14:19:22 -0200 Date: Tue, 11 Jan 2005 14:19:22 -0200 --=======AVGMAIL-41E3FC8A4E74======= Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C4F7E8.8C2BCA90" ------=_NextPart_000_0001_01C4F7E8.8C2BCA90 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all, I've read some old posts (January 2004) on the above subject and I'm still have some questions. After I bind the HITs to a network interface (on each of the two hosts), and place the HITs in /etc/hosts in the form , how can I associate the IPv4 (or even the IPv6) address to a HIT ? Also, is the mutual copy o the public keys (from /etc/hip) from each peer host required (it seems to be the case for the linux implementation) ? Thanks ! Marcio ------=_NextPart_000_0001_01C4F7E8.8C2BCA90 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I've = read some old=20 posts (January 2004) on the above subject and I'm still have some = questions.=20 After I bind the HITs to a network interface (on each of the two hosts), = and=20 place the HITs in /etc/hosts in the form <HIT> <HOSTNAME>, = how can I=20 associate the IPv4 (or even the IPv6) address to a HIT ? Also, is the = mutual=20 copy o the public keys (from /etc/hip) from each peer host required = (it=20 seems to be the case for the linux implementation) = ? 
 
Thanks = !
 
Marcio
 
 
------=_NextPart_000_0001_01C4F7E8.8C2BCA90-- --=======AVGMAIL-41E3FC8A4E74======= Content-Type: text/plain; x-avg=cert; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Description: "AVG certification" Content-Transfer-Encoding: quoted-printable No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/1/2005 --=======AVGMAIL-41E3FC8A4E74=======-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 11 11:39:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07019 for ; Tue, 11 Jan 2005 11:39:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E50557307; Tue, 11 Jan 2005 11:39:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from web51510.mail.yahoo.com (web51510.mail.yahoo.com [206.190.38.202]) by honor.icsalabs.com (Postfix) with SMTP id E987A72F4 for ; Tue, 11 Jan 2005 11:38:55 -0500 (EST) Received: (qmail 8755 invoked by uid 60001); 11 Jan 2005 16:38:55 -0000 Message-ID: <20050111163855.8753.qmail@web51510.mail.yahoo.com> Received: from [217.9.64.246] by web51510.mail.yahoo.com via HTTP; Tue, 11 Jan 2005 17:38:54 CET From: Salvatore Loreto Reply-To: salvatore.loreto@ieee.org To: hipsec@honor.trusecure.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-204098637-1105461534=:6992" Content-Transfer-Encoding: 8bit Subject: [Hipsec] linux implementation? Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 11 Jan 2005 17:38:54 +0100 (CET) Date: Tue, 11 Jan 2005 17:38:54 +0100 (CET) --0-204098637-1105461534=:6992 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I'd like to know if there is a HIP linux implementation. Thanks in advance Sal --------------------------------- Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-204098637-1105461534=:6992 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi all,
 
I'd like to know if there is a HIP linux implementation.
 
Thanks in advance
Sal

Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! --0-204098637-1105461534=:6992-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 11 12:22:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10363 for ; Tue, 11 Jan 2005 12:22:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5A2A47332; Tue, 11 Jan 2005 12:22:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id E72CE730F for ; Tue, 11 Jan 2005 12:21:49 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA04300; Tue, 11 Jan 2005 09:21:44 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0BHLiP03724; Tue, 11 Jan 2005 09:21:44 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Jan 2005 09:21:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] linux implementation? Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F35@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] linux implementation? Thread-Index: AcT3/vepveWV6dY6TdeJ6BAj5DS4hAAAdYjQ From: "Ahrenholz, Jeffrey M" To: , X-OriginalArrivalTime: 11 Jan 2005 17:21:41.0009 (UTC) FILETIME=[03C52010:01C4F802] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 11 Jan 2005 09:21:40 -0800 Date: Tue, 11 Jan 2005 09:21:40 -0800 Content-Transfer-Encoding: quoted-printable Sal, There are two publicly-available Linux implementations: - HIPL - HIP for Linux ,=20 a kernel-based implementation that is a project of=20 researchers at the Helsinki Institute for Information Technology - Boeing's Linux HIP implementation = , which resides mostly in a user-space daemon, with a small kernel patch Additionally, in November 2003, Andrew McGregor released a Python = version which runs on Linux, = , which is entirely a = user-space program. -Jeff -----Original Message----- From: Salvatore Loreto [mailto:loretosal@yahoo.it]=20 Sent: Tuesday, January 11, 2005 8:39 AM To: hipsec@honor.trusecure.com Subject: [Hipsec] linux implementation? Hi all, I'd like to know if there is a HIP linux implementation. Thanks in advance Sal Nuovo Yahoo! Messenger E' molto pi=F9 divertente: Audibles, Avatar, = Webcam, Giochi, Rubrica... Scaricalo ora!=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 11 15:35:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24342 for ; Tue, 11 Jan 2005 15:35:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C468B7308; Tue, 11 Jan 2005 15:35:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id B6D8B72F3 for ; Tue, 11 Jan 2005 15:34:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24255; Tue, 11 Jan 2005 15:34:34 -0500 (EST) Message-Id: <200501112034.PAA24255@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-arch-02.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 11 Jan 2005 15:34:34 -0500 Date: Tue, 11 Jan 2005 15:34:34 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Architecture Author(s) : R. Moskowitz, P. Nikander Filename : draft-ietf-hip-arch-02.txt Pages : 24 Date : 2005-1-11 This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-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-arch-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-arch-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: <2005-1-11160517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-11160517.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jan 12 03:42:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22826 for ; Wed, 12 Jan 2005 03:42:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 400BA7309; Wed, 12 Jan 2005 03:42:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 346617307 for ; Wed, 12 Jan 2005 03:41:46 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 62098212CF0 for ; Wed, 12 Jan 2005 10:41:42 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@honor.trusecure.com From: Pekka Nikander X-Mailer: Apple Mail (2.619) Subject: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 12 Jan 2005 10:41:55 +0200 Date: Wed, 12 Jan 2005 10:41:55 +0200 Content-Transfer-Encoding: 7bit Folks, While updating our HIP implementation to the newest base draft, where HITs are 128 bits long and there is no longer any HIT prefix, we've encountered implementation level problems. More specifically, with the current IPv6 implementation in FreeBSD 5, it becomes quite hard to use ESP, with BEET patches, to support HIP. That is, if a HIT happens to conflict with an existing IPv6 address, there will be conflicts at the level of IPsec policies. To resolve this problem, I suggest that we temporarily restrict the allowed HIT values into the unused IPv6 address space. That is, when generating a new HI, the generator MUST check that the resulting HIT has the two topmost bits as 01 or 10. If the top most bits are 00 or 11, then the host must generate another HI. The idea is that this restriction is meant to be temporary (a few years) and to be eventually lifted, as the stacks evolve. Of course, we do not need to be this restrictive if we don't want to. We can just rule out the used part of the IPv6 address space, namely 001 and 1111 111. See http://www.iana.org/assignments/ipv6-address-space Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Jan 12 04:08:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24399 for ; Wed, 12 Jan 2005 04:08:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 12EB77307; Wed, 12 Jan 2005 04:08:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 62E4F72E0 for ; Wed, 12 Jan 2005 04:07:30 -0500 (EST) Received: from n51.nomadiclab.com (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 2ED49212CF0; Wed, 12 Jan 2005 11:07:33 +0200 (EET) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1 User-Agent: KMail/1.6.2 Cc: "Marcio Augusto de Lima e Silva" References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200501121107.32734.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 12 Jan 2005 11:07:22 +0200 Date: Wed, 12 Jan 2005 11:07:22 +0200 Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marcio On Tuesday 11 January 2005 18:19, Marcio Augusto de Lima e Silva wrote: > Hi all, > > I've read some old posts (January 2004) on the above subject and I'm still > have some questions. After I bind the HITs to a network interface (on each > of the two hosts), and place the HITs in /etc/hosts in the form > , how can I associate the IPv4 (or even the IPv6) address to a > HIT ?=20 Your /etc/hosts should look like this: This way when the hostname is resolved the resolver gets the appropriate HI= T=20 and IP addresses. > Also, is the mutual copy o the public keys (from /etc/hip) from each=20 > peer host required (it seems to be the case for the linux implementation)= ? Mutual copies of public keys are NOT required. Regards, Jan =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB5OjPp4iklvjQtTgRAqzdAJ9avXn4ZeiArEQ58I8fTA+INLKQ0gCgod9U hhODXtQzeq81+3qzW2UYRqg=3D =3DPeiN =2D----END PGP SIGNATURE----- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 00:57:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29936 for ; Fri, 14 Jan 2005 00:57:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 68F5C730D; Fri, 14 Jan 2005 00:57:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 68422730A for ; Fri, 14 Jan 2005 00:56:13 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA20088; Thu, 13 Jan 2005 21:55:56 -0800 (PST) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0E5txP29499; Thu, 13 Jan 2005 21:56:00 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Jan 2005 21:55:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040609CC@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Thread-Index: AcT4gqPWoAaSaVMFSy+X75zFxlOX3gBeds6g From: "Henderson, Thomas R" To: "Pekka Nikander" , X-OriginalArrivalTime: 14 Jan 2005 05:55:42.0815 (UTC) FILETIME=[AED05EF0:01C4F9FD] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 13 Jan 2005 21:55:42 -0800 Date: Thu, 13 Jan 2005 21:55:42 -0800 Content-Transfer-Encoding: quoted-printable >=20 > To resolve this problem, I suggest that we temporarily restrict the=20 > allowed HIT values into the unused IPv6 address space. That is, when=20 > generating a new HI, the generator MUST check that the resulting HIT=20 > has the two topmost bits as 01 or 10. =20 >=20 > Opinions? >=20 When this restriction is lifted, what becomes of the legacy = implementations that are enforcing it? Will this practically cause such = 01/10 HITs to be forever avoided? Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 01:02:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00462 for ; Fri, 14 Jan 2005 01:02:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3F765731A; Fri, 14 Jan 2005 01:02:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from enso.acheron.indranet.co.nz (unknown [203.167.203.10]) by honor.icsalabs.com (Postfix) with ESMTP id E78E7730A for ; Fri, 14 Jan 2005 01:01:59 -0500 (EST) Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id TAA12617; Fri, 14 Jan 2005 19:01:55 +1300 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040609CC@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040609CC@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , "Pekka Nikander" From: Andrew McGregor Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 19:01:25 +1300 Date: Fri, 14 Jan 2005 19:01:25 +1300 Content-Transfer-Encoding: 7bit How about checking for that condition or an IANA assigned address, for which implementations MUST be configurable for after the fact? Andrew On 14/01/2005, at 6:55 PM, Henderson, Thomas R wrote: > >> >> To resolve this problem, I suggest that we temporarily restrict the >> allowed HIT values into the unused IPv6 address space. That is, when >> generating a new HI, the generator MUST check that the resulting HIT >> has the two topmost bits as 01 or 10. >> >> Opinions? >> > > When this restriction is lifted, what becomes of the legacy > implementations that are enforcing it? Will this practically cause > such 01/10 HITs to be forever avoided? > > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 04:32:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28132 for ; Fri, 14 Jan 2005 04:32:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id CE09D730A; Fri, 14 Jan 2005 04:32:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id C865072EA for ; Fri, 14 Jan 2005 04:31:01 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9BD00212CF0; Fri, 14 Jan 2005 11:30:51 +0200 (EET) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C040609CC@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <027BB5E5-660F-11D9-85ED-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "" From: Pekka Nikander Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: Andrew McGregor , Thomas R Henderson X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 11:31:03 +0200 Date: Fri, 14 Jan 2005 11:31:03 +0200 Content-Transfer-Encoding: 7bit >>> To resolve this problem, I suggest that we temporarily restrict the >>> allowed HIT values into the unused IPv6 address space. That is, when >>> generating a new HI, the generator MUST check that the resulting HIT >>> has the two topmost bits as 01 or 10. >> >> When this restriction is lifted, what becomes of the legacy >> implementations that are enforcing it? Will this practically cause >> such 01/10 HITs to be forever avoided? (I assume that you mean that 00/11 HITs to be forever avoided.) > How about checking for that condition or an IANA assigned address, for > which implementations MUST be configurable for after the fact? Firstly, if we do adopt any scheme like this, I think that we must follow the usual "be strict in what you generate and liberal in what you accept" rule. That is, even if we decided that current hosts MUST generate only 01/10 HITs, they also SHOULD accept any HITs. In practise I think, this would result most HITs being usable, as real collisions are likely to be quite rare. That is, the only real reason that I can see for not accepting an 00/11 HIT is that it happens to collide with an IP address of some real host. (How does the host know that is another issue. It might be easier just to ignore HITs starting with 001 or 111110.) Secondly, I agree with Andrew that this MUST be configurable. Hence, even if we adopted this restriction, we can say that there MUST be a set of configuration options that - allow the host to generate any HIT instead of just 01/10 HITs - accept the host any HITs instead of 01/10 HITs - others? What comes to the "accept any HIT rule", there won't be any problems if the host uses always HIP. In other words, I'm afraid that we would end up living with this rule until most of the world is converted to HIP, if ever. But let's also consider the alternatives: - Go back to HIT the prefixes. Possible, but IMHO not the right architectural choice. - Do not adopt this restriction. Possible, but results at least in our case in much uglier implementation, and large rewriting of the code if we want to be able to accept all HITs, i.e., also such HITs that collide with some IP address. - Do adopt this restriction, but with a fixed date when it will be lifted. For example, let's decide that the restriction will be lifted by January 31st, 2007. That would mean that all implementations MUST be upgraded to support all HITs by that day. I would suggest that we would go with this restriction, with the above principles and configuration rules, and possibly with a fixed date for lifting the restriction. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 07:15:03 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02999 for ; Fri, 14 Jan 2005 07:15:03 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 97FB27377; Fri, 14 Jan 2005 07:14:03 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id E72827338 for ; Fri, 14 Jan 2005 07:13:00 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1CpQJv-00017u-00; Fri, 14 Jan 2005 07:12:51 -0500 From: Tim Shepard To: Pekka Nikander Cc: Andrew McGregor , Thomas R Henderson , "" Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? In-reply-to: Your message of Fri, 14 Jan 2005 11:31:03 +0200. <027BB5E5-660F-11D9-85ED-000D9331AFB0@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 07:12:51 -0500 Date: Fri, 14 Jan 2005 07:12:51 -0500 I guess I missed why this restriction is needed. IIRC, there are no 128-bit hash functions left standing, so don't we need to be thinking of 192-bit (or longer, in case confidence in the security of SHA1 is lost) HITs? We can still pass 128-bit LSIs across the IPv6 APIs, using a (say) 120-bit suffix of the HIT with an 8-bit prefix as a handle (an LSI) that can be passed across legacy APIs to refer to the HIT. I don't see what problem is solved by restricting the top two bits of the HIT itself. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 09:15:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16237 for ; Fri, 14 Jan 2005 09:15:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 483F47317; Fri, 14 Jan 2005 09:15:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 3BB98730D for ; Fri, 14 Jan 2005 09:14:30 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 72AEF212CF0; Fri, 14 Jan 2005 16:14:26 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew McGregor , Thomas R Henderson , "" From: Pekka Nikander Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: Tim Shepard X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 16:14:39 +0200 Date: Fri, 14 Jan 2005 16:14:39 +0200 Content-Transfer-Encoding: 7bit > I guess I missed why this restriction is needed. > > IIRC, there are no 128-bit hash functions left standing, so don't we > need to be thinking of 192-bit (or longer, in case confidence in the > security of SHA1 is lost) HITs? We can still pass 128-bit LSIs > across the IPv6 APIs, using a (say) 120-bit suffix of the HIT with an > 8-bit prefix as a handle (an LSI) that can be passed across legacy > APIs to refer to the HIT. > > I don't see what problem is solved by restricting the top two bits of > the HIT itself. There problems are implementation level. One side of the problem is related to checksums, the other to IPsec policies. The specification says (wisely IMHO) that the TCP or UDP checksum is computed with using the IPv6 pseudo header and HITs in the place of IP addresses. Consequently, the stack must have access to HITs when computing the checksum. Now, there are basically two possibilities for implementing this. One is to use HITs in the place of IP addresses everywhere in the stack; i.e., the LSIs are converted to HITs just below the API, and from there down to IPsec the stack uses HITs. That's the way we have done our implementation. The other possibility is to use LSIs in the stack, and rewrite the checksum computation and verification code the replace the LSIs with HITs during the checksum computation. The second problem is in IPsec policies. In order to allow ESP to be used both for HIP and other protocols, we currently have generic IPsec policies that rely on HIT prefixes. That made it very easy to direct all HIP traffic to ESP and to make sure that all incoming HIP traffic uses ESP properly. Now, if we used LSIs in the stack this problem goes away, as the LSIs have prefixes. But then we have to modify the checksum code. Alternatively, if we use HITs in the stack then we have to modify the policy code and accept the fact that there may be policies that conflict with real IP addresses. Maybe it would be best for us to bite the bullet now, use LSIs in the stack, and just patch the TCP/UDP checksum code instead of introducing my proposed restriction. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 09:29:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16804 for ; Fri, 14 Jan 2005 09:29:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EC1697317; Fri, 14 Jan 2005 09:29:03 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 9D1B6730D for ; Fri, 14 Jan 2005 09:28:57 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0EESuVu020917 for ; Fri, 14 Jan 2005 07:28:56 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAB00H0K9K7ZU@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 14 Jan 2005 07:28:56 -0700 (MST) Received: from [10.0.0.68] ([83.145.97.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAB005MW9JZUK@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 14 Jan 2005 07:28:55 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? In-reply-to: To: hipsec@honor.trusecure.com Cc: Pekka Nikander , Tim Shepard , Andrew McGregor , Thomas R Henderson Message-id: <200501141531.04657.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 15:31:04 +0100 Date: Fri, 14 Jan 2005 15:31:04 +0100 Content-Transfer-Encoding: 7BIT Hi Pekka, I just got an idea (inlined below), which is probably stupid, but anyway... On Friday 14 January 2005 15:14, Pekka Nikander wrote: > > I guess I missed why this restriction is needed. > > > > IIRC, there are no 128-bit hash functions left standing, so don't > > we need to be thinking of 192-bit (or longer, in case confidence > > in the security of SHA1 is lost) HITs? We can still pass 128-bit > > LSIs across the IPv6 APIs, using a (say) 120-bit suffix of the > > HIT with an 8-bit prefix as a handle (an LSI) that can be passed > > across legacy APIs to refer to the HIT. > > > > I don't see what problem is solved by restricting the top two > > bits of the HIT itself. > > There problems are implementation level. One side of the problem > is related to checksums, the other to IPsec policies. > > The specification says (wisely IMHO) that the TCP or UDP checksum > is computed with using the IPv6 pseudo header and HITs in the place > of IP addresses. (...) > The second problem is in IPsec policies. In order to allow ESP to > be used both for HIP and other protocols, we currently have generic > IPsec policies that rely on HIT prefixes. (..) > Maybe it would be best for us to bite the bullet now, use LSIs in > the stack, and just patch the TCP/UDP checksum code instead of > introducing my proposed restriction. And what if the spec says that TCP/UDP checksum are ignored on the receiver side? After all if we have ESP encapsulating TCP/UDP payloads, we don't need to check for the packet integrity, and you might be able to compute the checksum with LSIs or HITs; who cares... AFAICS the only problemis that we're in the process of removing ESP from the base spec, so we might run into problems if we use another protocol to carry the user data and that protocol happens to not implement an integrity check (like ESP does). In that case we might say: "If the protocol carrying user data implements an integrity check, the TCP/UDP checksum SHOULD be ignored on the receiver side". But perhaps this is completely silly... Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Jan 14 13:56:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04594 for ; Fri, 14 Jan 2005 13:56:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 28215731C; Fri, 14 Jan 2005 13:56:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 6E21A7317 for ; Fri, 14 Jan 2005 13:55:36 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAB07513; Fri, 14 Jan 2005 10:55:30 -0800 (PST) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0EItTP27276; Fri, 14 Jan 2005 10:55:29 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Jan 2005 10:55:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040609CE@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Thread-Index: AcT6G7+202B2BsawRESNGQMI1//TtwAS+tPg From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 14 Jan 2005 18:55:25.0695 (UTC) FILETIME=[9B9558F0:01C4FA6A] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 14 Jan 2005 10:55:24 -0800 Date: Fri, 14 Jan 2005 10:55:24 -0800 Content-Transfer-Encoding: quoted-printable >=20 > Firstly, if we do adopt any scheme like this, I think that we must=20 > follow the usual "be strict in what you generate and liberal in what=20 > you accept" rule. That is, even if we decided that current=20 > hosts MUST=20 > generate only 01/10 HITs, they also SHOULD accept any HITs. =20 I am OK with the proposed restriction, in the interest of facilitating experimentation. I would suggest making it SHOULD generate/SHOULD=20 accept, and explain the rationale for this, and that it probably will be lifted in the future. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jan 17 00:09:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17351 for ; Mon, 17 Jan 2005 00:09:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5ED2E7310; Mon, 17 Jan 2005 00:09:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 834257305 for ; Mon, 17 Jan 2005 00:08:16 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA18591; Sun, 16 Jan 2005 21:08:01 -0800 (PST) Received: from xch-sebh-02.se.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0H584s18194; Sun, 16 Jan 2005 23:08:05 -0600 (CST) Received: from xch-nwbh-01.nw.nos.boeing.com ([192.33.62.231]) by xch-sebh-02.se.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Jan 2005 23:07:38 -0600 Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 16 Jan 2005 21:07:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040609D8@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 PRE1 Thread-Index: AcT31YZpiWADz2HMRk2qzYER8R4eZQEcDXSg From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 17 Jan 2005 05:07:07.0157 (UTC) FILETIME=[642F8450:01C4FC52] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 16 Jan 2005 21:07:06 -0800 Date: Sun, 16 Jan 2005 21:07:06 -0800 Content-Transfer-Encoding: quoted-printable >=20 > So far I have came up with two more substantial issues: >=20 > 1. The order of user data transmission formats. >=20 > The current idea in the draft (IIRC this this idea > was mine, and hence my mistake) is that different > user data transmission formats are indicated with > distinct HIP parameters. Obviously, ESP_TRANSFORM > is the first of these. The idea is also that the > formats are placed in the HIP message in the > preference order, if there are several. Unfortunately, > this does not work, for two reasons: >=20 > - the hosts may desire to have multiple user data=20 > associations at=20 > the same time >=20 > - the preference order and the parameter type order may be=20 > different >=20 > Hence, something more flexible must be invented for this. > Maybe a new USER_DATA_FORMAT parameter, which then carries > a number of more specific parameters (also in TLV format?)? >=20 > Opinions? I agree that this is a problem for multiple user data associations. I didn't think that it was mandatory to include them in parameter type order. Regarding multiple associations and USER_DATA_FORMAT, does this start to take us down the path of replicating IKE? >=20 > 2. UPDATE packet processing rules. >=20 > The new base draft contains very little about how to process=20 > UPDATEs. > I think it should specify, very exactly, how to use SEQ=20 > and ACK,=20 > how > to retransmit outstanding but unacknowledged UPDATEs, etc. >=20 Agreed. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jan 17 00:27:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18247 for ; Mon, 17 Jan 2005 00:27:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 160C97315; Mon, 17 Jan 2005 00:27:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id ACF9A7305 for ; Mon, 17 Jan 2005 00:26:04 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA11740; Sun, 16 Jan 2005 21:26:02 -0800 (PST) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0H5Q1P21258; Sun, 16 Jan 2005 21:26:01 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 16 Jan 2005 21:25:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040609D9@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 PRE1 Thread-Index: AcT0vQQmCPissoWARniyjNbRxUNGHAHlWwxw From: "Henderson, Thomas R" To: "Petri Jokela" , X-OriginalArrivalTime: 17 Jan 2005 05:25:51.0382 (UTC) FILETIME=[0246A360:01C4FC55] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 16 Jan 2005 21:25:50 -0800 Date: Sun, 16 Jan 2005 21:25:50 -0800 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, January 07, 2005 5:29 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Base HIP: 02 PRE1 >=20 >=20 > Folks, >=20 > You can find the current pre-version, draft-ietf-hip-base-02-pre1, of=20 > the base draft in: >=20 > http://hip4inter.net/drafts.php >=20 Here are a few more comments on this draft: Section 3: > (SPI) can be used for this purpose. In many cases, this makes it > possible to use HIP without an additional explicit protocol header. Do we know this is true for "many" cases? Or is it just ESP? Section 3.2: > 3.2 Local Scope Identifier (LSI) I am curious-- does anyone else think it might be more appropriate to move LSIs out of this draft and into an informative draft or an appendix? If I decided to make my implementation use LSIs that do not conform to the specified subnet, would anyone be able to tell the difference? Section 4: > All HIP implementations MUST implement, at minimum, the ESP > transport format for HIP [23]. Should this be a MUST? Maybe strike this sentence (also in 4.7). Section 4.7: > When new transport formats are defined, they MUST have smaller type > value than the ESP transport format. The order in which the > transport formats are presented in the R1 packet, is the preferred > order. The last of the transport formats MUST be ESP transport > format. Could you please remind me why ESP must be last? Section 8.2: > 3. The IP addresses in the datagram are replaced with the HITs > associated with the ESP SA. HIP association. Note that this > IP-address-to-HIT conversion step MAY also be performed at some > other point in the > stack, e.g., before ESP processing. stack. =20 Probably more needs to be said here regarding what to do when it is IPv4 (i.e., convert to an IPv6 header then replace addresses with HITs). > Appendix A. API issues This should probably be removed to a separate draft now that other = aspects of the data transfer are moved out of this draft. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 18 00:04:43 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28080 for ; Tue, 18 Jan 2005 00:04:42 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E2FA572F3; Tue, 18 Jan 2005 00:04:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp.uol.com.br (smtpout2.uol.com.br [200.221.4.193]) by honor.icsalabs.com (Postfix) with ESMTP id A9D6272E6 for ; Tue, 18 Jan 2005 00:03:30 -0500 (EST) Received: from [192.168.1.3] (c906c03c.virtua.com.br [201.6.192.60]) by scorpion2.uol.com.br (Postfix) with ESMTP id 68B558E38; Tue, 18 Jan 2005 03:03:30 -0200 (BRST) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.6.13]); Tue, 18 Jan 2005 03:03:32 -0200 From: "Marcio Augusto de Lima e Silva" To: Cc: "'Jan Mikael Melen'" Subject: RES: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1 Message-ID: X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcT4hj8HsW/CrbALRqKhwZKo3VaOmQEjAfKg In-Reply-To: <200501121107.32734.Jan.Melen@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 18 Jan 2005 03:03:32 -0200 Date: Tue, 18 Jan 2005 03:03:32 -0200 Content-Transfer-Encoding: 7bit Thanks for the previous answer Since I'm still facing a problem during the test, I would like to ask for further explanation of the configuration. Is a IPSEC Policy like "spdadd any -P out ipsec esp/hip//require;" on each host enough to trigger the HIP negotiation ? It seems so, but I would like to double check (the IPSEC SA's will be handled by the HIP right ?). Is the editing of the hipconf.xml required ? The hipconf.xml on each host has the HIT 69dc:c983:bc39:c7eb:a25d:4b38:220e:23cd (which comes from the kernel patch file hip.patch) and does not change with the generation of the new HI (by removing /etc/hip entries) The (reproducible) behavior that I'm seeing (in a HIP patched ethereal 0.10.7) is: - one or two I1 HIP - one or two R1 HIP - one or two I2 HIP - one or two R2 HIP - approx 8 seconds delay - unencrypted regular TCP/IP connection (with ssh or ftp), no ESP ipsec traffic. Running hipd -n -d4 shows some errors in the source side: Errno : No such file or directory Errno : Unknown error: 0 Errno : No such file or directory Errno : Unknown error: 0 N Trace: [hipd_pfhip_write]: hipd_pfhip.c(194): ENTER Hex: [hipd_pfhip_write]: HIP packet outgoing Hex: 03000000 5865ef5f 18d87f17 01000000 00000000 00000000 00000000 00000000 Error: [hipd_io_write]: [FAIL] Write to fd8, errno 2 Error: [hipd_pfhip_write]: Write to PFHIP failed Running hipd -n -t10 shows only warnings like: Warning: [hipd_states_default_handle_r1]: Received an unexpected R1 in state=I2 sent!!! (which should be caused by the double I1,I2,R1,R2 packets) Well.....that's all......any clarifications or even a example config would be greatly appreciated. Thanks again, Marcio -----Mensagem original----- De: hipsec-admin@honor.trusecure.com [mailto:hipsec-admin@honor.trusecure.com] Em nome de Jan Mikael Melen Enviada em: quarta-feira, 12 de janeiro de 2005 07:07 Para: hipsec@honor.trusecure.com Cc: Marcio Augusto de Lima e Silva Assunto: Re: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marcio On Tuesday 11 January 2005 18:19, Marcio Augusto de Lima e Silva wrote: > Hi all, > > I've read some old posts (January 2004) on the above subject and I'm > still have some questions. After I bind the HITs to a network > interface (on each of the two hosts), and place the HITs in /etc/hosts > in the form , how can I associate the IPv4 (or even > the IPv6) address to a HIT ? Your /etc/hosts should look like this: This way when the hostname is resolved the resolver gets the appropriate HIT and IP addresses. > Also, is the mutual copy o the public keys (from /etc/hip) from each > peer host required (it seems to be the case for the linux implementation) ? Mutual copies of public keys are NOT required. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB5OjPp4iklvjQtTgRAqzdAJ9avXn4ZeiArEQ58I8fTA+INLKQ0gCgod9U hhODXtQzeq81+3qzW2UYRqg= =PeiN -----END PGP SIGNATURE----- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/1/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/1/2005 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 18 07:56:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19025 for ; Tue, 18 Jan 2005 07:56:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2A06A7312; Tue, 18 Jan 2005 07:56:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 9EA417312 for ; Tue, 18 Jan 2005 07:55:54 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 17D3A212CF0; Tue, 18 Jan 2005 14:55:54 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040609D8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040609D8@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <531ED5F4-6950-11D9-B86C-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] Base HIP: 02 PRE1 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 18 Jan 2005 14:56:09 +0200 Date: Tue, 18 Jan 2005 14:56:09 +0200 Content-Transfer-Encoding: 7bit >> 1. The order of user data transmission formats. >> >> The current idea in the draft (IIRC this this idea >> was mine, and hence my mistake) is that different >> user data transmission formats are indicated with >> distinct HIP parameters. Obviously, ESP_TRANSFORM >> is the first of these. The idea is also that the >> formats are placed in the HIP message in the >> preference order, if there are several. Unfortunately, >> this does not work, for two reasons: >> >> - the hosts may desire to have multiple user data >> associations at the same time >> >> - the preference order and the parameter type order may be >> different >> >> Hence, something more flexible must be invented for this. >> Maybe a new USER_DATA_FORMAT parameter, which then carries >> a number of more specific parameters (also in TLV format?)? >> >> Opinions? > > I agree that this is a problem for multiple user data associations. > I didn't think that it was mandatory to include them in parameter > type order. Regarding multiple associations and USER_DATA_FORMAT, > does this start to take us down the path of replicating IKE? I don't think we *need* to solve this within the base specification. On the other hand, we probably *could* solve this, e.g., by relaxing the current parameter ordering rules. For example, we could define that a certain range of parameter types may appear in any order. What comes to IKE, I would consider that a completely separate question, and belonging to the RG side. FWIW, I still would like to see a concrete proposal for supporting HIP-like identities on the top of IKEv2. (I think there was a draft on something like that some time ago, but IIRC I found it quite lacking.) --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Jan 23 04:11:41 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00184 for ; Sun, 23 Jan 2005 04:11:41 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 889CC7327; Sun, 23 Jan 2005 04:11:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 404987303 for ; Sun, 23 Jan 2005 04:10:53 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5ADF9212CF0; Sun, 23 Jan 2005 11:10:49 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040609D9@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040609D9@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Petri Jokela From: Pekka Nikander Subject: Re: [Hipsec] Base HIP: 02 PRE1 To: Thomas R Henderson , " " X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 23 Jan 2005 11:11:07 +0200 Date: Sun, 23 Jan 2005 11:11:07 +0200 Content-Transfer-Encoding: 7bit Tom and others, >> You can find the current pre-version, draft-ietf-hip-base-02-pre1, of >> the base draft in: >> >> http://hip4inter.net/drafts.php > > Here are a few more comments on this draft: > > Section 3: >> (SPI) can be used for this purpose. In many cases, this makes it >> possible to use HIP without an additional explicit protocol header. > > Do we know this is true for "many" cases? Or is it just ESP? I think it may be more appropriate to state "In some cases,". On the other hand, basically in any case where unambiguously demultiplex packets based on the information in the existing headers and state created with the help of the HIP protocol, in theory on can send packets without extra overhead. For example, one could imagine a HIP extension that "signals" TCP or UDP port numbers, and then uses plain TCP or UDP to send the traffic. Of course, that would require that the kernels in the participating machines do not assign those port numbers for non-HIP traffic, but that should be doable. > Section 3.2: >> 3.2 Local Scope Identifier (LSI) > > I am curious-- does anyone else think it might be more appropriate > to move LSIs out of this draft and into an informative draft or an > appendix? If I decided to make my implementation use LSIs that do > not conform to the specified subnet, would anyone be able to tell > the difference? As I have stated in more length at the RG side in the discussion related to ULIDs, I think that LSIs and LSI formats are important from the applications interoperability point of view. That is, while LSIs don't necessarily matter at the HIP protocol level, they are important for legacy applications that use the LSIs at the current IPv4 and IPv6 APIs. While I think that we are doing good progress with LSIs currently at the RG discussion, it might still be a good option to move LSIs into a separate draft. Such a document could discuss LSIs, how they are used at the APIs and by applications, and _also_ define a HIP protocol extension for informing about used/assigned LSIs. Opinions? > Section 4: >> All HIP implementations MUST implement, at minimum, the ESP >> transport format for HIP [23]. > > Should this be a MUST? Maybe strike this sentence (also in 4.7). Well, IMHO, it is important to provide some level of user plane interoperability. Right now ESP is the lowest common denominator. Hence, in order to make all HIP hosts to be able to talk to each other, I think it makes sense to make this requirement. > Section 4.7: >> When new transport formats are defined, they MUST have smaller type >> value than the ESP transport format. The order in which the >> transport formats are presented in the R1 packet, is the preferred >> order. The last of the transport formats MUST be ESP transport >> format. > > Could you please remind me why ESP must be last? The idea was that you have the common denominator as the last one. In that way, if none of the earlier ones match, you know that the ESP will match. Maybe we should add some text to clarify this? > Section 8.2: >> 3. The IP addresses in the datagram are replaced with the HITs >> associated with the ESP SA. HIP association. Note that this >> IP-address-to-HIT conversion step MAY also be performed at some >> other point in the >> stack, e.g., before ESP processing. stack. > > Probably more needs to be said here regarding what to do when it is > IPv4 > (i.e., convert to an IPv6 header then replace addresses with HITs). Or should we loosen this and say "... replaced with the HITs (or LSIs) associated with the HIP association"? >> Appendix A. API issues > > This should probably be removed to a separate draft now that other > aspects > of the data transfer are moved out of this draft. Yes, I agree. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jan 24 11:24:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27132 for ; Mon, 24 Jan 2005 11:24:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8734C7316; Mon, 24 Jan 2005 11:24:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 4396E7314 for ; Mon, 24 Jan 2005 11:23:18 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA23370; Mon, 24 Jan 2005 10:23:09 -0600 (CST) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0OGN6s06085; Mon, 24 Jan 2005 10:23:06 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jan 2005 08:23:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040609F7@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 PRE1 Thread-Index: AcUBK3FT6CIhhwI/RN2SMLhbhOaKIQBAlMBw From: "Henderson, Thomas R" To: "Pekka Nikander" , Cc: "Petri Jokela" X-OriginalArrivalTime: 24 Jan 2005 16:23:05.0762 (UTC) FILETIME=[FBE3C020:01C50230] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 24 Jan 2005 08:23:05 -0800 Date: Mon, 24 Jan 2005 08:23:05 -0800 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, January 23, 2005 1:11 AM > To: Henderson, Thomas R; =20 > > Cc: Petri Jokela > Subject: Re: [Hipsec] Base HIP: 02 PRE1 >=20 >=20 > Tom and others, >=20 > >> You can find the current pre-version,=20 > draft-ietf-hip-base-02-pre1, of > >> the base draft in: > >> > >> http://hip4inter.net/drafts.php > > > > Here are a few more comments on this draft: > > > > Section 3: > >> (SPI) can be used for this purpose. In many cases,=20 > this makes it > >> possible to use HIP without an additional explicit=20 > protocol header. > > > > Do we know this is true for "many" cases? Or is it just ESP? >=20 > I think it may be more appropriate to state "In some cases,". >=20 Agreed. > > Section 3.2: > >> 3.2 Local Scope Identifier (LSI) > > >=20 > While I think that we are doing good progress with LSIs currently > at the RG discussion, it might still be a good option to move LSIs > into a separate draft. Such a document could discuss LSIs, how > they are used at the APIs and by applications, and _also_ define > a HIP protocol extension for informing about used/assigned LSIs. > Opinions? I would favor such a document, scoped as "Using HIP with legacy APIs" and it could contain more discussion about the LSIs and incorporate the material in current Appendix A. I'd be willing to take a first cut at it. >=20 > > Section 4: > >> All HIP implementations MUST implement, at minimum, the ESP > >> transport format for HIP [23]. > > > > Should this be a MUST? Maybe strike this sentence (also in 4.7). >=20 > Well, IMHO, it is important to provide some level of user plane > interoperability. Right now ESP is the lowest common denominator. > Hence, in order to make all HIP hosts to be able to talk to each > other, I think it makes sense to make this requirement. My concern is that if someone adapts HIP for some non-ESP use (e.g. a device that is SIP specific) then "MUST" forces that=20 implementor to code also the ESP portions. I am not so concerned about user plane interoperability because the market can decide these things, and the early implementations will all support ESP anyway. >=20 > > Section 4.7: > >> When new transport formats are defined, they MUST have=20 > smaller type > >> value than the ESP transport format. The order in which the > >> transport formats are presented in the R1 packet, is the=20 > preferred > >> order. The last of the transport formats MUST be ESP transport > >> format. > > > > Could you please remind me why ESP must be last? >=20 > The idea was that you have the common denominator as the last one. > In that way, if none of the earlier ones match, you know that the > ESP will match. >=20 > Maybe we should add some text to clarify this? I guess this is tied to the above ESP discussion. >=20 > > Section 8.2: > >> 3. The IP addresses in the datagram are replaced with the HITs > >> associated with the ESP SA. HIP association. Note that this > >> IP-address-to-HIT conversion step MAY also be=20 > performed at some > >> other point in the > >> stack, e.g., before ESP processing. stack. > > > > Probably more needs to be said here regarding what to do when it is=20 > > IPv4 > > (i.e., convert to an IPv6 header then replace addresses with HITs). >=20 > Or should we loosen this and say "... replaced with the HITs (or LSIs) > associated with the HIP association"? Perhaps we need a term here-- to borrow a multi6 terminology, we may need to distinguish between LSI and "Upper Layer Identifier (ULID)" that is used in the transport checksum. We need to discuss in this section the ULID, not the LSI (the two may be different). In the absence of such definitions, I might suggest something like: "The IP addresses in the datagram are replaced by constructing the correct pseudo-header representation for the packet using HITs-- see section 4.2" or similar.=20 Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 25 07:52:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00346 for ; Tue, 25 Jan 2005 07:52:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 382A77318; Tue, 25 Jan 2005 07:52:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 1A1697313 for ; Tue, 25 Jan 2005 07:51:52 -0500 (EST) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id DCCA6212CF0 for ; Tue, 25 Jan 2005 14:51:44 +0200 (EET) Message-ID: <41F640E0.9050809@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base HIP: 02 pre2 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 25 Jan 2005 14:51:44 +0200 Date: Tue, 25 Jan 2005 14:51:44 +0200 Content-Transfer-Encoding: 7bit Folks, I uploaded the base draft's current snapshot to http://www.hip4inter.net/drafts.php (txt, html and diffs as usual) I have made some changes that I have received since pre-1 version. The biggest change is the UPDATE packet handling. ESP is still defined as a MUST implementation so that we have something common between two implementations. There are some questions that have come up (now or earlier): In 6.2.7 HIP_TRANSFORM XXX: Deprecate MD5 in the light of recent development? Shall we deprecate? In 6.3. ICMP messages Any need to say more about rate limitations? In 8.9 Sending UPDATE packets, at bullet 4. Pekka N: "Do we need exponential back off? If not, why not? Usually dropped packets are taken as an indication of congestion, and therefore TCP backs off exponentially." I haven't yet edited this one into the text, but it sounds reasonable. Any objections? ISSUES in the tracker: #49 IANA considerations section Requires something more. #52 Restricting HIT values I haven't yet edited changes into the draft. I will most likely follow the discussion that was on the mailing list. #53 Move LSIs to a separate draft LSIs are still in the current draft version but can be removed as there has not been any objections on the mailing list. #54 Move Appendix A. API issues to a separate draft Same comments as in #53. #55 User data transport format negotiation The current draft version contains a "negotiation". o TLV type values between 2048-4095 are reserved for new transport formats. o These values do NOT describe the TLV order in the HIP packet (as is the case with other TLV type values) o The transport format TLVs are inserted in the packet in the order of preference. The text in the draft related to this issue is still quite bad and must be edited. Related to this, Pekka put in one mail a quick proposal about introducing new TLV type areas, something like: 0- 1023: Fundamental functionality, WG action - move echo_RESPONSE to 1020 1024- 2047: Reserved 2048- 4095: Transform parameters 4096-32768: Reserved 32768-48XXX: Vendor 48XXX-65365: Fundamental functionality, WG action Any comments on this? /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Jan 25 21:06:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08397 for ; Tue, 25 Jan 2005 21:06:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EA9B37324; Tue, 25 Jan 2005 21:06:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 92DA3731D for ; Tue, 25 Jan 2005 21:05:39 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA15016; Tue, 25 Jan 2005 20:05:29 -0600 (CST) Received: from xch-nwbh-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j0Q25SU24771; Tue, 25 Jan 2005 18:05:28 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Jan 2005 18:04:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Base HIP: 02 pre2 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F41@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 pre2 Thread-Index: AcUC3LBOgqDaufymQXiGVU8qhY9y+wAW+45g From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" , X-OriginalArrivalTime: 26 Jan 2005 02:04:52.0247 (UTC) FILETIME=[6C306A70:01C5034B] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 25 Jan 2005 18:04:51 -0800 Date: Tue, 25 Jan 2005 18:04:51 -0800 Content-Transfer-Encoding: quoted-printable Petri, I started reviewing the 02-pre2 draft, and have just a few editorial comments: in the abstract (p1): /subsequent HIP message/subsequent HIP messages/ /session keys other security protocols/session keys for other security protocols/ "The basic HIP exchange for two public hosts shows the actual packet flow." The above sentence has been in the abstract since the moskowitz-01 version (5 years); it does not make sense to me. section 1.1 (p6) /not good for using as/not good for use as/ /or as a index/nor as an index/ section 3.1.1 (p11) /has the same length than the/has the same length as the/ /HI.n_len/HI.RSA.n_len/ section 4.1.1 (p16) /function such be used/function should be used/ 4.1.2 (p17) /and its the encrypted public authentication key/and its encrypted public authentication key/ 6.2.18 remember my post from ? I think it should be noted that one of the ECHO_REQUESTs is critical while the other is not. -Jeff > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Tuesday, January 25, 2005 4:52 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Base HIP: 02 pre2 >=20 >=20 >=20 > Folks, >=20 > I uploaded the base draft's current snapshot to >=20 > http://www.hip4inter.net/drafts.php >=20 > (txt, html and diffs as usual) I have made some changes that I have=20 > received since pre-1 version. The biggest change is the UPDATE packet=20 > handling. >=20 > ESP is still defined as a MUST implementation so that we have=20 > something=20 > common between two implementations. >=20 > There are some questions that have come up (now or earlier): >=20 > In 6.2.7 HIP_TRANSFORM >=20 > XXX: Deprecate MD5 in the light of recent development? >=20 > Shall we deprecate? >=20 >=20 > In 6.3. ICMP messages >=20 > Any need to say more about rate limitations? >=20 >=20 > In 8.9 Sending UPDATE packets, at bullet 4. >=20 > Pekka N: "Do we need exponential back off? If not, why not? > Usually dropped packets are taken as an indication of > congestion, and therefore TCP backs off exponentially." >=20 > I haven't yet edited this one into the text, but it sounds=20 > reasonable.=20 > Any objections? >=20 >=20 > ISSUES in the tracker: >=20 > #49 IANA considerations section >=20 > Requires something more. >=20 >=20 > #52 Restricting HIT values >=20 > I haven't yet edited changes into the draft. I will most=20 > likely follow=20 > the discussion that was on the mailing list. >=20 >=20 > #53 Move LSIs to a separate draft >=20 > LSIs are still in the current draft version but can be=20 > removed as there=20 > has not been any objections on the mailing list. >=20 >=20 > #54 Move Appendix A. API issues to a separate draft >=20 > Same comments as in #53. >=20 >=20 > #55 User data transport format negotiation >=20 > The current draft version contains a "negotiation". >=20 > o TLV type values between 2048-4095 are reserved for new=20 > transport formats. > o These values do NOT describe the TLV order in the HIP packet (as is=20 > the case with other TLV type values) > o The transport format TLVs are inserted in the packet in the=20 > order of=20 > preference. >=20 > The text in the draft related to this issue is still quite=20 > bad and must=20 > be edited. >=20 > Related to this, Pekka put in one mail a quick proposal about=20 > introducing new TLV type areas, something like: >=20 > 0- 1023: Fundamental functionality, WG action > - move echo_RESPONSE to 1020 >=20 > 1024- 2047: Reserved > 2048- 4095: Transform parameters > 4096-32768: Reserved > 32768-48XXX: Vendor > 48XXX-65365: Fundamental functionality, WG action >=20 > Any comments on this? >=20 >=20 > /Petri >=20 >=20 > --=20 > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jan 31 05:35:40 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11557 for ; Mon, 31 Jan 2005 05:35:40 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 919787303; Mon, 31 Jan 2005 05:35:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 8766F72F3 for ; Mon, 31 Jan 2005 05:34:57 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF239212C90; Mon, 31 Jan 2005 12:34:47 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040609F7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040609F7@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49b310ac3f68047eebc5094b3cf5c089@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Petri Jokela" , From: Pekka Nikander Subject: Re: [Hipsec] Base HIP: 02 PRE1 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 31 Jan 2005 12:35:10 +0200 Date: Mon, 31 Jan 2005 12:35:10 +0200 Content-Transfer-Encoding: 7bit >>>> 3.2 Local Scope Identifier (LSI) >> >> While I think that we are doing good progress with LSIs currently >> at the RG discussion, it might still be a good option to move LSIs >> into a separate draft. Such a document could discuss LSIs, how >> they are used at the APIs and by applications, and _also_ define >> a HIP protocol extension for informing about used/assigned LSIs. >> Opinions? > > I would favor such a document, scoped as "Using HIP with legacy > APIs" and it could contain more discussion about the LSIs and > incorporate the material in current Appendix A. > > I'd be willing to take a first cut at it. Great! >>>> All HIP implementations MUST implement, at minimum, the ESP >>>> transport format for HIP [23]. >>> >>> Should this be a MUST? Maybe strike this sentence (also in 4.7). >> >> Well, IMHO, it is important to provide some level of user plane >> interoperability. Right now ESP is the lowest common denominator. >> Hence, in order to make all HIP hosts to be able to talk to each >> other, I think it makes sense to make this requirement. > > My concern is that if someone adapts HIP for some non-ESP use > (e.g. a device that is SIP specific) then "MUST" forces that > implementor to code also the ESP portions. > > I am not so concerned about user plane interoperability because > the market can decide these things, and the early implementations > will all support ESP anyway. Well, I have experienced a number of cases at the IETF where the least-common-denominator interoperability has came up, and some people (even the IESG IIRC) have been very strict of having such as a MUST implement case. I agree with you that there seems to be emerging other uses of HIP but the original intention, where ESP is a central part. My suggestion is that we go for a MUST in the base specification, but also add something like: "Specific future documents of MAY define HIP profiles where implementing ESP is not MANDATORY. However, any such use MUST be explicitly labelled to be non-compliant with the ESP transport format and method." Hence, as a default case, I-D.ietf-hip-base implementations MUST be compliant with I-D.ietf-hip-esp, unless they are also compliant with which explicitly allows compliance to I-D.ietf-hip-base without compliance to I-D.ietf-hip-esp Ok? >>> Section 8.2: >>>> 3. The IP addresses in the datagram are replaced with the HITs >>>> associated with the ESP SA. HIP association. ... >>> > > ..., I might suggest something like: > "The IP addresses in the datagram are replaced by constructing the > correct pseudo-header representation for the packet using HITs-- > see section 4.2" or similar. Looks good to me other than I would add parenthesis round "pseudo", resulting in: "The IP addresses in the datagram are replaced by constructing the correct (pseudo-)header representation for the packet, using HITs in the place of IP addresses -- see section 4.2" Ok? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Jan 31 08:07:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24855 for ; Mon, 31 Jan 2005 08:07:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 82A6A7303; Mon, 31 Jan 2005 08:07:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 82D4972F3 for ; Mon, 31 Jan 2005 08:06:05 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 034BE212C90; Mon, 31 Jan 2005 15:06:01 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040609CE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040609CE@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <260ddc8483f4741ab92a19e42aef53ac@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 31 Jan 2005 15:06:24 +0200 Date: Mon, 31 Jan 2005 15:06:24 +0200 Content-Transfer-Encoding: 7bit >> Firstly, if we do adopt any scheme like this, I think that we must >> follow the usual "be strict in what you generate and liberal in what >> you accept" rule. That is, even if we decided that current >> hosts MUST generate only 01/10 HITs, they also SHOULD accept any HITs. > > I am OK with the proposed restriction, in the interest of facilitating > experimentation. I would suggest making it SHOULD generate/SHOULD > accept, and explain the rationale for this, and that it probably will > be lifted in the future. Since I haven't seen any objections to this proposed restriction, I hereby suggest that we add the following text to the HIT section in the base specification. Comments? --Pekka To facilitate experimentation and make certain kind of implementations easier, the following restrictions are temporarily placed on HITs. These restriction are to be lifted at the end of 2008. That is, after January 1st 2009, any implementation claiming conformance to this specification MUST accept any HITs from peers and be able to process them normally. The restrictions: Before the end of 2008, all implementations SHOULD restrict the HITs they generate to ones whose upper-most (left-most) two bits are either binary 01 or 10. That is, when generating new HIs, if the resulting HIT has as its first two bits as 00 or 11, the implementation SHOULD generate new HIs until it generates one that fulfils this restriction. Additionally, a conforming implementation MAY refuse to communicate with a peer that has a HIT with the upper-most bits either 00 or 11. When refusing a HIP connection on this bases, the implementation MUST send an R2 with a NOTIFY payload, with the NOTIFY code being UNSUPPORTED_HIT_VALUE_RANGE. A rationale: One way to implement HIP is to use unmodified IPv6, TCP and UDP implementations in the stack, using HITs in the place of IPv6 addresses. In such an implementation, modifications are only needed at the API level, where it may be necessary to convert HITs into LSIs and vice versa, and at or below ESP, where it is necessary to convert HITs into locators (IP addresses) and vice versa. However, if the IPv6 address space and the HIT value space overlap, it becomes quite hard to define secure IPsec policies. Furthermore, there is also the possibility of having a conflict between a HIT value and an IPv6 address, leading to potential confusion within the stack. This restriction temporarily allows such simple minded implementations. It is expected that such implementations will eventually migrate to a different implementation details, e.g., by tagging the values either as HITs or IPv6 addresses. However, tagging the values may be hard in existing IPv6 implementations; the purpose of this restriction is to allow such HIP implementations that rely on and patch on existing IPv6 implementations. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec