From pekka.nikander@nomadiclab.com Sat Nov 1 00:27:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Nov 1 00:27:01 2003 Subject: [Hipsec] [Fwd: Certicom IP Rights] Message-ID: <3FA34B4E.3060300@nomadiclab.com> This is a multi-part message in MIME format. --------------090409080306090603040100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Should we be worried about this? --Pekka --------------090409080306090603040100 Content-Type: message/rfc822; name="Fwd: Certicom IP Rights" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Fwd: Certicom IP Rights" X-Sieve: cmu-sieve 2.0 Return-Path: Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n97.nomadiclab.com (Postfix) with ESMTP id 5AEE61C for ; Sat, 1 Nov 2003 00:13:25 +0200 (EET) Received: by n2.nomadiclab.com (Postfix) id 08C56212C85; Sat, 1 Nov 2003 00:00:14 +0200 (EET) Delivered-To: pnr@nomadiclab.com Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 00698212C54 for ; Sat, 1 Nov 2003 00:00:14 +0200 (EET) Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by outside.nomadiclab.com (Postfix) with ESMTP id 286B1113E09 for ; Sat, 1 Nov 2003 00:00:08 +0200 (EET) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14617 Fri, 31 Oct 2003 15:20:36 -0500 (EST) Message-Id: <5.2.0.9.2.20031031152519.0449f590@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 15:29:27 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Fwd: Certicom IP Rights Cc: iesg@ietf.org, IMcKinnon@certicom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPsec Working Group: I just got this note, which is a follow-up to a query that I sent to Certicom in July 2003. I have asked Mr. McKinnon to post an updated IPR statement as soon as possible. Russ --- Original Message --- To: housley@vigilsec.com From: Ian McKinnon Date: Fri, 31 Oct 2003 15:14:09 -0500 Dear Mr. Housley: First, let me apologize for not responding sooner on our our Intellectual Property position re the August email stating that Certicom may have certain IP rights covering some aspects of the proposed IKEv2 proposal draft . Our IP group was totally consumed completing a $US 25 million IP licensing arrangement with the US Governments National Security Agency for a subset of our intellectual property portfolio for a limited field of use as it relates to its high assurance initiatives. We wish to advise the IETF that Certicom believes it has rights under patents and/or pending applications that relate to RFC 3526 "More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", RFC 2409 "Internet Key Exchange", Internet Draft (draft-ietf-ipsec-ikev2-11.txt) "Internet Key Exchange (IKEv2) Protocol" and other IETF standards using MODP Groups. The applicable patents include, but are not limited to, US Patents #5,933,504, #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent Application Publications #2001/0014153, #2002/0090085, and PCT Application #WO 00/01109, and corresponding foreign applications. Some of the patents listed in the previous paragraph were part of the NSA licensing arrangement discussed in paragraph 1 as they relate to elliptic curve cryptography (ECC). For applications requiring higher levels of security, we believe that one should consider ECC for the technological advantages over other public-key schemes. Certicom is willing to grant a royalty free license to the patents and patent pending listed in paragraph 2 for the purpose of practicing the art of public key cryptography as it pertains to IETF IKE standards in the limited field of use of MODP public key cryptography implemented using the well known Groups 1 and 2 as defined in RFC 2409. Certicom will send the IETF terms of the royalty free license and will post this our web site shortly. Outside the implementation of IETF IKE standards using well known Groups 1 and 2 Certicom is prepared to grant a license to such intellectual property on reasonable, non-discriminatory terms and conditions, provided that the licensee provides a similar grant for any relevant patents under their control to Certicom. Ian McKinnon President and CEO Certicom Corp --------------090409080306090603040100-- From rgm@htt-consult.com Sun Nov 2 15:05:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Sun Nov 2 15:05:00 2003 Subject: [Hipsec] draft-moskowitz-hip-arch-05.txt Message-ID: <6.0.0.22.2.20031102153330.03ce1e18@localhost> Date: Sun, 2 Nov 2003 13:19:38 -0500 To: rgm@icsalabs.com From: Avi Drissman Subject: HIP spec Content-Type: text/plain; charset="us-ascii" ; format="flowed" On page 4, section 2, first paragraph, "built from three principle components" ought to be "built from three principal components", yes? ============================================================== oops. From pekka.nikander@nomadiclab.com Mon Nov 3 01:04:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 3 01:04:01 2003 Subject: [Hipsec] Volunteers for taking minutes at the BOF Message-ID: <3FA5EE03.3000302@nomadiclab.com> As everybody on this list should know by now, we are heading for a BOF at Minneapolis. Right now it looks like the ADs want to move the BOF to Monday morning; please have a look at the agenda so that you don't miss the BOF. Anyway, BOFs, just like Working Groups, need to submit minutes to the IETF meeting proceedings. I am willing to produce the final minutes from notes, but experience has shown that it is very important to have note takers at the meeting that will take notes of the ongoing discussion. While it is not necessary to be able to record everything people say, a good note taker manages to mark down the names of all speakers at the microphones, and the essence of their message. Hence, I am looking for two or three note takers that are willing to take notes during the BOF. I would like to get the notes immediately after the BOF (completely unedited, no spelling mistakes corrected is perfectly OK). I will try to process the notes still during the same day (or next morning latest) into draft minutes, and post them to this list. Once people have had chance to correct any mistakes and record what they would like to have said instead of what they said :-), I will submit the minutes to the proceedings. --Pekka Nikander From mcr@sandelman.ottawa.on.ca Mon Nov 3 11:09:01 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Mon Nov 3 11:09:01 2003 Subject: [Hipsec] [Fwd: Certicom IP Rights] In-Reply-To: Your message of "Sat, 01 Nov 2003 07:57:34 +0200." <3FA34B4E.3060300@nomadiclab.com> Message-ID: <23934.1067877555@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: Pekka> Should we be worried about this? --Pekka Yes/no. From what I understand about the claim (which was discussed at IPsec last July), it applies to people who are generating MODP groups as used in DH work. The algorithm that is claimed is never used in a production system. Rather, it is used by the person *writing the IETF document* to generate an appropriate group. Certicom can not claim any rights to the resulting *number*. That's silly. So, their offer is silly. It also tells me that their lawyers possibly don't understand what their IP covers. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6aEsYqHRg3pndX9AQFXAgQAjh37I7+4n27OLI2sbb8j8JqLB7fBTU5J evwIXG0Wsh7KQoRccNM48gSKhUGFQ92i9Yco5sPLyRHSafULCymGfxp3LHyyZrSo zetfuMpFNFIhBfeuVs+/u+/Bqlac9vik1YDc8BgB4Ke3LDdCRZZhPXVldQ9qxwqM pi6Rm4cPqwI= =yOOD -----END PGP SIGNATURE----- From kivinen@ssh.fi Mon Nov 3 16:54:01 2003 From: kivinen@ssh.fi (Tero Kivinen) Date: Mon Nov 3 16:54:01 2003 Subject: [Hipsec] IKEv2 Mobility and Multihoming BOF Tue, Nov 11, 1700-1800 Message-ID: <16294.52860.518239.410976@ryijy.hel.fi.ssh.com> There has been some interest in the IPsec working group to add features to IKEv2 to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The features should then be used by the Mobile IP, HIP, etc working groups as building blocks to create their final protocols, but some of the features can immediately be used in the IPsec VPNs too (client roaming in VPN case, SCTP, multihoming support). The BOF is currently scheduled for Tuesday, November 11, 2003, at 1700-1800. The BOF have some kind of web pages at http://mobike.kivinen.iki.fi/index.html. The web pages have agenda for the meeting, proposed charter and basic introduction to the problem. The BOF mailing list: General Discussion: mobike@machshav.com To subscribe: mobike-request@machshav.com Archive and general information: https://www.machshav.com/mailman/listinfo/mobike The MOBIKE BOF's goal is to verify that we have enough interest to define mobility and multihoming extensions to the current IKEv2 protocol. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From rgm@htt-consult.com Tue Nov 4 10:59:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Tue Nov 4 10:59:00 2003 Subject: [Hipsec] They moved the HIPBOF Message-ID: <6.0.0.22.2.20031104112800.03a1f728@localhost> To monday, But there are no good flights from Minneapolis to Albuquerque other than the 11:30am which would not give me anytime at the BOF :) So I am not changing my flight plans. I guess I might see you all in the summer, depending on where the meeting is held. From pekka.nikander@nomadiclab.com Tue Nov 4 14:04:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Nov 4 14:04:00 2003 Subject: [Hipsec] They moved the HIPBOF In-Reply-To: <6.0.0.22.2.20031104112800.03a1f728@localhost> References: <6.0.0.22.2.20031104112800.03a1f728@localhost> Message-ID: <3FA7FF55.9040304@nomadiclab.com> Robert Moskowitz wrote: > To monday, and they are considering moving it again... Or perhaps arranging a secondary BOF with APPSAREA people, or something. --Pekka From shep@alum.mit.edu Tue Nov 4 14:15:03 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Tue Nov 4 14:15:03 2003 Subject: [Hipsec] They moved the HIPBOF In-Reply-To: Your message of Tue, 04 Nov 2003 21:34:45 +0200. <3FA7FF55.9040304@nomadiclab.com> Message-ID: <200311041946.hA4JkLWB020351@ginger.lcs.mit.edu> Would it make sense to combine the mobike bof and the hipbof bof and ask that they go together in a 2-hour slot somewhere? On the surface, it would seem that there is much overlap between these two bofs. -Tim Shepard shep@alum.mit.edu From jari.arkko@piuha.net Tue Nov 4 14:56:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Nov 4 14:56:01 2003 Subject: [Hipsec] They moved the HIPBOF In-Reply-To: <200311041946.hA4JkLWB020351@ginger.lcs.mit.edu> References: <200311041946.hA4JkLWB020351@ginger.lcs.mit.edu> Message-ID: <3FA80A9B.7060103@piuha.net> Tim Shepard wrote: > Would it make sense to combine the mobike bof and the hipbof bof and > ask that they go together in a 2-hour slot somewhere? On the > surface, it would seem that there is much overlap between these two bofs. I don't know if movements can be made -- the secretariat usually has a lot of constraints they have been given. You could try. Anyway, I think the hip and mobike work deserve their own time -- the approaches, intended WG forms, current status and expected time scales differ a lot. But they could be in consequtive slots, for instance. And its definately worth discussing which approach(es) shall be pursued at IETF and whether there is overlap. Or some dependencies/common parts. Say, if IPsec WG is going to be terminated, would mobike be interested in working on the BEET mode in addition to IKE enhancements? --Jari From mkomu@niksula.hut.fi Thu Nov 6 10:50:02 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Thu Nov 6 10:50:02 2003 Subject: [Hipsec] bug in E3 in the state machine? Message-ID: draft-08, section 5.4.2_ +---------+ | E3 | HIP SA established +---------+ .. Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and cycle at E3 .. Receive R2, drop and stay at E3 Receive R1, send I2 but drop the incoming R2? Is there are bug here or did I misunderstand something? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From thomas.r.henderson@boeing.com Thu Nov 6 11:26:02 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Nov 6 11:26:02 2003 Subject: [Hipsec] bug in E3 in the state machine? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos.boeing.com> I agree, under normal cases of no reordering, this should not happen. You should only get R1 if you have sent I1. If you=20 send I1, you are by definition in state E1. So we should not=20 be processing R1 while in state E3.=20 I would suggest: "Receive R1, drop and stay at E3" Tom > -----Original Message----- > From: Miika Komu [mailto:mkomu@niksula.hut.fi] > Sent: Thursday, November 06, 2003 8:21 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] bug in E3 in the state machine? >=20 >=20 > draft-08, section 5.4.2_ >=20 > +---------+ > | E3 | HIP SA established > +---------+ > .. > Receive R1, process with SA and Birthday check > if successful, send I2, prepare to drop old SA and cycle at E3 > .. > Receive R2, drop and stay at E3 >=20 > Receive R1, send I2 but drop the incoming R2? Is there are=20 > bug here or did > I misunderstand something? >=20 > --=20 > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From rgm@htt-consult.com Thu Nov 6 11:47:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Thu Nov 6 11:47:00 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos. boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos.boeing.com> Message-ID: <6.0.0.22.2.20031106121749.03afe468@localhost> At 11:55 AM 11/6/2003, Henderson, Thomas R wrote: >I agree, under normal cases of no reordering, this should not >happen. You should only get R1 if you have sent I1. If you >send I1, you are by definition in state E1. So we should not >be processing R1 while in state E3. > >I would suggest: >"Receive R1, drop and stay at E3" Give me some time. I will work out the attack model why I did this. I spent a lot of time working out all the combinations. >Tom > > > -----Original Message----- > > From: Miika Komu [mailto:mkomu@niksula.hut.fi] > > Sent: Thursday, November 06, 2003 8:21 AM > > To: hipsec@honor.trusecure.com > > Subject: [Hipsec] bug in E3 in the state machine? > > > > > > draft-08, section 5.4.2_ > > > > +---------+ > > | E3 | HIP SA established > > +---------+ > > .. > > Receive R1, process with SA and Birthday check > > if successful, send I2, prepare to drop old SA and cycle at E3 > > .. > > Receive R2, drop and stay at E3 > > > > Receive R1, send I2 but drop the incoming R2? Is there are > > bug here or did > > I misunderstand something? > > > > -- > > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > > _______________________________________________ > > 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 Julien.Laganier@Sun.COM Thu Nov 6 12:22:04 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Nov 6 12:22:04 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos.boeing.com> Message-ID: <200011061851.23655.julien.laganier@sun.com> On Thursday 06 November 2003 17:55, Henderson, Thomas R wrote: > I agree, under normal cases of no reordering, this should not > happen. You should only get R1 if you have sent I1. > > If you > send I1, you are by definition in state E1. So we should not > be processing R1 while in state E3. > > I would suggest: > "Receive R1, drop and stay at E3" Hi Tom, The section "5.3 Reboot and SA timeout restart of HIP" says: ----------------------- If a system receives an ESP packet for an unknown SPI, the assumption is that it has lost the state and its peer did not. In this case, the system treats the ESP packet like an I1 packet and sends an R1 packet. The initiator HIT is typically NULL in the R1, since the system usually does not know the peer's HIT any more. The system receiving the R1 packet first checks to see if it has an established and recently used SA with the party sending the R1. If such an SA exists, the system checks the Birthday, and if the Birthday is greater than the current SA's Birthday, it processes the R1 packet, optionally queuing the payload packet(s) to be resent later. The peer system processes the I2 in the normal manner, and replies with an R2. This will re-establish state between the two peers. Note that the process will result in new ESP SAs being used, and therefore simply resending ESP packets is not sufficient. ----------------------- It seems that in this case you are in state E3, haven't send an I1, but receive an R1 (your correspondent lost his state). And so you should reply with I2 after birthday check, and prepare to receive R2. If you can't receive R2 at this point (Like Bob Moskowitz told) then I guess that the whole scenario above doesn't work, unless we create another pending state (E5: resync pending ?) Thoughts? Thanks, --julien > > > -----Original Message----- > > From: Miika Komu [mailto:mkomu@niksula.hut.fi] > > Sent: Thursday, November 06, 2003 8:21 AM > > To: hipsec@honor.trusecure.com > > Subject: [Hipsec] bug in E3 in the state machine? > > > > > > draft-08, section 5.4.2_ > > > > +---------+ > > > > | E3 | HIP SA established > > > > +---------+ > > .. > > Receive R1, process with SA and Birthday check > > if successful, send I2, prepare to drop old SA and cycle at E3 > > .. > > Receive R2, drop and stay at E3 > > > > Receive R1, send I2 but drop the incoming R2? Is there are > > bug here or did > > I misunderstand something? > > > > -- > > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > > _______________________________________________ > > 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 -- "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Explanation obtained from the Micro$oft help desk. -- Julien Laganier SUN Microsystems Laboratories *************************************************** SunNetwork EMEA 2003 Conference and Pavilion "Get Connected to the Future of Network Computing!" WHEN: December 3-4, 2003 WHERE: ICC * Berlin, Germany For more information or to register for the conference, please visit http://sun.com/sunnetwork. **************************************************** From rgm@htt-consult.com Thu Nov 6 12:50:02 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Thu Nov 6 12:50:02 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: <200011061851.23655.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D48@xch-nw-27.nw.nos.boeing.com> <200011061851.23655.julien.laganier@sun.com> Message-ID: <6.0.0.22.2.20031106131951.03ae65e8@localhost> I knew I worked through some of this. You have to look at each state and what would happen if you receive any packet. Otherwise you do not have a complete state machine. At 12:52 PM 11/6/2000, Julien Laganier wrote: >On Thursday 06 November 2003 17:55, Henderson, Thomas R wrote: > > I agree, under normal cases of no reordering, this should not > > happen. You should only get R1 if you have sent I1. > > > > If you > > send I1, you are by definition in state E1. So we should not > > be processing R1 while in state E3. > > > > I would suggest: > > "Receive R1, drop and stay at E3" > >Hi Tom, > >The section "5.3 Reboot and SA timeout restart of HIP" says: >----------------------- > If a system receives an ESP packet for an unknown SPI, the assumption > is that it has lost the state and its peer did not. In this case, the > system treats the ESP packet like an I1 packet and sends an R1 > packet. The initiator HIT is typically NULL in the R1, since the > system usually does not know the peer's HIT any more. > > The system receiving the R1 packet first checks to see if it has an > established and recently used SA with the party sending the R1. If > such an SA exists, the system checks the Birthday, and if the > Birthday is greater than the current SA's Birthday, it processes the > R1 packet, optionally queuing the payload packet(s) to be resent > later. The peer system processes the I2 in the normal manner, and > replies with an R2. This will re-establish state between the two > peers. Note that the process will result in new ESP SAs being used, > and therefore simply resending ESP packets is not sufficient. >----------------------- > >It seems that in this case you are in state E3, haven't send an I1, but >receive an R1 (your correspondent lost his state). > >And so you should reply with I2 after birthday check, and prepare to receive >R2. If you can't receive R2 at this point (Like Bob Moskowitz told) then I >guess that the whole scenario above doesn't work, unless we create another >pending state (E5: resync pending ?) > >Thoughts? Thanks, > >--julien > > > > > > -----Original Message----- > > > From: Miika Komu [mailto:mkomu@niksula.hut.fi] > > > Sent: Thursday, November 06, 2003 8:21 AM > > > To: hipsec@honor.trusecure.com > > > Subject: [Hipsec] bug in E3 in the state machine? > > > > > > > > > draft-08, section 5.4.2_ > > > > > > +---------+ > > > > > > | E3 | HIP SA established > > > > > > +---------+ > > > .. > > > Receive R1, process with SA and Birthday check > > > if successful, send I2, prepare to drop old SA and cycle at E3 > > > .. > > > Receive R2, drop and stay at E3 > > > > > > Receive R1, send I2 but drop the incoming R2? Is there are > > > bug here or did > > > I misunderstand something? > > > > > > -- > > > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > > > _______________________________________________ > > > 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 > >-- >"Memory is like gasoline. You use it up when you are running. >Of course you get it all back when you reboot..."; >Explanation obtained from the Micro$oft help desk. >-- >Julien Laganier >SUN Microsystems Laboratories > >*************************************************** > SunNetwork EMEA 2003 Conference and Pavilion >"Get Connected to the Future of Network Computing!" > > WHEN: December 3-4, 2003 > WHERE: ICC * Berlin, Germany > >For more information or to register for the >conference, please visit http://sun.com/sunnetwork. >**************************************************** From thomas.r.henderson@boeing.com Thu Nov 6 20:02:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Nov 6 20:02:01 2003 Subject: [Hipsec] bug in E3 in the state machine? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D4B@xch-nw-27.nw.nos.boeing.com> How do we know that the ESP packet corresponds to a HIP SA and not an IKE SA if we have lost our state? Shouldn't there be a more general response at IPsec or ICMP level (rather than responding at=20 HIP level) to the receipt of an unknown SPI? Or no response at all in some scenarios? (this seems like a potential means to circumvent=20 policy controls on who a responder may elect to send an R1 to) > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > Sent: Monday, November 06, 2000 9:53 AM > To: Henderson, Thomas R > Cc: Miika Komu; HIPsec; Robert Moskowitz > Subject: Re: [Hipsec] bug in E3 in the state machine? >=20 >=20 >=20 > Hi Tom, >=20 > The section "5.3 Reboot and SA timeout restart of HIP" says: > ----------------------- > If a system receives an ESP packet for an unknown SPI, the=20 > assumption > is that it has lost the state and its peer did not. In=20 > this case, the > system treats the ESP packet like an I1 packet and sends an R1 > packet. The initiator HIT is typically NULL in the R1, since the > system usually does not know the peer's HIT any more. >=20 >=20 >=20 From pekka.nikander@nomadiclab.com Fri Nov 7 02:55:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Nov 7 02:55:02 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: References: Message-ID: <3FAB5713.7020506@nomadiclab.com> Miika Komu wrote: > draft-08, section 5.4.2_ > > +---------+ > | E3 | HIP SA established > +---------+ > .. > Receive R1, process with SA and Birthday check > if successful, send I2, prepare to drop old SA and cycle at E3 > .. > Receive R2, drop and stay at E3 > > Receive R1, send I2 but drop the incoming R2? Is there are bug here or did > I misunderstand something? I think this is my mistake between -07 and -08. If I remember correctly, earlier the rule was to go to E2 upon receiving an R1. However, if an attacker can force the peer to increment the birthday counter (that seems doable), it can then trigger a suitable R1 and replay it to the target node, causing the target node to unnecessarily to drop the IPsec SAs and go to E2. That would be bad. Hence, I changed the rule to "prepare to drop" the old SAs instead of dropping them, and cycling back to E3. Apparently that wasn't quite enough. I see two basic choices in dealing with this: 1. Create a new state (E5), as somebody suggested. 2. Change the rule on receiving R2 to read something like "Receive R2, check if a corresponding R1 has been recently received, .... I think a new state would probably be better. One more thing. I don't know if it is good to name the substates of E3 as E4, E5, ... as we do now. Maybe it would be better to have E3 (as now), rename E4 as E3.1, and make the new state E3.2. In that way the new states would be understood to be substates of E3, making the spec perhaps easier to understand. And yes, somebody has to work out the interactions between E4/E3.1 and E5/E3.2. --Pekka From pekka.nikander@nomadiclab.com Fri Nov 7 03:11:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Nov 7 03:11:00 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D4B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5D4B@xch-nw-27.nw.nos.boeing.com> Message-ID: <3FAB5AF4.5080902@nomadiclab.com> Henderson, Thomas R wrote: > How do we know that the ESP packet corresponds to a HIP SA and not > an IKE SA if we have lost our state? Shouldn't there be a more > general response at IPsec or ICMP level (rather than responding at > HIP level) to the receipt of an unknown SPI? Or no response at all > in some scenarios? (this seems like a potential means to circumvent > policy controls on who a responder may elect to send an R1 to) Very good question. If I remember correctly (probably not), the IPsec folks decided not to have this kind of functionality. Indeed, the current IPsec architecture doesn't support any notification of receiving packets with an unknown SA. One possible reason for that might have been that such indications would allow an attacker to learn which SAs are in use and which are not, and that might be a security risk. (At the very high security levels it most probably is a security risk, but HIP is not really designed to be that secure, but more as a *practical* security solution.) Hence, this feature in HIP is very much experimental, and more or less reverses the decision that the IPsec WG made. I'd suppose Bob can tell us more about the background. --Pekka Nikander From Julien.Laganier@Sun.COM Fri Nov 7 03:24:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Nov 7 03:24:00 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: <3FAB5713.7020506@nomadiclab.com> References: <3FAB5713.7020506@nomadiclab.com> Message-ID: <200311070954.44451.julien.laganier@sun.com> On Friday 07 November 2003 09:25, Pekka Nikander wrote: > Miika Komu wrote: > > draft-08, section 5.4.2_ > > > > +---------+ > > > > | E3 | HIP SA established > > > > +---------+ > > .. > > Receive R1, process with SA and Birthday check > > if successful, send I2, prepare to drop old SA and cycle at E3 > > .. > > Receive R2, drop and stay at E3 > > > > Receive R1, send I2 but drop the incoming R2? Is there are bug here or > > did I misunderstand something? > > I think this is my mistake between -07 and -08. > > If I remember correctly, earlier the rule was to go to E2 upon > receiving an R1. However, if an attacker can force the peer > to increment the birthday counter (that seems doable), it can > then trigger a suitable R1 and replay it to the target node, > causing the target node to unnecessarily to drop the IPsec SAs > and go to E2. That would be bad. > > Hence, I changed the rule to "prepare to drop" the old SAs instead > of dropping them, and cycling back to E3. Apparently that wasn't > quite enough. > > I see two basic choices in dealing with this: > > 1. Create a new state (E5), as somebody suggested. > > 2. Change the rule on receiving R2 to read something like > > "Receive R2, check if a corresponding R1 has been > recently received, .... > > I think a new state would probably be better. I concur cuz an implementation isn't supposed to keep track of received R1s (2), as opposed to (1), where receiving an R1 cause the state machine to transition to E3.resync (or E5), so that the subsequent R2 can be accepted for some duration (I guess we needs to timeout and revert to E3 after some time waiting for an R2). > One more thing. I don't know if it is good to name the > substates of E3 as E4, E5, ... as we do now. Maybe it would > be better to have E3 (as now), rename E4 as E3.1, and make > the new state E3.2. In that way the new states would be > understood to be substates of E3, making the spec perhaps > easier to understand. I agree too. What about E3, E3.rekey (E4), and E3.resync (E5) ? > And yes, somebody has to work out the interactions between > E4/E3.1 and E5/E3.2. I'll try to take a look at that. Thanks, --julien From pekka.nikander@nomadiclab.com Mon Nov 10 18:09:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 10 18:09:01 2003 Subject: [Hipsec] Slides at today's HIP bof Message-ID: <3FB02206.5000308@nomadiclab.com> The slides we used today at the HIP bof are now available at http://www.tml.hut.fi/~pnr/presentations/hipbof-slides.pdf If anybody wants to have them in Apple KeyNote format, just send me e-mail. --Pekka Nikander From rgm@htt-consult.com Tue Nov 11 11:41:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Tue Nov 11 11:41:01 2003 Subject: [Hipsec] bug in E3 in the state machine? In-Reply-To: References: Message-ID: <6.0.0.22.2.20031111095732.03c16b90@localhost> This state machine first appeared in 05.txt (replacing the harder to follow state machine in 04). It had the drop R2 in E3 back then. An R2 while in E3 can be the result of: A replay attack. Drop it. A retransmission for some stupid reason. It was a stupid desision by something and Drop it. This is in there for state machine completeness. Each state MUST have a response for ANY possible HIP dataframe. As a result of this review, I noticed that in 5.4.3, state E3, does not list R2 for staying in E3. R2 should be added to the list of datagrams on that loop link. Thank you for this opportunity to go back and look at my effort for this state machine, in the next six months I have committed to redesigning the state machines in IEEE 802.1X so that there is only one machine for both parties like HIP has. Not like the current Supplicant/Authenticator machines :) At 07:20 AM 11/6/2003, Miika Komu wrote: >draft-08, section 5.4.2_ > > +---------+ > | E3 | HIP SA established > +---------+ > .. > Receive R1, process with SA and Birthday check > if successful, send I2, prepare to drop old SA and cycle at E3 > .. > Receive R2, drop and stay at E3 > >Receive R1, send I2 but drop the incoming R2? Is there are bug here or did >I misunderstand something? > >-- >Miika Komu miika@iki.fi http://www.iki.fi/miika/ >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec From jari.arkko@piuha.net Wed Nov 12 09:55:02 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Nov 12 09:55:02 2003 Subject: [Hipsec] feature interactions of HIP and IPsec Message-ID: <3FB23987.90006@piuha.net> Stephen and Eric, In the HIP BOF you expressed a worry of how HIP and IPsec would work together, and whether there'd be some negative impacts to the correct operation of traditional IPsec if HIP were adopted. The purpose of this e-mail is to dwell a bit deeper into this subject and try to see if there is indeed a problem. My preliminary conclusion is that there is no problem. But let me first ask a clarification regarding your concerns. I am unsure which problem you had in mind: a) Opportunistic security is inherently bad, and you should not bring it to IPsec. b) The simultaneous use of HIP and traditional IPsec in the same host leads to problems, even if the intention is not to use them for the same packets. c) It is not possible to use HIP and traditional IPsec for the same packets. That is, one must choose between "security" (ie traditional IPsec and all the security configurations) and the nice features offered by HIP. If you are worried about point a), I don't know what to say. Not everyone needs to have a managed security mechanism, and they still want to move around. It sounded a bit like some people in the meeting were worried about point c). Perhaps you were too. Let me argue that we should not demand that much from the protocols, HIP may not help you in *all* situations. If you are running traditional IPsec, you should stick to it. If you need mobility or multihoming in that situation, perhaps you should re-establish your SAs upon movements, or use MOBIKE. But I think the main issue that people should pay attention to is point b). If I add the HIP feature to my host, the VPN that I already have should not break. If the administrator has configured a certain trusted peer for some traffic, HIP should not open a hole for others to send such traffic. However, this does not appear to be a problem in HIP. Here's why: it is possible to implement HIP in such a way that HIP operates still under the usual IPsec policy rules, and the SPD gets to decide what is done with each packet. (That's how the Ericsson Research implementation works.) There's one thing that a HIP-enabled implementation must be able to do, and that is the selection of the right key management protocol. For a given policy entry, the kernel must be able to tell whether it should talk to the IKE daemon or the HIP daemon. If we require this -- and that requirement can be put in the HIP specifications -- the rest is easy. HIP's policy entries can be put last in the policy data base, meaning that the configured security always takes precedence. I also think that HIP operates within the normal 2401 rules. The only possible extension of 2401/2406 rules that I can see is BEET mode, but that seems more like a separate component than a core part of HIP. In conclusion, provided that the HIP specifications state the one additional requirement of allowing KMP selection, I don't think there are any implications for traditional IPsec usage. On the other hand, we also have to realize that some people may want to implement HIP without implementing IPsec, and just use ESP without the rest of IPsec. (That is how Andrew McGregor's user level Python implementation works.) I'm not sure whether that type of implementation can be made to work with existing IPsec in the host. Then again, such implementations should probably be targeted to situations where there is no IPsec in the host at all yet. Comments? --Jari From andrew@indranet.co.nz Wed Nov 12 10:16:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Nov 12 10:16:00 2003 Subject: [Hipsec] feature interactions of HIP and IPsec In-Reply-To: <3FB23987.90006@piuha.net> References: <3FB23987.90006@piuha.net> Message-ID: <15040000.1068651890@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, November 12, 2003 03:45:43 PM +0200 Jari Arkko wrote: > In conclusion, provided that the HIP specifications > state the one additional requirement of allowing KMP selection, > I don't think there are any implications for traditional > IPsec usage. On the other hand, we also have to realize that > some people may want to implement HIP without implementing IPsec, > and just use ESP without the rest of IPsec. (That is how Andrew > McGregor's user level Python implementation works.) I'm not > sure whether that type of implementation can be made to work > with existing IPsec in the host. Then again, such implementations > should probably be targeted to situations where there is no > IPsec in the host at all yet. > > Comments? > > --Jari PyHIP is presently targeted to Linux 2.4 systems without IPSec of any kind, and so presently it has no facilities for cooperating with IPSec (and indeed implements a BEET mode ESP itself). However there is no reason it can't use the SPD and kernel SAs and ESP, in which case it would be the same as any other HIP daemon that does that. In general, the issues are KMP selection and SPI selection to avoid collisions. Neither is insuperable, and I agree that HIP should have some wording about these. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP7JVflGmVIGYWzvRAQG4iwP9H0J9S4D40B5JHSeaPqd12e3q25LBaC/q s4cM+HiRH6xediNbkClD+LK4ulD1Vfo9xoc3ZbcnijM1XlsudeaOeiQwWu23WA/x dYrfEBB53ztUsZRUMrPToQmmEC/xujkQvcn7/CvCLt1qMlh89oKDdoy5LahW5M5L etSilpBEE14= =LA1q -----END PGP SIGNATURE----- From rgm@htt-consult.com Wed Nov 12 10:55:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Wed Nov 12 10:55:01 2003 Subject: [Hipsec] feature interactions of HIP and IPsec In-Reply-To: <3FB23987.90006@piuha.net> References: <3FB23987.90006@piuha.net> Message-ID: <6.0.0.22.2.20031112092054.03cdb840@localhost> At 06:45 AM 11/12/2003, Jari Arkko wrote: > c) It is not possible to use HIP and traditional > IPsec for the same packets. That is, one must > choose between "security" (ie traditional IPsec > and all the security configurations) and the > nice features offered by HIP. The interesting scenario is IPsec over HIP. This is to support a mobile host connecting to a corporate VPN. 2401 fully defines multiple encrypting layers. Sometimes members of the workgroup complained about this, and SteveK defended it admirably. Now it shows yet another advantage. Of course there are two ways to implement this scenario: IPsec over HIP IPinIP over HIP But this is just ruminations while listing to discussions on 802.1af (general link security encapsulation!) Back to listening to Allyn..... From kent@bbn.com Wed Nov 12 12:10:03 2003 From: kent@bbn.com (Stephen Kent) Date: Wed Nov 12 12:10:03 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3FB23987.90006@piuha.net> References: <3FB23987.90006@piuha.net> Message-ID: At 15:45 +0200 11/12/03, Jari Arkko wrote: >Stephen and Eric, > >In the HIP BOF you expressed a worry of how HIP and IPsec >would work together, and whether there'd be some negative >impacts to the correct operation of traditional IPsec if HIP >were adopted. The purpose of this e-mail is to dwell a bit >deeper into this subject and try to see if there is indeed >a problem. My preliminary conclusion is that there is no >problem. I did not say there was a problem per se. Pekka, in the HOP BOF, said that he wanted to use ESP with HIP, but that the processing required did not match that described in 2401, or what is likely to be in 2401bis. Thus I noted that if HIP uses the ESP syntax, but does not follow the processing model described in 2401/bis, then the result is not IPsec. Pekka agreed with that characterization in the HIP BOF, but later seemed to be uncomfortable when I repeated the same observation in the IPsec WG meeting. > >But let me first ask a clarification regarding your concerns. >I am unsure which problem you had in mind: > > a) Opportunistic security is inherently bad, > and you should not bring it to IPsec. IPsec offers access control as an intrinsic feature. However, an admin (e.g., a user for a single user host that employs Ipsec) is free to configure the SPD to permit SA establishment with any peer, and to allow any traffic to traverse such an SA. So, in the extreme, one can locally choose to override the access control features of IPsec. Does this match your definition of "opportunistic security?" If, so, then there is no inherent conflict. > b) The simultaneous use of HIP and traditional > IPsec in the same host leads to problems, > even if the intention is not to use them > for the same packets. One of Pekka's slides in the HIP BOF called for processing packets using a mix of tunnel and transport mode features. this clearly conflicts with 2401/bis and so I do see a possible problem, but only based on his characterization of the required processing, not based on any analysis I have performed. > c) It is not possible to use HIP and traditional > IPsec for the same packets. That is, one must > choose between "security" (ie traditional IPsec > and all the security configurations) and the > nice features offered by HIP. These are all your words, not mine, and so I will not respond to this begged question. (In case you are not familiar with the phrase begging the question, I refer you to the canonical example; "have you stopped beating your wife?") >If you are worried about point a), I don't know what >to say. Not everyone needs to have a managed security >mechanism, and they still want to move around. the term "managed security?" is vague and generally inaccurate in this context. What I assume you are referring to is access control. But, as I noted above, although access control is an intrinsic function of IPsec, the SPD can be configured to largely disable the function. However, a product that does not support the full access controls required in 2401/bis, is not IPsec compliant. >It sounded a bit like some people in the meeting were >worried about point c). Perhaps you were too. Let me >argue that we should not demand that much from the >protocols, HIP may not help you in *all* situations. >If you are running traditional IPsec, you should >stick to it. If you need mobility or multihoming in >that situation, perhaps you should re-establish your >SAs upon movements, or use MOBIKE. OK. >But I think the main issue that people should >pay attention to is point b). If I add the HIP feature >to my host, the VPN that I already have should not break. >If the administrator has configured a certain trusted peer >for some traffic, HIP should not open a hole for others to >send such traffic. However, this does not appear to be a >problem in HIP. Here's why: it is possible to implement >HIP in such a way that HIP operates still under the usual >IPsec policy rules, and the SPD gets to decide what is done >with each packet. (That's how the Ericsson Research >implementation works.) Fine. >There's one thing that a HIP-enabled implementation must be >able to do, and that is the selection of the right key >management protocol. For a given policy entry, the kernel >must be able to tell whether it should talk to the IKE daemon >or the HIP daemon. If we require this -- and that requirement >can be put in the HIP specifications -- the rest is easy. >HIP's policy entries can be put last in the policy data base, >meaning that the configured security always takes precedence. Sounds possible from an SPD management perspective. >I also think that HIP operates within the normal 2401 rules. >The only possible extension of 2401/2406 rules that I can see >is BEET mode, but that seems more like a separate component than >a core part of HIP. I can't tell what is the core part of HIP, so I can't comment on this observation. >In conclusion, provided that the HIP specifications >state the one additional requirement of allowing KMP selection, >I don't think there are any implications for traditional >IPsec usage. On the other hand, we also have to realize that >some people may want to implement HIP without implementing IPsec, >and just use ESP without the rest of IPsec. (That is how Andrew >McGregor's user level Python implementation works.) I'm not >sure whether that type of implementation can be made to work >with existing IPsec in the host. Then again, such implementations >should probably be targeted to situations where there is no >IPsec in the host at all yet. > If one wants to use ESP syntax outside of the 2401-defined semantics, then there is a possible problem because we would have the same ID assigned to what are really two different protocols, based on the different in semantics between HIP and IPsec, IF there is a real processing distinction. That is probably not acceptable in the IETF. Steve From jari.arkko@piuha.net Wed Nov 12 13:37:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Nov 12 13:37:01 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> Message-ID: <3FB2844A.7090200@piuha.net> Stephen Kent wrote: >> But let me first ask a clarification regarding your concerns. >> I am unsure which problem you had in mind: >> >> a) Opportunistic security is inherently bad, >> and you should not bring it to IPsec. > > > IPsec offers access control as an intrinsic feature. However, an admin > (e.g., a user for a single user host that employs Ipsec) is free to > configure the SPD to permit SA establishment with any peer, and to allow > any traffic to traverse such an SA. So, in the extreme, one can locally > choose to override the access control features of IPsec. Does this > match your definition of "opportunistic security?" If, so, then there is > no inherent conflict. I think that means roughly it, yes. >> c) It is not possible to use HIP and traditional >> IPsec for the same packets. That is, one must >> choose between "security" (ie traditional IPsec >> and all the security configurations) and the >> nice features offered by HIP. > > > These are all your words, not mine, and so I will not respond to this > begged question. (In case you are not familiar with the phrase begging > the question, I refer you to the canonical example; "have you stopped > beating your wife?") I'm sorry, I didn't mean it to be taken that way. I was just trying to contrast what is provided by the two things, and ask about the desire to get both at the same time. And yes, I should have had quotes on "nice features" too... >> If you are worried about point a), I don't know what >> to say. Not everyone needs to have a managed security >> mechanism, and they still want to move around. > > > the term "managed security?" is vague and generally inaccurate in this > context. What I assume you are referring to is access control. But, as I > noted above, although access control is an intrinsic function of IPsec, > the SPD can be configured to largely disable the function. However, a Right. > product that does not support the full access controls required in > 2401/bis, is not IPsec compliant. I agree. >> It sounded a bit like some people in the meeting were >> worried about point c). Perhaps you were too. Let me >> argue that we should not demand that much from the >> protocols, HIP may not help you in *all* situations. >> If you are running traditional IPsec, you should >> stick to it. If you need mobility or multihoming in >> that situation, perhaps you should re-establish your >> SAs upon movements, or use MOBIKE. > > > OK. Great! >> But I think the main issue that people should >> pay attention to is point b). If I add the HIP feature >> to my host, the VPN that I already have should not break. >> If the administrator has configured a certain trusted peer >> for some traffic, HIP should not open a hole for others to >> send such traffic. However, this does not appear to be a >> problem in HIP. Here's why: it is possible to implement >> HIP in such a way that HIP operates still under the usual >> IPsec policy rules, and the SPD gets to decide what is done >> with each packet. (That's how the Ericsson Research >> implementation works.) > > > Fine. > >> There's one thing that a HIP-enabled implementation must be >> able to do, and that is the selection of the right key >> management protocol. For a given policy entry, the kernel >> must be able to tell whether it should talk to the IKE daemon >> or the HIP daemon. If we require this -- and that requirement >> can be put in the HIP specifications -- the rest is easy. >> HIP's policy entries can be put last in the policy data base, >> meaning that the configured security always takes precedence. > > > Sounds possible from an SPD management perspective. Ok. Good. It looks like we agree on the basic technical requirement, then. >> In conclusion, provided that the HIP specifications >> state the one additional requirement of allowing KMP selection, >> I don't think there are any implications for traditional >> IPsec usage. On the other hand, we also have to realize that >> some people may want to implement HIP without implementing IPsec, >> and just use ESP without the rest of IPsec. (That is how Andrew >> McGregor's user level Python implementation works.) I'm not >> sure whether that type of implementation can be made to work >> with existing IPsec in the host. Then again, such implementations >> should probably be targeted to situations where there is no >> IPsec in the host at all yet. >> > > If one wants to use ESP syntax outside of the 2401-defined semantics, > then there is a possible problem because we would have the same ID > assigned to what are really two different protocols, based on the > different in semantics between HIP and IPsec, IF there is a real > processing distinction. I agree that a processing distinction could be problematic, but as Andrew noted in his e-mail, he believes that he can have co-existence of both and abide by the 2401 requirements in a future version. So perhaps this isn't a practical problem even for this type of HIP implementation. --Jari From andrew@indranet.co.nz Wed Nov 12 13:51:02 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Nov 12 13:51:02 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> Message-ID: <2310000.1068664946@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, November 12, 2003 12:08:09 PM -0500 Stephen Kent wrote: > At 15:45 +0200 11/12/03, Jari Arkko wrote: >> Stephen and Eric, >> >> In the HIP BOF you expressed a worry of how HIP and IPsec >> would work together, and whether there'd be some negative >> impacts to the correct operation of traditional IPsec if HIP >> were adopted. The purpose of this e-mail is to dwell a bit >> deeper into this subject and try to see if there is indeed >> a problem. My preliminary conclusion is that there is no >> problem. > > I did not say there was a problem per se. Pekka, in the HOP BOF, said > that he wanted to use ESP with HIP, but that the processing required did > not match that described in 2401, or what is likely to be in 2401bis. > Thus I noted that if HIP uses the ESP syntax, but does not follow the > processing model described in 2401/bis, then the result is not IPsec. > Pekka agreed with that characterization in the HIP BOF, but later seemed > to be uncomfortable when I repeated the same observation in the IPsec WG > meeting. There had been some conversations in the mean time. > One of Pekka's slides in the HIP BOF called for processing packets using > a mix of tunnel and transport mode features. this clearly conflicts with > 2401/bis and so I do see a possible problem, but only based on his > characterization of the required processing, not based on any analysis I > have performed. There is no reason to assume that HIP and any other KMP cannot coexist. Yes, the KMP implementations do need to have some feature to avoid SPI value collisions, and the SPD must support selection of the correct KMP for any flow, but these are almost trivial *and both are specified to be subject to local policy in IPsec*. Actually, BEET mode does not appear to conflict with the IPsec RFCs and drafts; see below. > If one wants to use ESP syntax outside of the 2401-defined semantics, > then there is a possible problem because we would have the same ID > assigned to what are really two different protocols, based on the > different in semantics between HIP and IPsec, IF there is a real > processing distinction. That is probably not acceptable in the IETF. > > Steve I can't find anything in BEET mode or HIP that is inconsistent with 2401, 2401bis, 2406 or the new ESP draft. These are remarkably silent on how to deal with the specific step in transport mode processing covered by the BEET draft, and one could regard BEET merely as a richer and more complete specification of transport mode. Note: transport mode. BEET is closer in semantics to transport mode, whatever the language in the draft. Current practice use of transport mode can be exactly duplicated by a BEET SA with a particular pseudoheader set in the SA. Extra processing steps will take place, but the result will be the same. IKE or IKEv2 running on a system with BEET would install that pseudoheader, and interoperate with non-BEET systems by so doing. HIP or MOBIKE could (indeed, must) use other pseudoheaders (MOBIKE only some of the time), but that is an issue for those KMPs. In other words, there does not seem to be a problem. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP7KIflGmVIGYWzvRAQHsMQQAlRtu6Gou7WyD93VbKYTrXvIB7bZAzkhC glsKw5KYsrr0ZBp7LjZZhlBiRxgqtwSeyRMwS06d37uNYtTpWByjLXr3J8SIMqT9 zKvewnZkv/2nK9XS5SC2H70yugS2FQf8BtFI25E4XD9bXiGCWO5pSKUkYzwcP3vq gwhPGgecs1I= =owXm -----END PGP SIGNATURE----- From kent@bbn.com Wed Nov 12 14:10:02 2003 From: kent@bbn.com (Stephen Kent) Date: Wed Nov 12 14:10:02 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3FB2844A.7090200@piuha.net> References: <3FB23987.90006@piuha.net> <3FB2844A.7090200@piuha.net> Message-ID: Jari, >>If one wants to use ESP syntax outside of the 2401-defined >>semantics, then there is a possible problem because we would have >>the same ID assigned to what are really two different protocols, >>based on the different in semantics between HIP and IPsec, IF there >>is a real processing distinction. > >I agree that a processing distinction could be problematic, but >as Andrew noted in his e-mail, he believes that he can have >co-existence of both and abide by the 2401 requirements in a >future version. So perhaps this isn't a practical problem >even for this type of HIP implementation. > >--Jari I think the preferable approach here is to describe how processing for traffic on a HIP-based SA differs from what 2401bis requires for an IKE-based or manually configured SA, if there is a difference. If we can describe the processing, then we will know if there is a difference, as has been suggested. This is a more satisfying approach, for me, rather than the existence of an implementation that appears to be able to handle both. After all, the output of IETF WGs are standards, not implementations. Steve From jari.arkko@piuha.net Wed Nov 12 14:11:00 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Nov 12 14:11:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> <3FB2844A.7090200@piuha.net> Message-ID: <3FB28C29.9040104@piuha.net> Steve, > I think the preferable approach here is to describe how processing for > traffic on a HIP-based SA differs from what 2401bis requires for an > IKE-based or manually configured SA, if there is a difference. If we can > describe the processing, then we will know if there is a difference, as > has been suggested. This is a more satisfying approach, for me, rather > than the existence of an implementation that appears to be able to > handle both. After all, the output of IETF WGs are standards, not > implementations. That makes sense. (Perhaps two different descriptions, one for HIP and one for BEET.) --Jari From pekka.nikander@nomadiclab.com Wed Nov 12 14:21:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 12 14:21:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> Message-ID: <3FB28F78.8070003@nomadiclab.com> Stephen, It looks like that I get very often confused when I talk to you. My current, perhaps faulty understanding of this phenomenon is that apparently we are having very different assumptions of what is "security" or "IPsec" or a number of other key terms. (I do not imply that my understanding of the terms is right; on the contary, my understanding is probably quite flawed. I am just noting that your and mine understanding of the terms seem to be different, and therefore I quite often get confused). Now, due to that confusion I apparently enter a very defensive mode while speaking with you, especially publicly, and consequently sometimes expressing my thoughts in a way that can be very easily misunderstood. Secondly, since English is not my native tongue, I am most probably missing lots of nuances of what different everyday terms mean, and therefore use language that may appear to be very very sloppy from your point of view. With these caveats, I'd like to to express some concerns about the discussion that took place at the BOF. > ... Pekka, in the HOP BOF, said > that he wanted to use ESP with HIP, but that the processing required did > not match that described in 2401, or what is likely to be in 2401bis. The processing that is required by HIP does not need rfc2401 or 2401bis. Specifically, the current HIP processing model implements only a small fraction of the 2401/bis policy model. Hence, the HIP processing model does not match 2401/bis in the sense that it is only a small subset. Another issue is that it is very easy to implement the HIP processing model with an 2401 compliant IPsec policy engine. Indeed, that is what we have done. We control the HIP ESP usage with a plain, vanilla unmodified IPsec policy engine as implemented in KAME. As far as I understood, what Jari tried to argue is that it is possible to create 2401/bis compatible policies that allow HIP and IPsec to co-exist in a single host. Since I am not an expert in 2401/bis, I can't really say whether that is true or not, but I have no reason to doubt what Jari says. > Thus I noted that if HIP uses the ESP syntax, but does not follow the > processing model described in 2401/bis, then the result is not IPsec. And I agreed with you, under my perhaps misled understanding that the term "IPsec" implies implementing *all* of 2401/bis processing model, including all selectors, which HIP does not require (or support). On the other hand, there does not seem to be anything that prevents HIP and IPsec from co-existing in a single machine and sharing a single 2401/bis conformant policy engine. > Pekka agreed with that characterization in the HIP BOF, but later seemed > to be uncomfortable when I repeated the same observation in the IPsec WG > meeting. Quite a lot depends on what you mean with IPsec, and I have to admit that I still don't quite understand how you define IPsec, exactly. An observation that I tried to make at the IPsec WG is that, to me, it looks like that not everybody even in the IPsec WG agree with your definition of IPsec. > One of Pekka's slides in the HIP BOF called for processing packets using > a mix of tunnel and transport mode features. This clearly conflicts with > 2401/bis and so I do see a possible problem, but only based on his > characterization of the required processing, not based on any analysis I > have performed. As I have dicussed in length in the BEET draft, that processing can be implemented as a part of the ESP SA processing (as we have done), or it can be implemented separately. There are a number of security and implementation level benefits from integrating the functions jointly at the SA, but there is no inherent reason why the HIT <-> IP translation cannot be implemented separately. This is all discussed in the BEET draft, partially thanks to the critisism that you offered on the initial BEET ideas at San Francisco IETF. > If one wants to use ESP syntax outside of the 2401-defined semantics, > then there is a possible problem because we would have the same ID > assigned to what are really two different protocols, based on the > different in semantics between HIP and IPsec, IF there is a real > processing distinction. That is probably not acceptable in the IETF. I don't see here any real difficulty for anything but perhaps firewalls that want to control ESP usage. That case is being discussed in the HIP architecture draft. It appears that the current HIP protocol design allows an HIP and ESP aware firewall to have much stricter control on ESP use than a firewall who must rely on IKE exchanges. If there are other concerns which make these two usages so different that they create a potential issue, I really would like to hear the specifics of those concerns. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Nov 12 14:43:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 12 14:43:00 2003 Subject: [Hipsec] Please check for correctness: transcription of HIP BOF discussions Message-ID: <3FB2943F.70207@nomadiclab.com> This is a multi-part message in MIME format. --------------000900090405020100090605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please find enclosed a draft for the transcription of the HIP BOF discussions on Monday. Many thanks to Spencer Dawkins, John Colins and Eva Gustafsson, whose notes the transcript is based on. PLEASE CHECK that what I have written down matches with what you intended to say. If there is anything that you want to change, please let me know as soon as possible, preferably before the end of this week. It would be nice if you could acknowledge that you have checked your sayings even if there is nothing to correct. There is also a few unidentifier speakers. If you recognize who they most probably have been, please let me know and I will try to contact them. If somebody can forward this to Nico Williams, Tom Petch, and Melinda Shore, please do so, since I don't have their e-mail addresses. Once I have an accurate transcript, I will produce a set of minutes that summarize the discussion. --Pekka Nikander --------------000900090405020100090605 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="discussion.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="discussion.txt" Pekka did a nice overview of HIP. He pointed out that HIP doesn't map cleanly into any IETF area, but it could become the next "waist" of the IP protocol stack. HIP uses ESP in transport mode, has a four-way handshake for association setup, and is DoS-resistent - R1 packet is cryptographic, but is precomputed. Pekka also pointed out that the mobility/multihoming drafts are much less mature than the base protoco spec, etc. Keith Moore: HIP is nice, but being oversold. It has a lot of brilliant ideas, but it doesn't solve all of the claimed problems, it helps to solve them. You need to clarify what HIP does & doesn't. Pekka Nikander: I agree. I don't remember what I said during the talk, but if I said that HIP "solves" the problems, it was wrong. HIP provides mechanisms to solve these problems, but as it stands now, it does not "completely" solve the problems. Jim Bound: Too much overlap between protocol specification and implementation description in the documents - this needs to be removed before entry into standards track. How to rebuild our stacks it not your business. What do you want in terms of standards? Pekka Nikander: We have been trying to move implementation level issues to appendices. It is well possible that not all has been moved. If there are still sections that talk too much about implementation, they need to be moved to an appendix, too. (Nods from ADs) David Ward: Please note, too, that the architecture document is headed towards informational RFC, and informational documents may discuss implementation issues. Erik Nordmark: Do we know about claimed IPRs on this? Pekka Nikander: We don't know for sure. There may be IPR claimed on the puzzle. However, given how the current puzzle implementation is, my personal belief is that there shouldn't be any. It is also possible that there are IPRs on the Diffie-Hellman MODP groups, but based on discussions at the IPsec WG it does not seem to be a problem. Eric Fleischman: Bob Moscowitz says he won't patent his contributions. Neither does Boeing. Bill Sommerfeld: Given my understanding of the patent law, it isn't sufficient to say there are no IPR claims. Eric Fleischman: All I am saying is that Bob Moskowitz does not have any IPR on this. Margaret Wasserman: If this becomes a working group, we need to look at the IPR issues then. Perry Metzger: Why WG for experimental documents? What is the policy for experimental documents? Thomas Narten: Currently the IPR requirements are for standards-track documents, not experimental. However, there are new policies in the IETF with respect to IPR and experimental track documents. Hence, the IPR status need to be declared for all documents. David Ward: We clearly need to investigate whethere there are IPRs or not. Eric Rescola: How does HIP play with IPsec? Is the assumption that you want to use IKE and IPsec over the top of HIP? Andrew McGregor: Well, you could do both, but then you would end up encryptiong twice. Or, you could HIP to establish some SAs and IKE to other ones. Depending on implementation, you could use policies to control this. Niko Williams: Does server need to do public key operations before reverse routability verification? What is the computational load on server? How about DNSsec or certificates? Pekka Nikander: From our point of view, I would say that HIP is not so much of IPsec. Bob Moskowitz assumed that people would be doing ESP anyway, so the default is to use ESP. However, architecturally HIP could be implemented without any IPSec at all. The exact way of doing that is just not specified as of now. What comes to return routability and server load, the R1 packet is precomputed. Hence, the server isn't vulnerable to DoS attacks at that point. We deliberately left DNSsec and certificates out of the scope for now. They were there before, but their usage depends so much on what do you want to use HIP for that it is better to scope them out. (?): Have you tested mobility and renumbering? Pekka Nikander: Yes, there will be demo of this in a few minutes. Steve Kent: This is a solution looking for a problem. IPsec is much more than just ESP. Hence, you're not doing IPSec, you're just doing ESP. Pekka Nikander: You can say that we are not doing IPsec but only ESP if you want to express it in that way. What coems to the problem, there seems to be a need to separate identifiers from IP addresses. This is one possible answer to that problem, and we need to understand better the properties of this. Steve Kent: A solution must fit within prespecified constraints, and I have haven't heard any of such constraings. Perry Metzger: Don't break a butterfly on the wheel. This is an experiment. We need more of them. I think this is a great idea. For once we have a bunch of people going out doing something that may not provide all answers at once. Eric Fleischman: We tried doing requirements first last time; that's why we're not a WG now! Keith Moore: It is more correct to say that identifier/location combination is a design compromise, not merely wrong. Steve Kent: A question to the ADs. If the intent is to create an experimental group, why is this being proposed for IETF, why not IRTF? Thomas Narten: IRTF is research, IETF is engineering. We are trying to engineer bits on the wire. Steve Kent: For what I have heard, we want to play with this until we know what it's good for. Engineering is about solving problems, not playing with something to see if it's useful. Margaret Wasserman: In materials engineering, you may have a new material and it is still engineering to see whether it best fits a problem. We do know some of the problems we are working on. We already have implementations. The idea is to see how this fits within the rest of the system This isn't strictly an experiment. Pekka Nikander cut the discussion short to continue with the agenda. 20 min Demo of current implementations Demo team ========================================================== - HIP base exchange - HIP mobility between IPv4 and IPv6 - HIP based IPv4/IPv6 API bridging Keith Moore: I want to point out that this is not so wonderful as it might seem. It doesn't live up to the claims being made for HIP. What if both sides move at once? I challenge you to work with both hosts moving concurrently, to create a demo that shows that this is a practical solution, not a toy. Jeff Ahrenholtz(?): This is experimental, this isn't complete. Keith Moore: So there are still probably issues that need to be looked at. This is interesting technology but not complete. David Ward: Of course. That is why we want to do a WG on this. We just want to avoid working in the dark. (Other presentations) * 50 min Charter discussion All ====================================================== Tim Shepard: I attended the earlier HIP BOFs. Very soon after the second HIP BOF, I was not in favour of forming a HIP WG. Today, I use SSH instead of IPsec as my VPN solution. SSH was a protocol solving an as yet not understood problem. I hope that HIP does get there. If we look at engineering in the world, there _are_ a lot of things that are done bottom up, and that is wonderful. I hope that the development of HIP can proceed like this, and I am not convinced that an IETF WG can help. I am not sure that bringing HIP to the IETF is the right thing. If SSH had been brought into the IETF in the beginning, it might not be as valuable as it is today. I'm not actually sure what is the correct thing. I am ambivalent. James Kempf: You should get rid of the proposed charter items 9 & 10 (Implementation report & MIB), they are standardization items and shouldn't be part of experimental. I think that the biggest problem is the rendezvous server. There are other proposals around for separating identifiers and locations without cryptographic keys. They need to be also considered. We need to understand if a cryptographic name space has any additional value. David Ward: The intention of putting up an implementation report is to separate implementation techniques from the specification. Erik Nordmark: It is good to continue to explore HIP, and a WG is a good way to do this. One is issue is IPv4 by itself, other concern is NAT. It is operationally hard to make a robust solution as all NAT implementations are different. That may make it hard to focus. Pekka Nikander: There are two approaches to the NAT problem. One is to base the solution on existing mechanisms, meaning UDP encapsulation. The other is to enhance NATs, i.e., to teach NATs to understand HIP. The current thinking is in the favour of the latter. Keith Moore: This is bottom-up architecture. That's the wrong way to do architecture. We need top-down architecture before we deploy widely. The search mechanism (Charter item 7) isn't optional, it's critical. I would make it number 1 on the list. Need to look at wide range of interactions, for example, MTU changes when we move from v4 to v6. Probably need to do base spec last, including what we've learned from working on other specs. Pekka Nikander: The current plan is to complete the base spec first, then get operational experience, and then revise the base spec if needed. Perry Metzger: SSH was widely deployed before coming to IETF - the IETF value-add was SSHv2. The protocol originally had some serious flaws. HIP could be the same way. It is important for HIP to be brought to the IETF. It needs the exposure to a wide number of people so that it gains from the exposure and the protocol is improved. We need to give the WG a chance to come up with HIPv2. Bob Hinden: A WG for Experimental docs just seems wrong, wrt. IESG overload. The deliverables look like charter items for standards-track documents - no cycles included. I would like to see something that shows what is the result of the experiment. Eric Fleishman: We need to add the v4/v6 transition mechanisms to charter list. In general, the IETF doesn't do architecture well and architecutral work is less appreciated. This is architecture, but other people are starting to solve the same problem in piecemeal fashion - even worse than us! I value HIP as giving the IETF a possibly more architecturally complete solution than the more piecemal approaches elsewhere. HIP is giving the to IETF a possibility to consider a broader architectural solution. Melinda Shore: The concept of exploratory WGs is under discussion (Ted Hardie draft, etc). This would fit in there. NAT traversal is actually several problems that have never been decomposed appropriately at IETF, and name spaces is only one of them. Expect problems with directory, reachability, etc. Making NAT HIP aware do not solve these problems. Harald Alvestrand: If the IESG is overworked, then chartering or not chartering HIP not going to change that. HIP won't break IESG's back, and it could help IETF later. Decide if this experiment is in the best interest of the Internet; in my opinion it is. If so, we'll need to make it happen. Spencer Dawkins: APPS view of HIP is needed soon, to avoid late suprises. We want to have the applications guideline in the charter. Gabriel Montenegro: I would like to speak in favour of the WG, but the charter obviously needs some more hacking. Items 6 & 7 (rendezvous and proxy servers & search mechanism) need more work and may be better done in research. Personally, I would not worry about modifying NAT boxes but just assume they are there and workaround them. My advice is to also create an IRTF research group to have a look at some of the issues. At the working group side, should also be a document as a guidline of how to join the experiment. Erik Nordmark: Should IKE interactions be considered? Pekka Nikander: I am not sure. We have the MOBIKE BoF later, and it addresses some (but not all) of the issues from the IKE point of view. Erik Nordmark: But what if you use ESP, use HIP to rehome your packets, and simultaneously want to use IKE instead of HIP to create the security associations? David Ward: If this becomes a working group, we apparently need to address this issue. Elliott Lear: The NSRG research group at the IRTF didn't get far in this space. Perhaps the charter should be expanded to include MAST, NOID, etc? It also seems like some charter areas aren't individual work items - they are too broad. Tony Hain: Ignore NAT traversal unless you're doing IPv6. Look at infrastructure problems - that's the hard part - DNS, proxies, rendezvouz servers, etc. They are what needs experimentation. Lots of work fails because of infrastructure issues. Tom Petch: To the naive, it looks like the DNS is the crux of the problem. DNS is right answer but is perceived as useless to solve this problem. We need to bite this bullet now. Steve Kent: You need to do a list of problems right up front. Work item number zero should be a list of problems you are tackling. Are you doing experiments or testing? Margaret Wasserman: The current identity/locator overlap is a property of IP addresses, not inherently evil. We need a scalable way of life after the split. Don't throw all the experiments in a room and expect them to work things out. Apparently we will eventually need something like the DHTs to be able to look up identifiers. Erik Nordmark: There are overlapping conversations, and we need them. It is good to have these guys in one room. Spencer Dawkins: Yes, but don't put them all in THIS room - HIP is focused and already underway. Margaret Wasserman: We're trying to build a taller tower. We don't do that by putting everything in one tower and hoping it fits and turns out to be taller. In other words, we should not be put everything in the same room and expect to get a good outcome. Thomas Narten: Why a working group now? Pekka Nikander: We have been working on the base protocol for last two years. It would now really benefit from a wider review. Additionally, we need to focus on the infrastructure requirements, and we don't have that expertise in the current HIP community. Creating a working group is one way to get a wider review and invite people with wider experience to take part. David Ward: We have reached the point where the initial work has uncovered some interesting problems and potential paths. We need to finalize the specs we are working ong, and build interoperable solutions. Pekka Nikander: We need a widely implemented experimentation to get operational experience. Thomas Narten: HIP requires upgrades at both ends of an association. Is this deployable? Is it deployable from the experimental work point of view? How about longer term look, as a wider solution? We need to consider these at the working group, if one is formed. David Ward: There is no need for a Internet flag day for HIP, of course. Thomas Narten: Can you prioritize charter items? John Loughney: Everything beyond base spec is moving beyond experiment. Need a crisp charter for experiments. NAT traversal, for example, not needed for experiments. Pekka Nikander: Yes, we need to prioritize, but the base spec is not quite enough. John Loughney: Ok, "Core set of what's needed" may be more than the base spec alone. Thomas Narten: The suggestion of "DNS interaction" too vague. Speaking about using HIP to dynamically update DNS, we need to check with the DNS WG. Spencer Dawkins: Items needing wider community review can be mentioned in the charter without being chartered deliverables at this time. Tim Shephard: What is the "minimal set?" Probably first three proposed items, plus a report on what the experiment taught us. Wait a year to add more deliverables - this is realistic. Keith Moore: How can "minimal set" not be already done, if you have interoperating implementations now? I am concernted that if you exclude important isssues, you need to work on all aspects together. Bill Sommerfeld: Is this technology incrementally deployable? If not, what changes does it need? You can't boil the ocean. Margaret Wasserman: But IPv6 isn't incrementally deployable, either. Before we can have a question of incremental deployability, we need to decide what what we are talking about. (The discussion came to end.) 10 min Summary and next steps Chairs ======================================================= The chairs posed a number of questions: A. Is this an interesting technical problem to pursue in the IETF? ------------------------------------------------------------------ room hands were "yes". B. Do we have enough of additional people that would participate? ----------------------------------------------------------------- B.1. Security? 3 hands raised (Bill Sommerfeld, Perry Metzger, unidentified) -------------- B.2. DNS? no hands, but --------- Randy Bush: The needed DNS RR is trivial. Thomas Narten: Need to get help from DNS WG. B.3. Applications: No hands, but the appsarea meeting was taking place ------------------ at the same time. B.4. Routing? 3 or 4 hands, depending what "HIP and routing means" ------------ Thomas Narten: What do you mean with routing? Margaret Wasserman: I asked the chairs to ask these questions, so that we get some cross area expertise. C. Do we have enough information to decide about a WG? ------------------------------------------------------ Randy Bush: I am trying to understand how this relates to the work out of multi6. I am not sure I understand the space yet, and what we can achieve here with a separate working group, and whether it would be useful? (?): The deployment piece that needs work is the secure updating of the infrastructure. Keith Moore: I think that it is unfortunate that the applications people are not here. They are the people who need broader view to finalise the charter. Margaret Wasserman: All WG proposals get sent out for two weeks anyway. The room hands was "yes", we do have enough of information. D. Should we have a working group? ---------------------------------- Randy Bush: How this relates to NOID. Margaret Wasserman: We need to identify willingness to work here. David Ward: We have managed to bash the charter so much that we need to have a charter discussion at the list anyway. Tony Hain: My concern is that some of the key pieces of the problem (infrastructure) have no volunteers. The room hands were "yes", based on successful charter discussions. --------------000900090405020100090605-- From kent@bbn.com Wed Nov 12 14:44:01 2003 From: kent@bbn.com (Stephen Kent) Date: Wed Nov 12 14:44:01 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <2310000.1068664946@ijir> References: <3FB23987.90006@piuha.net> <2310000.1068664946@ijir> Message-ID: > >Actually, BEET mode does not appear to conflict with the IPsec RFCs and >drafts; see below. > >> If one wants to use ESP syntax outside of the 2401-defined semantics, >> then there is a possible problem because we would have the same ID >> assigned to what are really two different protocols, based on the >> different in semantics between HIP and IPsec, IF there is a real >> processing distinction. That is probably not acceptable in the IETF. >> >> Steve > >I can't find anything in BEET mode or HIP that is inconsistent with 2401, >2401bis, 2406 or the new ESP draft. These are remarkably silent on how to >deal with the specific step in transport mode processing covered by the >BEET draft, and one could regard BEET merely as a richer and more complete >specification of transport mode. Note: transport mode. BEET is closer in >semantics to transport mode, whatever the language in the draft. 2401 and 2401bis are the definitive descriptions for how transport mode processing is performed, so I am very suspicious of this assertion :-) >Current practice use of transport mode can be exactly duplicated by a BEET >SA with a particular pseudoheader set in the SA. Extra processing steps >will take place, but the result will be the same. IKE or IKEv2 running on >a system with BEET would install that pseudoheader, and interoperate with >non-BEET systems by so doing. HIP or MOBIKE could (indeed, must) use other >pseudoheaders (MOBIKE only some of the time), but that is an issue for >those KMPs. if extra processing steps take place within the IPsec boundary, then this is a change to IPsec (to accommodate HIP functionality). if the steps take place outside the boundary, then it is not a change to IPsec. In the latter case, the offered security services may differ, but that's not unique to HIP. For example, if one chooses to employ IP-in-IP tunneling before submitting a packet to IPsec, then one gives up the opportunity to perform access control at fine granularity, because IPsec is not going to look at the transport layer protocol that is now buried in the tunneled packet that was handed to it. Steve From andrew@indranet.co.nz Wed Nov 12 15:45:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Nov 12 15:45:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> <2310000.1068664946@ijir> Message-ID: <2740000.1068671770@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, November 12, 2003 03:11:58 PM -0500 Stephen Kent wrote: >> >> Actually, BEET mode does not appear to conflict with the IPsec RFCs and >> drafts; see below. >> >>> If one wants to use ESP syntax outside of the 2401-defined semantics, >>> then there is a possible problem because we would have the same ID >>> assigned to what are really two different protocols, based on the >>> different in semantics between HIP and IPsec, IF there is a real >>> processing distinction. That is probably not acceptable in the IETF. >>> >>> Steve >> >> I can't find anything in BEET mode or HIP that is inconsistent with 2401, >> 2401bis, 2406 or the new ESP draft. These are remarkably silent on how >> to deal with the specific step in transport mode processing covered by >> the BEET draft, and one could regard BEET merely as a richer and more >> complete specification of transport mode. Note: transport mode. BEET >> is closer in semantics to transport mode, whatever the language in the >> draft. > > 2401 and 2401bis are the definitive descriptions for how transport mode > processing is performed, so I am very suspicious of this assertion :-) I was surprised, but 2401/bis are silent about the content of the pseudoheader used by upper layers to calculate their checksums, and also about the apparent addresses seen by upper layers (the latter is less surprising). This is how BEET differs, where it comes down to it. I presume the idea is to merely insert the ESP header and transform the tail of the packet, in which case the pseudoheader has standard content, but *it is not specified in 2401/bis*. Therefore, although the obvious place to store the variables is the SA, and although this happens in the IPsec packet processing path in some implementations, BEET requires no changes to 2401/bis. >> Current practice use of transport mode can be exactly duplicated by a >> BEET SA with a particular pseudoheader set in the SA. Extra processing >> steps will take place, but the result will be the same. IKE or IKEv2 >> running on a system with BEET would install that pseudoheader, and >> interoperate with non-BEET systems by so doing. HIP or MOBIKE could >> (indeed, must) use other pseudoheaders (MOBIKE only some of the time), >> but that is an issue for those KMPs. > > if extra processing steps take place within the IPsec boundary, then this > is a change to IPsec (to accommodate HIP functionality). if the steps > take place outside the boundary, then it is not a change to IPsec. In the > latter case, the offered security services may differ, but that's not > unique to HIP. For example, if one chooses to employ IP-in-IP tunneling > before submitting a packet to IPsec, then one gives up the opportunity to > perform access control at fine granularity, because IPsec is not going to > look at the transport layer protocol that is now buried in the tunneled > packet that was handed to it. > > Steve Agreed. It appears to be a matter of opinion where these steps take place, since the HIP implementations can do it in the socket API, in something akin to a NAT module and in the ESP processing. All three have been implemented, and interoperate. Clearly two of those are outside of IPsec. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP7KjJlGmVIGYWzvRAQEhkwP9HsP0IQoFsLlZfOnuUPKxPOFkOmz5PY3t egPeFadsykZT3ELC1Yau+LAGKNSGRSLmrcC9+mRrabvZ8by4PVKIwv2AwKuoSTNL sewnbLr1Ev5zvKosUUj0qvq9F3GW2BnuD4tZt1kZ4SgiM3Rux67VPjvrBbSaDLtJ 1q3Vu5ls2JI= =smU5 -----END PGP SIGNATURE----- From kent@bbn.com Wed Nov 12 16:52:01 2003 From: kent@bbn.com (Stephen Kent) Date: Wed Nov 12 16:52:01 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <2740000.1068671770@ijir> References: <3FB23987.90006@piuha.net> <2310000.1068664946@ijir> <2740000.1068671770@ijir> Message-ID: At 10:16 +1300 11/13/03, Andrew McGregor wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > >- --On Wednesday, November 12, 2003 03:11:58 PM -0500 Stephen Kent > wrote: > >>> >>> Actually, BEET mode does not appear to conflict with the IPsec RFCs and >>> drafts; see below. >>> >>>> If one wants to use ESP syntax outside of the 2401-defined semantics, >>>> then there is a possible problem because we would have the same ID >>>> assigned to what are really two different protocols, based on the >>>> different in semantics between HIP and IPsec, IF there is a real >>>> processing distinction. That is probably not acceptable in the IETF. >>>> >>>> Steve >>> >>> I can't find anything in BEET mode or HIP that is inconsistent with 2401, >>> 2401bis, 2406 or the new ESP draft. These are remarkably silent on how >>> to deal with the specific step in transport mode processing covered by >>> the BEET draft, and one could regard BEET merely as a richer and more >>> complete specification of transport mode. Note: transport mode. BEET >>> is closer in semantics to transport mode, whatever the language in the >>> draft. >> >> 2401 and 2401bis are the definitive descriptions for how transport mode >> processing is performed, so I am very suspicious of this assertion :-) > >I was surprised, but 2401/bis are silent about the content of the >pseudoheader used by upper layers to calculate their checksums, and also >about the apparent addresses seen by upper layers (the latter is less >surprising). This is how BEET differs, where it comes down to it. IPsec does not see a pseudo header, in general. Remember, many IPsec implementations are in security gateways or BITW implementations. These implementations see packets with real headers, not pseudo headers. So, in order to provide a uniform description of IPsec processing, we always express it in terms of receiving a packet with an IP header, that otherwise could just be sent to a layer 2 interface. That's why there is no reference to pseudo headers in IPsec. It is not an oversight, it is an intentional choice of the interface defined for IPsec. >I presume the idea is to merely insert the ESP header and transform the >tail of the packet, in which case the pseudoheader has standard content, >but *it is not specified in 2401/bis*. Therefore, although the obvious >place to store the variables is the SA, and although this happens in the >IPsec packet processing path in some implementations, BEET requires no >changes to 2401/bis. see comments about why any reference to a pseudo header is inappropriate in this context. > >>> Current practice use of transport mode can be exactly duplicated by a >>> BEET SA with a particular pseudoheader set in the SA. Extra processing >>> steps will take place, but the result will be the same. IKE or IKEv2 >>> running on a system with BEET would install that pseudoheader, and >>> interoperate with non-BEET systems by so doing. HIP or MOBIKE could >>> (indeed, must) use other pseudoheaders (MOBIKE only some of the time), >>> but that is an issue for those KMPs. >> >> if extra processing steps take place within the IPsec boundary, then this >> is a change to IPsec (to accommodate HIP functionality). if the steps >> take place outside the boundary, then it is not a change to IPsec. In the >> latter case, the offered security services may differ, but that's not >> unique to HIP. For example, if one chooses to employ IP-in-IP tunneling >> before submitting a packet to IPsec, then one gives up the opportunity to >> perform access control at fine granularity, because IPsec is not going to >> look at the transport layer protocol that is now buried in the tunneled >> packet that was handed to it. >> >> Steve > >Agreed. It appears to be a matter of opinion where these steps take place, >since the HIP implementations can do it in the socket API, in something >akin to a NAT module and in the ESP processing. All three have been >implemented, and interoperate. Clearly two of those are outside of IPsec. Consider the comments above re what the interface is to IPsec, then decide where HIP fits. Steve From kent@bbn.com Wed Nov 12 16:52:04 2003 From: kent@bbn.com (Stephen Kent) Date: Wed Nov 12 16:52:04 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3FB28F78.8070003@nomadiclab.com> References: <3FB23987.90006@piuha.net> <3FB28F78.8070003@nomadiclab.com> Message-ID: At 13:52 -0600 11/12/03, Pekka Nikander wrote: >Stephen, > >It looks like that I get very often confused when I talk to you. >My current, perhaps faulty understanding of this phenomenon is >that apparently we are having very different assumptions of what >is "security" or "IPsec" or a number of other key terms. (I do >not imply that my understanding of the terms is right; on the >contary, my understanding is probably quite flawed. I am just >noting that your and mine understanding of the terms seem to be >different, and therefore I quite often get confused). > >Now, due to that confusion I apparently enter a very defensive mode >while speaking with you, especially publicly, and consequently >sometimes expressing my thoughts in a way that can be very easily >misunderstood. Secondly, since English is not my native tongue, >I am most probably missing lots of nuances of what different everyday >terms mean, and therefore use language that may appear to be very >very sloppy from your point of view. > >With these caveats, I'd like to to express some concerns about >the discussion that took place at the BOF. Pekka, I appreciate the fact that you are not a native speaker of English, and since you speak much better Engligh that I do Finnish, I can't complain on that basis. I, more than most folks, place a great deal of emphasis on trying to be precise in writing and speaking, since that helps avoid confusion. I assure you that I criticize many native English speakers for being inarticulate in technical matters. I do so because ultimately, such imprecision in communication wastes everyone time, leads to unnecessary confusion, etc. So, please don't feel that I am picking on you, personally, when I am critical of communication problems. > >>... Pekka, in the HOP BOF, said that he wanted to use ESP with HIP, >>but that the processing required did not match that described in >>2401, or what is likely to be in 2401bis. > >The processing that is required by HIP does not need rfc2401 or >2401bis. Specifically, the current HIP processing model implements >only a small fraction of the 2401/bis policy model. Hence, the HIP >processing model does not match 2401/bis in the sense that it is only >a small subset. OK, that's seems like a clear statement. But, the implication is that ESP, when used in this context, is not the same protocol as when used in the IPsec context. Since a protocol is not just syntax, but also the processing performed prior to transmission and after reception, I think this is a fair statement. >Another issue is that it is very easy to implement the HIP processing >model with an 2401 compliant IPsec policy engine. Indeed, that is >what we have done. We control the HIP ESP usage with a plain, vanilla >unmodified IPsec policy engine as implemented in KAME. I don't know how to interpret this statement. >As far as I understood, what Jari tried to argue is that it is possible >to create 2401/bis compatible policies that allow HIP and IPsec to >co-exist in a single host. Since I am not an expert in 2401/bis, >I can't really say whether that is true or not, but I have no reason >to doubt what Jari says. Again, I have some problem interpreting this. What Jari said is that if one wants to employ HIP and make sure that it does not cause security problems by overriding the (presumably more restrictive) access control policies typically associated with IPsec use, then one can put the SPD entries that refer to HIP traffic at the end of the SPD. That mechanistic description of co-existence does not answer the question of whether use of ESP syntax with HIP is different from ESP with IPsec. > >>Thus I noted that if HIP uses the ESP syntax, but does not follow >>the processing model described in 2401/bis, then the result is not >>IPsec. > >And I agreed with you, under my perhaps misled understanding that >the term "IPsec" implies implementing *all* of 2401/bis processing >model, including all selectors, which HIP does not require (or support). The term IPsec DOES imply compliance with ALL of the 2401.bis processing. You were wight. >On the other hand, there does not seem to be anything that prevents >HIP and IPsec from co-existing in a single machine and sharing a >single 2401/bis conformant policy engine. If by policy engine your mean SPD, that may be true. That may be an interesting capability, but it does not address the question of whether ESP-HIP and ESP-IPsec are the same protocol, which is what I think we are discussing right now. > >>Pekka agreed with that characterization in the HIP BOF, but later >>seemed to be uncomfortable when I repeated the same observation in >>the IPsec WG meeting. > >Quite a lot depends on what you mean with IPsec, and I have to admit >that I still don't quite understand how you define IPsec, exactly. >An observation that I tried to make at the IPsec WG is that, to me, >it looks like that not everybody even in the IPsec WG agree with >your definition of IPsec. RFC 2401 is the IPsec architecture document. It defines what IPsec is. The protocols AH and ESP are used by IPsec to provide certain secruity services. However, because there is considerable overlap in how one processes AH and ESP, we chose to not define all of these protocol in the RFCs that describe the syntax of each. Rather, we put the common processing in 2401. Thus, one ought not talk about implementing ESP outside of the IPsec context defined by 2401. Note that there are pointers in AH and ESP to 2401, indicating that these protocols are not completely described in the individual RFCs. >>One of Pekka's slides in the HIP BOF called for processing packets >>using a mix of tunnel and transport mode features. This clearly >>conflicts with 2401/bis and so I do see a possible problem, but >>only based on his characterization of the required processing, not >>based on any analysis I have performed. > >As I have dicussed in length in the BEET draft, that processing can >be implemented as a part of the ESP SA processing (as we have done), >or it can be implemented separately. There are a number of security >and implementation level benefits from integrating the functions >jointly at the SA, but there is no inherent reason why the HIT <-> IP >translation cannot be implemented separately. This is all discussed >in the BEET draft, partially thanks to the critisism that you offered >on the initial BEET ideas at San Francisco IETF. If you have to change ANY code in an IPsec implementation to support HIP, then its not IPsec anymore. If you can implement the requisite processing before the packet is handed to IPsec, then no problem. >>If one wants to use ESP syntax outside of the 2401-defined >>semantics, then there is a possible problem because we would have >>the same ID assigned to what are really two different protocols, >>based on the different in semantics between HIP and IPsec, IF there >>is a real processing distinction. That is probably not acceptable >>in the IETF. > >I don't see here any real difficulty for anything but perhaps >firewalls that want to control ESP usage. That case is being >discussed in the HIP architecture draft. It appears that the >current HIP protocol design allows an HIP and ESP aware firewall >to have much stricter control on ESP use than a firewall who >must rely on IKE exchanges. > >If there are other concerns which make these two usages so >different that they create a potential issue, I really would like >to hear the specifics of those concerns. I have not explored specific ramifications of having two different protocols that share the same protocol number, but I am comfortable saying that the IETF does not endorse such use. So, that's why we need to decide whether ESP is different in any way when used with HIP vs. IPsec. Steve From andrew@indranet.co.nz Wed Nov 12 20:16:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Nov 12 20:16:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> <3FB28F78.8070003@nomadiclab.com> Message-ID: <2640000.1068688011@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, November 12, 2003 05:04:41 PM -0500 Stephen Kent wrote: > At 13:52 -0600 11/12/03, Pekka Nikander wrote: >> Stephen, >>> ... Pekka, in the HOP BOF, said that he wanted to use ESP with HIP, >>> but that the processing required did not match that described in >>> 2401, or what is likely to be in 2401bis. >> >> The processing that is required by HIP does not need rfc2401 or >> 2401bis. Specifically, the current HIP processing model implements >> only a small fraction of the 2401/bis policy model. Hence, the HIP >> processing model does not match 2401/bis in the sense that it is only >> a small subset. > > OK, that's seems like a clear statement. But, the implication is that > ESP, when used in this context, is not the same protocol as when used in > the IPsec context. Since a protocol is not just syntax, but also the > processing performed prior to transmission and after reception, I think > this is a fair statement. > >> Another issue is that it is very easy to implement the HIP processing >> model with an 2401 compliant IPsec policy engine. Indeed, that is >> what we have done. We control the HIP ESP usage with a plain, vanilla >> unmodified IPsec policy engine as implemented in KAME. > > I don't know how to interpret this statement. > >> As far as I understood, what Jari tried to argue is that it is possible >> to create 2401/bis compatible policies that allow HIP and IPsec to >> co-exist in a single host. Since I am not an expert in 2401/bis, >> I can't really say whether that is true or not, but I have no reason >> to doubt what Jari says. > > Again, I have some problem interpreting this. What Jari said is that if > one wants to employ HIP and make sure that it does not cause security > problems by overriding the (presumably more restrictive) access control > policies typically associated with IPsec use, then one can put the SPD > entries that refer to HIP traffic at the end of the SPD. That mechanistic > description of co-existence does not answer the question of whether use > of ESP syntax with HIP is different from ESP with IPsec. > >> >>> Thus I noted that if HIP uses the ESP syntax, but does not follow >>> the processing model described in 2401/bis, then the result is not >>> IPsec. >> >> And I agreed with you, under my perhaps misled understanding that >> the term "IPsec" implies implementing *all* of 2401/bis processing >> model, including all selectors, which HIP does not require (or support). > > The term IPsec DOES imply compliance with ALL of the 2401.bis processing. > You were wight. > >> On the other hand, there does not seem to be anything that prevents >> HIP and IPsec from co-existing in a single machine and sharing a >> single 2401/bis conformant policy engine. > > If by policy engine your mean SPD, that may be true. That may be an > interesting capability, but it does not address the question of whether > ESP-HIP and ESP-IPsec are the same protocol, which is what I think we are > discussing right now. They could be, depending on if a supplementary RFC describing either a slightly augmented ESP or a slightly different HIP were published. > If you have to change ANY code in an IPsec implementation to support HIP, > then its not IPsec anymore. If you can implement the requisite processing > before the packet is handed to IPsec, then no problem. You *can* implement it separately, but often it is much more efficient to do it within the ESP implementation. The behaviour observed from outside the stack is the same, excluding efficiency issues. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP7LimFGmVIGYWzvRAQF/pQQAiedeRGqfzIuFyvHcWAA+4r8hRVyZxfJg mUu6T5njbx4Y+i4KP0gROnmA/aw4f5Y9L5EjuQmRivmylN53xdlvdbLOoStlk2bV 1c7qL7zn8DN1h4bHifPCvqXl5wEi1TNOSyMEa+atCXsozY6rc8pmt81cozf7ecSv z37teIKRCvY= =yG78 -----END PGP SIGNATURE----- From andrew@indranet.co.nz Wed Nov 12 20:23:04 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Nov 12 20:23:04 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3FB23987.90006@piuha.net> <2310000.1068664946@ijir> <2740000.1068671770@ijir> Message-ID: <9000000.1068688488@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, November 12, 2003 04:45:46 PM -0500 Stephen Kent wrote: > IPsec does not see a pseudo header, in general. Remember, many IPsec > implementations are in security gateways or BITW implementations. These > implementations see packets with real headers, not pseudo headers. So, in > order to provide a uniform description of IPsec processing, we always > express it in terms of receiving a packet with an IP header, that > otherwise could just be sent to a layer 2 interface. That's why there is > no reference to pseudo headers in IPsec. It is not an oversight, it is an > intentional choice of the interface defined for IPsec. Ah. Ok, that makes sense. Well, pseudoheader fields or actual header fields, the description is almost the same. > Consider the comments above re what the interface is to IPsec, then > decide where HIP fits. Well, one could describe the HIP processing as a kind of packet mangler in the path before entering IPsec transport mode; I had that for a while in my implementation, even. So, if logically it's that, but implementors for efficiency alter ESP, where do we stand, in your opinion? Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP7LkaFGmVIGYWzvRAQGPnQP7BIXrmYRPLHx2k6Y5ppBI+LrVVrrqB6nt CPhQhGN7XXUaQLcfPQmzidmn6a3d9Cm4wcesatBCcMfdFGXwtDUHHYRdOTR0iDbi 9Mkcfss87pug2wM2E5tdRlO5IuNt6LVcoNOaCMT59aW0IGjZWlSb3Wbq42zD7ZGO t+BcL3fmg8Y= =nZgS -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Wed Nov 12 21:12:00 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed Nov 12 21:12:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: Your message of "Wed, 12 Nov 2003 16:45:46 EST." Message-ID: <3969.1068691037@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: >> I was surprised, but 2401/bis are silent about the content of the >> pseudoheader used by upper layers to calculate their checksums, and also >> about the apparent addresses seen by upper layers (the latter is less >> surprising). This is how BEET differs, where it comes down to it. Stephen> IPsec does not see a pseudo header, in general. Remember, many Stephen> IPsec implementations are in security gateways or BITW Stephen> implementations. The "H" in HIP is for "HOST" BITW/BITS do not apply. I see no requirement that all features be implementable by a BITW. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7LuWIqHRg3pndX9AQHzzQP+LqFNhscNFfpg4ZRqUuY6YtrIORI2gnBt rsAUS2N0MznZg1AKxFj05gaNkQXYP16+rRSpdrx4tYE7drtzGHfLTQnaJX2RetfQ SQ93+LUA15yzuo2Knhh0duzTC+CTgaOdbfF1boUhIQWww8xY/YYKQAxb0AEvLbHE d6pAf1MTRy4= =98Hb -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Thu Nov 13 10:31:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Nov 13 10:31:02 2003 Subject: [Hipsec] HIP referrals (was Re: Some Comments on ID/Loc Separation Proposals) In-Reply-To: References: Message-ID: <3FB3AB31.4090603@nomadiclab.com> Margaret.Wasserman@nokia.com wrote: > I have been analyzing a few of the proposal for ID/Loc separation > (HIP, NOID and MAST) and I have some comments (attached). ... > > HIP Feedback > > Very well-developed proposal for end-to-end ID/Loc separation. > No ID->Locator mapping mechanism, so no support for referrals. > > Specific Feedback: > > - The lack of any ID->Locator mapping mechanism is a > blocking problem for using HIP (as currently defined) > with anything but simple end-to-end applications. The earlier versions of the HIP draft contained a mechanism where a HIT would not be a 128 bit hash of the public key but consist of a 64-bit, hierarchically assigned prefix and a 64-bit hash. However, I removed this from the later versions of drafts for the following reasons: - the proposed mechanism was tied to DNS, and we decided to move all DNS specific issues into a separate draft - we wanted to keep HIP as simple as possible, and having different types of HITs seemed unnecessary, especially when the mechanism was optioinal - ID->Locator mapping is not needed for simple end-to-end applications, and the majority of current applications do not need referrals According to the current thinking, there are at least three different options on how to support referrals in HIP: 1. Re-introduce some structure to the HITs, and use a hierarchical lookup service (e.g. reverse DNS). 2. Introduce a flat lookup service, e.g., based on DHTs. This looks like a researchy issue, which is likely to need more research before ready for engineering. 3. Introduce a "social contract" to HIP where each HIP host acts as a temporary rendezvous point for all hosts that it has connections with. While 3) is not a generic ID->locator mapping solution, it looks like quite interesting anyway. In particular, it seems to be able to solve the common referral case where A has connections with both B and C, and what to give B's ID to C so that B and C can start to communicate directly. Here is a more specific example on how this might work: 1. A opens a HIP association AB with B. 2. A opens a HIP association AC with C. At this point A knows the locator sets for both B and C, but B and C know only the locator set of A. 3. A sends B's ID to C. 4. C tries to open a connection to B. At this point C has B's id, but it does not have B's locator set. However, it has a HIP association with A, and therefore it may try to use A as a rendezvous server for B. [There are a number of open problems in the description above, I know. But for the moment I'd like to focus only on the idea, hoping that the nasty details can be solved later.] 4. C constructs an I1 packet and sents it to A, hoping that A knows where B is and will forward the packet to B. 5. A receives the I1, and according to the "social contract" it passes the packet to B, whose locators it knows. 6. B receives the I1, and replies directly back to C, thereby initiating the actual negotiation. I don't think that it would be useful to define such an referral mechanism quite yet, but it would certainly be interesting to explore its limitations and implications (given the assumption that it can be made to work in the first place). --Pekka Nikander From rgm@htt-consult.com Thu Nov 13 11:00:02 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Thu Nov 13 11:00:02 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3969.1068691037@marajade.sandelman.ottawa.on.ca> References: <3969.1068691037@marajade.sandelman.ottawa.on.ca> Message-ID: <6.0.0.22.2.20031113092708.03c02870@localhost> At 07:37 PM 11/12/2003, Michael Richardson wrote: > Stephen> IPsec does not see a pseudo header, in general. Remember, many > Stephen> IPsec implementations are in security gateways or BITW > Stephen> implementations. > > The "H" in HIP is for "HOST" > BITW/BITS do not apply. > > I see no requirement that all features be implementable by a BITW. There is the Proxy model. This is not quite BITW. I only roughed out the Proxy model, to support an orginization wanting HIP for external use, and not fully upgraded. The Proxy is a bit more than the active NAT. Arguement can be made to not do this (it actually owns the HIs, yikes!). But it is in the HIP model. From andrew@indranet.co.nz Fri Nov 14 08:59:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Fri Nov 14 08:59:00 2003 Subject: [Hipsec] PyHIP release Message-ID: <7610000.1068820257@ijir> -----BEGIN PGP SIGNED MESSAGE----- A new release of PyHIP, which I believe is approximately compliant to draft-moscowitz-hip-08, is available at the URL below (note the slight change of the URL format from previously). Older releases will be moved into that directory at some time. - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCUAwUBP7TnKVGmVIGYWzvRAQEHXAP3eqlVZCtjG9eU3ab5vo5I5SYdHgLsiVrO 1q22FH4iaLmkuTaOMGuwD13tvXuoRw8/Iw5dQQdqbhThWbR9iOdyaVisIlGJtivF ycIy0sTTYNaXEkjn/N+uQilLkKFKuNlou3FlHuXquQSymFqegn3xO4R0hjYJejYY 1R8cXKtQVQ== =a17c -----END PGP SIGNATURE----- From kent@bbn.com Fri Nov 14 09:19:01 2003 From: kent@bbn.com (Stephen Kent) Date: Fri Nov 14 09:19:01 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <9000000.1068688488@ijir> References: <3FB23987.90006@piuha.net> <2310000.1068664946@ijir> <2740000.1068671770@ijir> <9000000.1068688488@ijir> Message-ID: At 14:54 +1300 11/13/03, Andrew McGregor wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > >- --On Wednesday, November 12, 2003 04:45:46 PM -0500 Stephen Kent > wrote: > >> IPsec does not see a pseudo header, in general. Remember, many IPsec >> implementations are in security gateways or BITW implementations. These >> implementations see packets with real headers, not pseudo headers. So, in >> order to provide a uniform description of IPsec processing, we always >> express it in terms of receiving a packet with an IP header, that >> otherwise could just be sent to a layer 2 interface. That's why there is >> no reference to pseudo headers in IPsec. It is not an oversight, it is an >> intentional choice of the interface defined for IPsec. > >Ah. Ok, that makes sense. Well, pseudoheader fields or actual header >fields, the description is almost the same. > >> Consider the comments above re what the interface is to IPsec, then >> decide where HIP fits. > >Well, one could describe the HIP processing as a kind of packet mangler in >the path before entering IPsec transport mode; I had that for a while in my >implementation, even. So, if logically it's that, but implementors for >efficiency alter ESP, where do we stand, in your opinion? > >Andrew If one can describe HIP processing as an activity that takes place prior to IPsec processing, then we probably don't have a problem. This would be true even if, as you note, people choose to implement this processing within the IPsec boundary. Look at the revised processing model figures I presented at this week's IPsec WG meeting to see if you think the separation in question is feasible. Steve From kent@bbn.com Fri Nov 14 09:39:00 2003 From: kent@bbn.com (Stephen Kent) Date: Fri Nov 14 09:39:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3969.1068691037@marajade.sandelman.ottawa.on.ca> References: <3969.1068691037@marajade.sandelman.ottawa.on.ca> Message-ID: At 20:37 -0600 11/12/03, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Stephen" == Stephen Kent writes: > >> I was surprised, but 2401/bis are silent about the content of the > >> pseudoheader used by upper layers to calculate their >checksums, and also > >> about the apparent addresses seen by upper layers (the latter is less > >> surprising). This is how BEET differs, where it comes down to it. > > Stephen> IPsec does not see a pseudo header, in general. Remember, many > Stephen> IPsec implementations are in security gateways or BITW > Stephen> implementations. > > The "H" in HIP is for "HOST" > BITW/BITS do not apply. > > I see no requirement that all features be implementable by a BITW. Mike, Does this means that HIP is to be employed ONLY when BOTH peers are native host implementations? Steve From kent@bbn.com Fri Nov 14 09:39:04 2003 From: kent@bbn.com (Stephen Kent) Date: Fri Nov 14 09:39:04 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <6.0.0.22.2.20031113092708.03c02870@localhost> References: <3969.1068691037@marajade.sandelman.ottawa.on.ca> <6.0.0.22.2.20031113092708.03c02870@localhost> Message-ID: At 9:30 -0700 11/13/03, Robert Moskowitz wrote: >At 07:37 PM 11/12/2003, Michael Richardson wrote: > >> Stephen> IPsec does not see a pseudo header, in general. Remember, many >> Stephen> IPsec implementations are in security gateways or BITW >> Stephen> implementations. >> >> The "H" in HIP is for "HOST" >> BITW/BITS do not apply. >> >> I see no requirement that all features be implementable by a BITW. > > >There is the Proxy model. This is not quite BITW. > >I only roughed out the Proxy model, to support an orginization >wanting HIP for external use, and not fully upgraded. The Proxy is >a bit more than the active NAT. > >Arguement can be made to not do this (it actually owns the HIs, >yikes!). But it is in the HIP model. When you guys agree on the scope of applicability for HIP, get back to me and we can continue this discussion. Steve From pekka.nikander@nomadiclab.com Fri Nov 14 10:06:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Nov 14 10:06:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: References: <3969.1068691037@marajade.sandelman.ottawa.on.ca> Message-ID: <3FB4F6E8.9000700@nomadiclab.com> Stephen, > Does this means that HIP is to be employed ONLY when BOTH peers are > native host implementations? Yes. That is the current model. The proxy model that Bob Moskowitz mentioned would extend HIP to a case where HIP is employed between a native host implementation and a HIP proxy. In that case I guess the HIP proxy could be compared to the IPsec Security Gateway concept (or is it called BITW?). Making an exact comparison is impossible since people have very different ideas of the potential processing model of a HIP proxy. It looks likely that a HIP proxy would more resemble a Mobile IP home agent than an IPsec Security Gateway. The HIP proxy concept was part of the proposed work item #6 at the BOF. --Pekka Nikander From mcr@sandelman.ottawa.on.ca Fri Nov 14 18:18:01 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Fri Nov 14 18:18:01 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: Your message of "Fri, 14 Nov 2003 09:46:33 EST." Message-ID: <4097.1068853735@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: >> The "H" in HIP is for "HOST" >> BITW/BITS do not apply. >> >> I see no requirement that all features be implementable by a BITW. Stephen> Does this means that HIP is to be employed ONLY when BOTH peers Stephen> are native host implementations? I can't see any reason to build or specify a BITW IPv6 mobility via HIP box. Maybe someone else can, but I don't see the point. The HITs need to be strongly associated with the TCP. Sure, NCP was implemented outboard for a decade. Was TCP/IP? Rarely. Things progress - BITW seems like a stepping stone. Eventually, you don't need it anymore. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7Vp5oqHRg3pndX9AQFdawQAyIlVYcqOssoQDZwSbkjwqFnfvlKPjRyI L7FKjoAf7aSoneBV+de8DLJkHtoKGQMdIihJj+jk4UdAW36yadV6OVhn1Ev1XLVG IL1jQtZ45y7aFixcX/UoGJ2RHFvcVlHOjcPyqG/2134CaOeAF9VMozDjyWR81nTU ytcwoFBVt6I= =Pxqj -----END PGP SIGNATURE----- From rgm@htt-consult.com Sun Nov 16 00:26:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Sun Nov 16 00:26:00 2003 Subject: [Hipsec] Re: feature interactions of HIP and IPsec In-Reply-To: <3FB4F6E8.9000700@nomadiclab.com> References: <3969.1068691037@marajade.sandelman.ottawa.on.ca> <3FB4F6E8.9000700@nomadiclab.com> Message-ID: <6.0.0.22.2.20031115224826.03c351f0@localhost> At 10:38 AM 11/14/2003, Pekka Nikander wrote: >Stephen, > >>Does this means that HIP is to be employed ONLY when BOTH peers are >>native host implementations? > >Yes. That is the current model. > >The proxy model that Bob Moskowitz mentioned would extend HIP >to a case where HIP is employed between a native host >implementation and a HIP proxy. In that case I guess the >HIP proxy could be compared to the IPsec Security Gateway >concept (or is it called BITW?). I should point out that I only came up with the Proxy model when I was challenged about it. 'Is it possible for...' 'Well, yes. Here is how. I don't think it is a good idea, as the Proxy owns the identity....' If we never implement the proxy model, I will not complain. Not one bit. Not over the wire or over the air! >Making an exact comparison is impossible since people have >very different ideas of the potential processing model of a >HIP proxy. It looks likely that a HIP proxy would more >resemble a Mobile IP home agent than an IPsec Security Gateway. > >The HIP proxy concept was part of the proposed work item #6 >at the BOF. > >--Pekka Nikander > > >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec From pekka.nikander@nomadiclab.com Wed Nov 19 06:19:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 19 06:19:01 2003 Subject: [Hipsec] Combining SLAP and HIP? Message-ID: <3FBB5968.7040702@nomadiclab.com> This is a multi-part message in MIME format. --------------070401020306010005040906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The SLAP approach is getting pretty favourable comments at the multi6 mailing list. Personally, I think that it is a great idea. However, I also think that the HIP way of introducing cryptographic end-point identifiers is a great idea. Now, the question prevails if we can somehow integrate these? For example, could HIP work as a control protocol for SLAP? May TCP could use HITs, STCP use SLAP directly, etc? Any ideas? (Before thinking too much, it is probably a good idea to read the rest of the messages on this at the multi6 mailing list.) --Pekka Nikander --------------070401020306010005040906 Content-Type: message/rfc822; name="Shared Locator Address Pool (SLAP) protocol proposal" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Shared Locator Address Pool (SLAP) protocol proposal" X-Sieve: cmu-sieve 2.0 Return-Path: Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n97.nomadiclab.com (Postfix) with ESMTP id CB8771C for ; Sat, 15 Nov 2003 19:00:57 +0200 (EET) Received: by n2.nomadiclab.com (Postfix) id EEEB1212C92; Sat, 15 Nov 2003 18:47:49 +0200 (EET) Delivered-To: pnr@nomadiclab.com Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id E54BA212C8D for ; Sat, 15 Nov 2003 18:47:49 +0200 (EET) Received: from psg.com (psg.com [147.28.0.62]) by outside.nomadiclab.com (Postfix) with ESMTP id 7E2CF113E09 for ; Sat, 15 Nov 2003 18:47:49 +0200 (EET) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL3Yi-00033A-J0 for multi6-data@psg.com; Sat, 15 Nov 2003 16:46:04 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL3Ye-00032o-Nt for multi6@ops.ietf.org; Sat, 15 Nov 2003 16:46:00 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAFGqPf29884 for ; Sat, 15 Nov 2003 08:52:25 -0800 Date: Sat, 15 Nov 2003 08:45:55 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <11729160049.20031115084555@brandenburg.com> To: multi6@ops.ietf.org Subject: Shared Locator Address Pool (SLAP) protocol proposal MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Level: Sender: owner-multi6@ops.ietf.org Precedence: bulk Folks, A fundamental advantage that transport-based locator-pool schemes (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, MAST, MIP) is that they can multiplex the control exchange in with data traffic, potentially saving on number of packets. Wedge-layer approaches are forced to have an explicit, separate exchange. MAST makes this asynchronous from the data exchange that uses the locator pool; this avoid startup delay. However the basic cost of the exchange remains. If a host must do this exchange with every other host it talks to, the aggregate overhead is high. Deferring use of the mechanism, as Pekka S. described, is one way to reduce such traffic. Wouldn't it be nice if it were possible to have the "enhanced" transport services share their lower-cost largesse with the wedge-layer schemes? So, here's the thought: 1. An endpoint runs Locator Pools (LP) as a resource shared among different consumer services at the endpoint -- eg, a wedge layer service and an enhanced transport service -- potentially with multiple maintainers. (Yes, the latter raises a concern about synchronization, but let's ignore that minor detail, for now.) LPs might vary in their granularity. Bigger grains makes it more likely that the pool will be shared. A pool that is the finest grain (Connection) can't be shared, of course. 2. A common Shared Locator Address Pool (SLAP) protocol is used by the different maintenance services, over different communication channels (eg, multiplexed on the transport channel, versus over an independent control channel). The maintenance services also might use different "configurations", such as peer-to-peer exchange, versus third-party agent mediation. 3. Enhanced transport services access the pool directly. Legacy transport services access the pool via the much-vaunted IP wedge layer service. If an enhanced transport is one of the participants, then there really is no need for a wedge-layer service to conduct an exchange. This saves packets. The obvious direction this idea leads is towards an effort to produce a common protocol. Clearly it should include the locator "characterization" attribute-signalling capability that Erik suggested. Anyone from the various camps interested in discussing such an effort? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA --------------070401020306010005040906-- From petri.jokela@nomadiclab.com Wed Nov 19 08:11:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Nov 19 08:11:01 2003 Subject: [Hipsec] HIP issue #03: Keymat interpretation Message-ID: <3FBB7396.4010204@nomadiclab.com> I have now changed the section 9 and 11 according to discussions earlier on this list. Proposed new text follows. Changes in Section 9: - Changed two paragraphs according to Tom's comments. - The key retrieval from the KEYMAT according to discussion earlier Changes in Section 11: Two new subsections added as proposed by Pekka. I haven't looked at other subsections in 11, so they are still in the original shape. The new ones are attached in this mail. In 11.2, I wanted to use something else than I and R for the rekey initiator and responder just to make sure that there is no connection with the basic 4-way handshake roles. That's why I' and R'. /petri 9. HIP KEYMAT HIP keying material is derived from the Diffie-Hellman Kij produced during the base HIP exchange. The Initiator has Kij during the creation of the I2 packet, and the Responder has Kij once it receives the I2 packet. This is why I2 can already contain encrypted information. The KEYMAT is derived by feeding Kij and the HITs into the following operation; the | operation denotes concatenation. KEYMAT = K1 | K2 | K3 | ... where K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) K2 = SHA-1( Kij | K1 | 0x02 ) K3 = SHA-1( Kij | K2 | 0x03 ) ... K255 = SHA-1( Kij | K254 | 0xff ) K256 = SHA-1( Kij | K255 | 0x00 ) etc. Sort(HIT-I | HIT-R) is defined as the network byte order concatenation of the two HITs, with the smaller HIT preceding the larger HIT, resulting from the numeric comparison of the two HITs interpreted as positive (unsigned) 128-bit integers in network byte order. The initial keys are drawn sequentially in the following order: HIP-IR encryption key for Initiator's outgoing HIP packets HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets HIP-RI encryption key (currently unused) for Responder's outgoing HIP packets HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets SA-IR ESP encryption key for Initiator's outgoing traffic SA-IR ESP authentication key for Initiator's outgoing traffic SA-RI ESP encryption key for Responder's outgoing traffic SA-RI ESP authentication key for Reponder's outgoing traffic The IR and RI denotes the direction of the traffic where the key is applied. The IR describes "from the Initiator to the Responder" -direction and the RI the other direction. The number of bits drawn for a given algorithm is the "natural" size of the keys. For the mandatory algorithms, the following sizes apply: 3DES 192 bits SHA-1 160 bits NULL 0 bits The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using NES will only draw the four ESP keys from KEYMAT. Section 8.9 describes the rules for reusing or regenerating KEYMAT based on the NES exchange. 11.1 ESP Security Associations Each HIP association is linked with two ESP SAs, one incoming and one outgoing. The Initiator's incoming SA corresponds with the Responder's outgoing one. The initiator defines the SPI for this association, as defined in Section 3.3. This SA is called SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the Responder's incoming SA corresponds with the Initiator's outgoing SA and is called SA-IR, with the SPI-IR. The Initiator creates SA-RI as a part of R1 processing, before sending out the I2, as explained in Section 8.5. The keys are derived from KEYMAT, as defined in Section 9. The Responder creates SA-RI as a part of I2 processing, see Section 8.6. The Responder creates SA-IR as a part of I2 processing, before sending out R2, see Step 17 in Section 8.6. The Initator creates SA-IR when processing R2, see Step 7 in Section 8.7. 11.2 Updating ESP SAs during rekeying After the initial 4-way handshake and SA establishment, both hosts are in state E3. There are no longer Initiator and Responder roles and the association is symmetric. In this subsection, the initiating party of the rekey procedure is denoted with I' and the peer with R'. The I' initiates the rekeying process when needed (see Section 8.8). It creates a NES packet with required information and sends it to the peer node. The old SAs are still in use. The R', after receiving and processing the NES (see Section 8.9), generates new SAs: SA-I'R' and SA-R'I'. It does not take the new outgoing SA into use, but uses still the old one, so there exists two SA pairs towards the same peer host. For the new outgoing SA, the SPI-R'I' value is picked from the received NES packet. The R' generates the new SPI value for the incoming SA, SPI-I'R', and includes it in the response NES packet. When the I' receives a response NES from the R', it generates new SAs, as described in Section 8.9: SA-I'R' and SA-R'I'. It starts using the new outgoing SA immediately. The R' starts using the new outgoing SA when it receives traffic from the new incoming SA. After this, the R' can remove old SAs. Similarily, when the I' receives traffic from the new incoming SA, it can safely remove old SAs. -- 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 From petri.jokela@nomadiclab.com Wed Nov 19 08:15:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Nov 19 08:15:01 2003 Subject: [Hipsec] HIP issue #03: Keymat interpretation In-Reply-To: <3FBB7396.4010204@nomadiclab.com> References: <3FBB7396.4010204@nomadiclab.com> Message-ID: <3FBB746F.6070009@nomadiclab.com> Reminder: the issue number refers to the issue-tracker numbering for draft-moskowitz-hip-xxx http://hip4inter.net/issues userid: guest passwd: guest /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 From dfawcus@cisco.com Wed Nov 19 09:37:01 2003 From: dfawcus@cisco.com (Derek Fawcus) Date: Wed Nov 19 09:37:01 2003 Subject: [Hipsec] Combining SLAP and HIP? In-Reply-To: <3FBB5968.7040702@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Wed, Nov 19, 2003 at 12:52:08PM +0100 References: <3FBB5968.7040702@nomadiclab.com> Message-ID: <20031119150915.B6475@edinburgh.cisco.com> On Wed, Nov 19, 2003 at 12:52:08PM +0100, Pekka Nikander wrote: > The SLAP approach is getting pretty favourable comments at > the multi6 mailing list. Personally, I think that it > is a great idea. However, I also think that the HIP way > of introducing cryptographic end-point identifiers is > a great idea. Now, the question prevails if we can > somehow integrate these? For example, could HIP work as > a control protocol for SLAP? May TCP could use HITs, > STCP use SLAP directly, etc? > > Any ideas? (Before thinking too much, it is probably > a good idea to read the rest of the messages on this > at the multi6 mailing list.) Yeah read part of it, but not all of it. However I'll comment anyway... It rather depends upon the usage model. As it is there are only usually two situations in which I'm communicating with a lot of different hosts. The first is DNS resolution, the second web browsing. Now for DNS resolution, often (i.e. when at work), I'm forced to use a particular resolving server. So I only talk to that one host. It's only at home, that my DNS resolver can contact all and sundry. However I don't think HIP maps well to that sort of problem (not much does, DNSSEC - a unresolved problem). The second situation - web browsing is more interesting. However, most (if not all) of this is publishing, so there is no interest in privacy, i.e. crypto is not an issue. Additionally, the connections tend not to be long lives (compared to expected movements), so again it would appear to be uninteresting wrt HIP. The only bit with any interest is potentially purchasing (https), but even there the crypto is pointless, as any 'security' is provided by being able to repudiate credit card transactions. So, the situations where I see these facilities being used, are for a few long lived connections. And for these, the delay in setting up the connection is inconsequental. DF From pekka.nikander@nomadiclab.com Wed Nov 19 10:48:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 19 10:48:00 2003 Subject: [Hipsec] Combining SLAP and HIP? In-Reply-To: <20031119150915.B6475@edinburgh.cisco.com> References: <3FBB5968.7040702@nomadiclab.com> <20031119150915.B6475@edinburgh.cisco.com> Message-ID: <3FBB9854.5040908@nomadiclab.com> Derek, > It rather depends upon the usage model. > ... DNS resolution, the second web browsing. I don't see how either SLAP or HIP would be applicable to either DNS resolution or web browsing. For DNS resolution you want to have application level multi-homing for obvious reasons, and for web browsing you probably want to share load between servers instead of having multi-homed servers. Hence, I don't understand what's your point. Are you saying that both HIP and multi6 are useless? If so, I do understand what you are saying but I don't understand why you are saying that. If not, I have to admit that I am totally confused. --Pekka Nikander From Margaret.Wasserman@nokia.com Tue Nov 25 13:08:01 2003 From: Margaret.Wasserman@nokia.com (Margaret.Wasserman@nokia.com) Date: Tue Nov 25 13:08:01 2003 Subject: [Hipsec] Next Steps for HIP Message-ID: Hi Pekka and David,=20 Thanks for running an excellent HIP BOF at the Minneapolis IETF=20 meeting. The BOF was well-run, and clearly there is a great deal of community interest in pursuing work in this area. On Wednesday evening, we were able to sit down with Pekka and Vern Paxson to discuss next steps for HIP. Our initial thoughts had focused on whether the HIP effort would be more likely to=20 succeed if it were chartered as an IETF Working Group or as an=20 IRTF Research Group, but we fairly quickly concluded that some parts of this work would best fit best in an IETF WG (publishing=20 the core specs, DNS interactions, etc.) while other parts are fairly clearly research activities (HIT-to-locator mapping,=20 for example). So, if there is no objection, we'd like to see the HIP community put together two complementary charters: One for an IETF WG to do the more straight-forward engineering work, and one for an IRTF RG to continue research in this area. Please let us know if there are any questions or comments. Thanks, Thomas Narten and Margaret Wasserman Internet Area Directors From dfawcus@cisco.com Tue Nov 25 17:28:01 2003 From: dfawcus@cisco.com (Derek Fawcus) Date: Tue Nov 25 17:28:01 2003 Subject: [Hipsec] Next Steps for HIP In-Reply-To: ; from Margaret.Wasserman@nokia.com on Tue, Nov 25, 2003 at 01:41:44PM -0500 References: Message-ID: <20031125230125.B13999@edinburgh.cisco.com> On Tue, Nov 25, 2003 at 01:41:44PM -0500, Margaret.Wasserman@nokia.com wrote: > > So, if there is no objection, we'd like to see the HIP community > put together two complementary charters: One for an IETF WG > to do the more straight-forward engineering work, and one for > an IRTF RG to continue research in this area. > > Please let us know if there are any questions or comments. So what would the aims of the WG be? To produce a informational RFC describing the current state of play, or to produce some standard track RFCs? Also to what extent would the two groups interact. If standard track documents are expected out of the IETF WG, then are they to be held as proposed standards pending the results of the IRTF RG, or would they be able to progress as is? DF From jari.arkko@piuha.net Wed Nov 26 04:55:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Nov 26 04:55:01 2003 Subject: [Hipsec] Next Steps for HIP In-Reply-To: <20031125230125.B13999@edinburgh.cisco.com> References: <20031125230125.B13999@edinburgh.cisco.com> Message-ID: <3FC47F42.5040504@piuha.net> Derek Fawcus wrote: > So what would the aims of the WG be? To produce a informational RFC > describing the current state of play, or to produce some standard > track RFCs? I think the intent has been all along to produce Experimental RFCs. I'd be surprised if a split between an IETF and IRTF group would change that. --Jari From Spencer Dawkins" Message-ID: <0cc001c3b41d$d184abd0$2c818182@DFNJGL21> This isn't a bad plan, of course. I guess I'm wondering (after the BoF) if HIT-to-locator mapping really IS research - I thought this was covered under the "we need operational guidance for usability and deployability" thread. I know we don't have a spec on how to do it, but does that make it research? Or is the IRTF work to include PKI? Did the back-of-the-dinner-napkin include a complete list of research topics? What I remember from the BoF was that we had three specs that were essentially ready to Last-Call for Experimental, and a bunch of preliminary work - surely not all the preliminary work belongs in the IRTF (else why have a WG? just so we can do a WG Last Call?)... Spencer ----- Original Message ----- From: To: ; Cc: ; ; Sent: Tuesday, November 25, 2003 12:41 PM Subject: [Hipsec] Next Steps for HIP Hi Pekka and David, Thanks for running an excellent HIP BOF at the Minneapolis IETF meeting. The BOF was well-run, and clearly there is a great deal of community interest in pursuing work in this area. On Wednesday evening, we were able to sit down with Pekka and Vern Paxson to discuss next steps for HIP. Our initial thoughts had focused on whether the HIP effort would be more likely to succeed if it were chartered as an IETF Working Group or as an IRTF Research Group, but we fairly quickly concluded that some parts of this work would best fit best in an IETF WG (publishing the core specs, DNS interactions, etc.) while other parts are fairly clearly research activities (HIT-to-locator mapping, for example). So, if there is no objection, we'd like to see the HIP community put together two complementary charters: One for an IETF WG to do the more straight-forward engineering work, and one for an IRTF RG to continue research in this area. Please let us know if there are any questions or comments. Thanks, Thomas Narten and Margaret Wasserman Internet Area Directors _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From Margaret.Wasserman@nokia.com Wed Nov 26 08:31:01 2003 From: Margaret.Wasserman@nokia.com (Margaret.Wasserman@nokia.com) Date: Wed Nov 26 08:31:01 2003 Subject: [Hipsec] Next Steps for HIP Message-ID: Hi Derek (and everyone else), The reasoning behind this idea is that some parts of this=20 work (the publication of the experimental specs, basic mobility=20 and multihoming support, DNS interactions) are well-defined tasks that are well-understood and subject to applied engineering. Whereas, some items on the proposed charter (the use of DHTs for=20 HIT->Address mapping, perhaps rendezvous and proxy?) are much less=20 well-defined and might benefit from a concentrated effort in the=20 research community before coming to the IETF. IETF WGs are good at refining well-understood ideas through cross- area review, but they aren't necessarily a good forum for=20 advancing our thinking on technical issues, such as how/if a complex algorithm can be applied to a complicated problem. So, the idea would be to charter an IETF WG to do the well-defined work, in parallel with efforts in the reasearch community to=20 better understand the more speculative items. It is even possible that an IRTF research group would make sufficient progress that we=20 could bring some of their output into the WG at a later stage. Our goal is to use whatever structure(s) will best support this work, and to work with the HIP community to decide which work falls into which category. If there is no work in one of the two categories, we don't need to start that group.=20 This idea doesn't imply any change to the plan to publish the HIP specs as experimental RFCs. This isn't a done deal, so if the community believes that it=20 would work better to structure this work differently, we are open to that. Margaret > -----Original Message----- > From: hipsec-admin@honor.trusecure.com > [mailto:hipsec-admin@honor.trusecure.com]On Behalf Of ext Derek Fawcus > Sent: Tuesday, November 25, 2003 6:01 PM > To: Wasserman Margaret (NRC/Boston) > Cc: pekka.nikander@nomadiclab.com; dward@cisco.com; > hipsec@honor.trusecure.com; narten@us.ibm.com; irtf-chair@irtf.org > Subject: Re: [Hipsec] Next Steps for HIP >=20 >=20 > On Tue, Nov 25, 2003 at 01:41:44PM -0500,=20 > Margaret.Wasserman@nokia.com wrote: > >=20 > > So, if there is no objection, we'd like to see the HIP community > > put together two complementary charters: One for an IETF WG > > to do the more straight-forward engineering work, and one for > > an IRTF RG to continue research in this area. > >=20 > > Please let us know if there are any questions or comments. >=20 > So what would the aims of the WG be? To produce a informational RFC > describing the current state of play, or to produce some standard > track RFCs? >=20 > Also to what extent would the two groups interact. If standard track > documents are expected out of the IETF WG, then are they to be held > as proposed standards pending the results of the IRTF RG, or would > they be able to progress as is? >=20 > DF > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From saq66@umkc.edu Wed Nov 26 19:58:00 2003 From: saq66@umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Wed Nov 26 19:58:00 2003 Subject: [Hipsec] Next Steps for HIP Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110818C@KC-MAIL4.kc.umkc.edu> =20 >Whereas, some items on the proposed charter (the use of DHTs for >HIT->Address mapping, perhaps rendezvous and proxy?) are much less >well-defined and might benefit from a concentrated effort in the >research community before coming to the IETF. =20 mapping is not a big deal; It just requires an efficient=20 data structure (which is not a research effort). The=20 known distributed object location algorithms are DHT, skip lists and plankton algorithm etc. I guess, this can even=20 be left as an implementation exercise . If HIP needs a=20 simple HIT->IP address mapping, go for DHT. But, DHT doesn't resolve complex queries. If one is interested in seeing how=20 HIP system work with other functions say SLP, we need to=20 think about other alternatives. One can do a late binding=20 to couple both the systems. In such cases, you need a better=20 mapping system which can answer imprecise queries(which is a=20 research effort.) =20 But, as per my understanding of HIP effort, it requires a=20 rendezvous system; something other than DNS(as DNS cache at=20 a larger time scale.) DHT suffers from churn and security problems. Instead, why can't we just have an agent (like=20 home agent in MIP; but can be present anywhere) which can=20 provide all the currently available/known/best locators for=20 the HIT identifier? =20 In short, I don't see a need for IRTF RG. The problem of selecting a suitable data structure to implement a=20 rendenzous mechanism is not a research issue.=20 =20