From pekka.nikander@nomadiclab.com Mon Dec 1 06:52:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 1 06:52:01 2003 Subject: [Hipsec] Next Steps for HIP In-Reply-To: References: Message-ID: <3FCB3377.6050601@nomadiclab.com> Folks, I am still in the middle of processing the comments that were made during the BOF and still struggling to understand what would be the best way forward. Hence, what I write below may be half baked and may change as I get better understanding of the situation. On the other hand, I am sure that we need more discussion about this topic in order to find out what is the best way forward. Firstly, I want to remind everybody that the currently stated goal of this proposed work at the IETF and IRTF is to allow *experimentation* with the proposed identifier / locator split. The proposed change is architecturally larger than e.g. moving from IPv4 to IPv6; at the same time it may be operationally much easier. Hence, many people (me included) are hesitant in seeing this kind of new architecture to be universally adopted to the Internet without proper experimentation first. We still do not know what are the likely effects of HIP in the large. One aspect to consider is to compare introducing HIP to the intro- duction of NAT, which led to large scale changes in the nature of applications. I might claim that it is probably better for the Internet to introduce the change in a controlled way than to allow it to happen without any control. Secondly, HIP is by no way the only proposal in this area. Indeed, there are multiple proposals appearing in the multi6 working group. It is likely that the solution adopted by the multi6 working group will be less ambitious than HIP is. On the other hand, we can hope that the adopted solution would be "forward compatible" with HIP (or whatever HIP will become to). At the same time, there are even more far fetching solutions being proposed at the (academic) research community. Personally, I do not believe that the HIP that we have now is the same as the "HIP" that eventually will be adopted to the Internet in the large. (That is, I do believe that we need to do the id/loc split, but I don't know how exactly.) Indeed, I am almost sure that there are aspects in the current HIP structure that we want to change. We just don't know what those aspects are. Hence, we want to have an open situation where we can change any of the current HIP aspects without causing too much back pressure from the market. Thirdly, we have to remember that the IETF is to a large extent an organization that aims to lead the Internet to the future. Its main product is standards based on rough consensus and running code. Hence, if we want to change the Internet with HIP, - we have to show that HIP indeed is good for the Internet, - we have to reach rough consensus, and - we must have running code. Hence, we have to choose a working structure that allows us to go forward along all these three aspects: - exploring the consequences of HIP, - building consensus, and - having running and working code. I believe that having both a working group, for building consensus and defining details, and a research group, for exploration and alternative (sub)solutions, may be a good way. However, I am also open to other suggestions; maybe there are better ways to go forward. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Dec 1 08:52:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 1 08:52:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought Message-ID: <3FCB4F64.4070401@nomadiclab.com> Folks, Taking a different angle on how to organize the HIP work, I think that it is also useful to think in very concrete terms. My previous mail tried to focus on the various in-the-large aspects that we have to consider here. This mail puts forward a concrete but certainly not ready proposal for a HIP WG and an RG with a slightly larger scope. Both groups could use the same mailing list, at least initially. HIP WG Chairs: David Ward, Gonzalo Camarillo A 6-9 month WG that would produce the following documents: 1. HIP base protocol specification. Experimental RFC. Base document: draft-moskowitz-hip-08/09.txt Document Editor: Petri Jokela 2. Basic mobility and multi-homing with HIP. Experimental RFC. Base document: draft-nikander-hip-mm-01.txt (-00 is not good enough) Document Editor: Pekka Nikander 3. DNS resource record for storing HIP Host Identifiers and HITs. Experimental RFC. Base document author: Michael Richardson Document Editor: Needs to be defined This is a simple RR that is very much like IPSECKEY RR. It just stores a public key and/or a hash of a public key. 4. A simple rendezvous server for HIP. Experimental RFC. Base document author: Pekka Nikander Document Editor: Needs to be defined This is a simple node that forwards I1 packets to a registered IP address and does nothing else. We also need a protocol that allows a HIP host to change the registered IP address at the rendezvous server. The latter could be a new HIP packet, basically meaning that the rendezvous server would need to run HIP with the hosts that it servers. It could also be something much simpler, e.g., I1 -> R1 -> AddressChange, where the AddressChange would be a packet that implements some properties from I2 but instead of creating a HIP state just updates the I1 forwarding state. Instead of having Michael to write the -00 version of the DNS RR document and me the -00 version of the simple rendezvous server, we could have design teams. However, I do believe that the ideas are simple enough that it is probably better to have single individuals to write the initial drafts. (Provided, of course, that those individuals do have cycles.) BEET seems to be moving to MOBIKE, and going standards track. LOC/ID SPLIT AND HIP (LISHIP) RG Chairs: To be determined (I could be one) An RG with a 2-3 year clear two threaded goal: - to explore solutions to the referral problem caused by the id/log split - to co-ordinate and follow the experimental deployment of HIP in the Internet Documents to be produced: - HIP experimentation guide. Informational RFC. The goal of this document is to give practical instructions on how to join the HIP experimentation. It must also contain suitable warnings about the potential dangers, like some applications breaking etc. - DHT based information lookup service. Experimental RFC. A new, flat "DNS"? How to build it? How to make it economically feasible? I think that this is the really tough problem, and not related only to HIP but also to most other id/loc proposals. - Other referral solutions (but DHT) for HIP. Informational RFC? Could there be other solutions to solve the referral problem, especially with HIP? Hierarchical HITs is one possibility, which was discussed in earlier HIP architectural drafts but removed later in the process. Another possibility of using peers as limited rendezvous server was invented during the Minneapolis meeting. I guess there might be others, too. - Advanced HIP rendezvous server / proxy / forwarding agent. Experimental RFC. A node that provides "advanced" rendezvous / proxy / packet forwarding functions for HIP nodes. If this was to be produced at the IETF, I guess one would need a requirements document first. However, being IRTF work I'd much more would like to see people to implement various options, and the document to be produced as a merger of results from implementation projects. There are already a couple of research papers that have appeared in this area, and I guess there will be more. This could be moved to the WG later once the WG has completed its initial items. - Dynamic DNS updates secured with HIP. Experimental RFC. Once we start storing HIs (public keys) into the DNS, could we allow the use of the same public keys to update other DNS records that are related to that public key? What should the protocol be like? Like the rendezvous protocol outlined in the #4 WG work item? This might result in a future item for the dnsext WG. - NAT traversal with HIP. Experimental RFC. I guess there might be multiple approaches in this area. Personally, I don't care much about this as I sincerely hope that IPv6 would come and make NATs to go away. - Applications guideline. Informational RFC. How something like HIP would affect the applications. There is also a new mailing list, aulli, for discussing some related aspects. Now, as you can see, there seems to be enough of food for both a working group and a research group. There seems also to be enough of people that actually want to use HIP so that the WG would most probably be manned and produce useful things. On the other hand, so far there definitely has been enough of people interested on researching HIP so that I would expect the RG to be fairly lively and actually produce output. --Pekka Nikander From Margaret.Wasserman@nokia.com Mon Dec 1 09:49:01 2003 From: Margaret.Wasserman@nokia.com (Margaret.Wasserman@nokia.com) Date: Mon Dec 1 09:49:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought Message-ID: Hi Pekka, > Taking a different angle on how to organize the HIP work, > I think that it is also useful to think in very concrete > terms. My previous mail tried to focus on the various > in-the-large aspects that we have to consider here. This > mail puts forward a concrete but certainly not ready proposal > for a HIP WG and an RG with a slightly larger scope. Both > groups could use the same mailing list, at least initially. I think that it is an excellent idea to try to have a more concrete discusson about ths. In general, I agree with the=20 split you are proposing, but I do have a few comments and=20 questions. > HIP WG >=20 > Chairs: David Ward, Gonzalo Camarillo Technically, Thomas and I will choose the chairs for this WG. We do appreciate your suggestions, though! =20 > A 6-9 month WG that would produce the following documents: >=20 > 1. HIP base protocol specification. Experimental RFC. > Base document: draft-moskowitz-hip-08/09.txt > Document Editor: Petri Jokela >=20 > 2. Basic mobility and multi-homing with HIP. Experimental RFC. > Base document: draft-nikander-hip-mm-01.txt (-00 is not=20 > good enough) > Document Editor: Pekka Nikander These both look good. Were you also planning to publish a WG version of the architecture? Or is the individual submission version good enough for now? =20 > 3. DNS resource record for storing HIP Host Identifiers and HITs. > Experimental RFC. > Base document author: Michael Richardson > Document Editor: Needs to be defined >=20 > This is a simple RR that is very much like IPSECKEY RR. > It just stores a public key and/or a hash of a public key. >=20 > 4. A simple rendezvous server for HIP. Experimental RFC. > Base document author: Pekka Nikander > Document Editor: Needs to be defined >=20 > This is a simple node that forwards I1 packets to a > registered IP address and does nothing else. [...] Both of these look good, too. What is the timeframe for having first drafts of these documents? > LOC/ID SPLIT AND HIP (LISHIP) RG I think all of the RG topics look interesting. One question: Would you want this to be an open RG, or a closed one? Also, I would probably break the HIP work into two separate mailing=20 lists once these things spin up... I think that would help to keep=20 the WG focused on the short-term deliverables. =20 > - Applications guideline. Informational RFC. >=20 > How something like HIP would affect the applications. > There is also a new mailing list, aulli, for discussing > some related aspects. I'm wondering if this should be done in the RG or in the WG... We may want to talk to the applications folks about this, and figure out what makes the most sense. I'd also expect this document to be interesting and useful for the multi6 folks. =20 > Now, as you can see, there seems to be enough of food for both > a working group and a research group. There seems also to be > enough of people that actually want to use HIP so that the WG > would most probably be manned and produce useful things. On the > other hand, so far there definitely has been enough of people > interested on researching HIP so that I would expect the RG to > be fairly lively and actually produce output. I agree, and I think that this makes sense as a way to move forward. What do others think? Margaret From gab@sun.com Mon Dec 1 10:08:01 2003 From: gab@sun.com (gabriel montenegro) Date: Mon Dec 1 10:08:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought In-Reply-To: References: Message-ID: <3FCB6127.6050309@sun.com> I think having a HIP WG and a RG is a good idea. What I'm wondering is if the RG should be limited to HIP. Pekka himself has said there are other alternatives. Should we not encourage looking at other variants of id/loc separation or even id/loc relationship (separation is just one possible such relationship). As an exampel of another possibility, I was very enthusiastic about the possiblity of conjoining id/loc in as per CGA/SUCV. Now, it seems like all that is shot due to IPR concerns. Nevertheless, perhaps there's ways around it or ways] to influence IPR. My concern stems from some discussions I took to heart in the NSRG whereby the id/loc decision was explicit. The reason as eloquently put forth by Steve Deering was that having them conjoined is actually a feature. The problem is when you don't want it, granted, but having the option of this massively distributed database which is the routing fabric do the id/loc resolution would indeed be sweet (whenever that works). This is one example, but I'm sure there's other proposals before or after HIP that attempt explorations along the id/loc separation space (e.g. FARA) and might benefit from a common area for discussion. Oh, and I vote it be an open RG. -gabriel From saq66@umkc.edu Mon Dec 1 12:44:00 2003 From: saq66@umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Mon Dec 1 12:44:00 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02985747@KC-MAIL4.kc.umkc.edu> >Should we not encourage looking at other variants of >id/loc separation or even id/loc relationship=20 >(separation is just one possible such relationship).=20 I agree, it is an important work. But, it duplicates the multi6 work. I presume, the proposed RG will=20 deal with possible research issues regarding mapping,=20 referral etc;to serve as input to various IETF WG relating to multi-homing and mobility. >As an exampel of another possibility, I was very=20 >enthusiastic about the possiblity of conjoining id/loc=20 >in as per CGA/SUCV. We have more cryptographic name space proposals...=20 self-certifying key space, naming markup languages, and PBK etc Even, a recent draft explores the issue from URN=20 perspective (draft-thiemann-cbuid-urn-00.txt.) But, what is the purpose of conjoining id/loc as per CGA etc? >This is one example, but I'm sure there's other proposals >before or after HIP that attempt explorations along the >id/loc separation space (e.g. FARA) >and might benefit from a common area for discussion. OTOH, FARA doesn't introduce new name space. So, it's requirements will not match with Pekka's RG charter=20 items. But, yes... anything can be discussed if relevant to id/loc split. I agree with pekka's RG strawman. But, I have two more=20 concerns for the RG: o it should address some of the saad charter goals like referential integrity in case of multiple identifiers. o it should not just focus on HIP; It should also take into some of the multi6 proposals research concerns. actually, some of the multi6 proposals require pekka's stated RG charter deliverables (i.e.locator selection, referral system etc.) From smb@research.att.com Mon Dec 1 13:45:01 2003 From: smb@research.att.com (Steven M. Bellovin) Date: Mon Dec 1 13:45:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought In-Reply-To: Your message of "Mon, 01 Dec 2003 16:25:40 +0200." <3FCB4F64.4070401@nomadiclab.com> Message-ID: <20031201191756.6EF1A7B43@berkshire.research.att.com> In message <3FCB4F64.4070401@nomadiclab.com>, Pekka Nikander writes: > >BEET seems to be moving to MOBIKE, and going standards track. > The status of BEET and its relationship (if any) to MOBIKE is still unsettled. --Steve Bellovin, http://www.research.att.com/~smb From rgm@htt-consult.com Mon Dec 1 14:44:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Mon Dec 1 14:44:00 2003 Subject: [Hipsec] Next Steps for HIP In-Reply-To: <3FCB3377.6050601@nomadiclab.com> References: <3FCB3377.6050601@nomadiclab.com> Message-ID: <6.0.1.1.2.20031201150720.03f71a58@localhost> I just discovered that practically all my HIPSEC messages were ending up in my Junk folder. Some with ratings as high as 90! I've made some changes that I hope will stop such behaviour. Anyway, I am sorry if I have been out of the loop. At 02:42 AM 12/1/2003, Pekka Nikander wrote: >I am still in the middle of processing the comments that >were made during the BOF and still struggling to understand >what would be the best way forward. Hence, what I write >below may be half baked and may change as I get better >understanding of the situation. On the other hand, I am sure >that we need more discussion about this topic in order to >find out what is the best way forward. > >Firstly, I want to remind everybody that the currently stated >goal of this proposed work at the IETF and IRTF is to allow >*experimentation* with the proposed identifier / locator split. If only more of the 'new' ideas that have been in the IETF over the past 10 years had been handled in this manner. >Thirdly, we have to remember that the IETF is to a large extent >an organization that aims to lead the Internet to the future. >Its main product is standards based on rough consensus and >running code. Hence, if we want to change the Internet with HIP, >- we have to show that HIP indeed is good for the Internet, >- we have to reach rough consensus, and >- we must have running code. It would be interesting indeed, if other work was made to work under the same premise. Oh course, I am now working in IEEE 802, and, for the most part, NO ONE does much of anything until there is a standard to complain about :) From rgm@htt-consult.com Mon Dec 1 14:52:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Mon Dec 1 14:52:01 2003 Subject: [Hipsec] Next Steps for HIP In-Reply-To: <6.0.1.1.2.20031201150720.03f71a58@localhost> References: <3FCB3377.6050601@nomadiclab.com> <6.0.1.1.2.20031201150720.03f71a58@localhost> Message-ID: <6.0.1.1.2.20031201152259.03fd6fa8@localhost> At 03:15 PM 12/1/2003, Robert Moskowitz wrote: >I just discovered that practically all my HIPSEC messages were ending up >in my Junk folder. Some with ratings as high as 90! > >I've made some changes that I hope will stop such behaviour. Anyway, I am >sorry if I have been out of the loop. Perhaps premature, but this message ended up in the proper folder. I would LIKE to think I've trained this puppy. From Spencer Dawkins" Message-ID: <006d01c3b879$933a2200$0400a8c0@DFNJGL21> I'm *net* complaining about the chairs who have graciously given us a home in multi6 for some vaguely on-topic discussion, but multi6 really is chartered to think about network multihoming, not host multihoming. Most of the time, we've ignored this distinction, but if we're hoping for something that switches links faster than BGP4 converence times, we aren't duplicating multi6 (at least not what multi6 is chartered to do). Spencer ----- Original Message ----- From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "gabriel montenegro" ; Cc: ; ; ; ; ; ; Sent: Monday, December 01, 2003 12:17 PM Subject: RE: [Hipsec] A concrete HIP WG & RG proposal as feed for thought >Should we not encourage looking at other variants of >id/loc separation or even id/loc relationship >(separation is just one possible such relationship). I agree, it is an important work. But, it duplicates the multi6 work. I presume, the proposed RG will deal with possible research issues regarding mapping, referral etc;to serve as input to various IETF WG relating to multi-homing and mobility. From Spencer Dawkins" Message-ID: <007a01c3b87c$afceffa0$0400a8c0@DFNJGL21> If I may express an opinion... If I learned anything from the Late Unpleasantness on site-local addressing, it's that the more visibility something like HIP has in the applications community, the better. I agree with the thought that "effect on applications" is also significant for multihoming, and (although we don't talk about renumbering much these days) renumbering as well. I am concerned that putting this topic in the IRTF, in a HIPish RG, will bury it (from an APPS perspective) more effectively than site-local was buried in an IETF INT WG, and expect that if HIP or anything like it "takes off", we'll wish that we hadn't buried it (from an APPS perspective). What are alternatives that would have more visibility in the APPS community? Spencer p.s. I'm leaping past the part where TSV cares about multihoming, assuming that since path characteristics will be different when paths change, TSV will need to see paths change. ----- Original Message ----- From: To: ; Cc: ; ; ; ; Sent: Monday, December 01, 2003 9:20 AM Subject: RE: [Hipsec] A concrete HIP WG & RG proposal as feed for thought > - Applications guideline. Informational RFC. > > How something like HIP would affect the applications. > There is also a new mailing list, aulli, for discussing > some related aspects. I'm wondering if this should be done in the RG or in the WG... We may want to talk to the applications folks about this, and figure out what makes the most sense. I'd also expect this document to be interesting and useful for the multi6 folks. From saq66@umkc.edu Mon Dec 1 23:51:02 2003 From: saq66@umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Mon Dec 1 23:51:02 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110819F@KC-MAIL4.kc.umkc.edu> >Most of the time, we've ignored this distinction, but if we're hoping >for something that switches links faster than BGP4 converence times, >we aren't duplicating multi6 (at least not what multi6 is chartered to >do). =20 If i take the above statement at face value, multi6 should only consider = network-level solution i.e doing fail-over at bgp convergence scale. = But,=20 it is considering proposals at all levels. In IPv4, you do multi-homing=20 at routing level (as it is the only scalable model given address space=20 constraints.) But, IPv6 provides an oppurtunity to find more scalable=20 model beyond the network level. In a recent multi6 post, folks are=20 supporting for the transport level solution with a fail-over at RTT time = scale rather than convergence time scale. In BGP routing system, = fail-down=20 latency is at the order of 3-15 minutes; whereas, fail-over can be 10-20 sec(given, route flap damping, ghost flushing and default hold timer=20 settings.)=20 =20 In short, gabriel's wish list for the RG i.e "Should we not encourage=20 looking at other variants of id/loc separation or even id/loc = relationship (separation is just one possible such relationship)" is within the = charter=20 of multi6; which prompted my original reply. I agree with you that site and host multi-homing has some issues; But, = what=20 is the difference between site and host multi-homing from a id/loc split = perspective (use of look-up system for referral etc.)? =20 From gab@sun.com Tue Dec 2 02:04:01 2003 From: gab@sun.com (gabriel montenegro) Date: Tue Dec 2 02:04:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B0110819F@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B0110819F@KC-MAIL4.kc.umkc.edu> Message-ID: <3FCC402C.5040104@sun.com> Ayyasamy, Senthilkumar (UMKC-Student) wrote: > In short, gabriel's wish list for the RG i.e "Should we not encourage > looking at other variants of id/loc separation or even id/loc relationship > (separation is just one possible such relationship)" is within the charter > of multi6; which prompted my original reply. Precisely because I see some overlap in multi6 and related topics in HIP BoF, MOBIKE, mip{4,6,shop}, (anything else? ) that I think it should be ok for the IRTF to encourage thinking in this space. Even if the overlap is complete (which I doubt), the constraints and objectives are different. multi6 is a WG. They MUST be expeditious and decide on something in short order (as I'm pleased to see the chairs driving towards). A WG has less luxury than a RG for exploring. I'm suggesting that the IRTF should allow this to continue, and limiting it to be "the HIP RG" does not seem to accomplish that. -gabriel From pekka.nikander@nomadiclab.com Tue Dec 2 03:50:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 2 03:50:01 2003 Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought In-Reply-To: References: Message-ID: <3FCC5A3F.3020900@nomadiclab.com> Margaret, >> A 6-9 month WG that would produce the following documents: >> >> 1. HIP base protocol specification. Experimental RFC. >> 2. Basic mobility and multi-homing with HIP. Experimental RFC. > > These both look good. Were you also planning to publish a WG > version of the architecture? Or is the individual submission > version good enough for now? From my point of view, the individual submission version is good enough. If it appears that we need changes to the architecture, I think that it would be better to do it after rechartering. Personally, I do not believe that any of the proposed WG work items would produce any pressure to change the architecture document. Some of the research items may do that, though. >> 3. DNS resource record for storing HIP Host Identifiers and HITs. >> 4. A simple rendezvous server for HIP. Experimental RFC. > > Both of these look good, too. What is the timeframe for having > first drafts of these documents? Well, I have two other HIP drafts in my queue before I can write the simple rendezvous server draft. But definitely before Seoul. What comes to the DNS RR draft, I haven't talked to Michael lately; need to do that....done. We'll see how he answers. > I think all of the RG topics look interesting. One question: Would > you want this to be an open RG, or a closed one? I don't see any reason for a closed one. There has been also other people voicing for an open one. So be it. (Frankly, I didn't even remember that there is the option of running closed RGs...) > Also, I would probably break the HIP work into two separate mailing > lists once these things spin up... I think that would help to keep > the WG focused on the short-term deliverables. I'm OK with that. I just want to avoid dead mailing lists... >> - Applications guideline. Informational RFC. > > I'm wondering if this should be done in the RG or in the WG... I don't have any strong opinion. IMHO, it's probably best for the APPS folks to decide. Or maybe they want to do it separately in a short term APPS area WG or something. I really don't know. --Pekka From kslavov@hiit.fi Tue Dec 2 06:15:01 2003 From: kslavov@hiit.fi (Kristian Slavov) Date: Tue Dec 2 06:15:01 2003 Subject: [Hipsec] DH Group selection Message-ID: <3FCC7C27.3040907@hiit.fi> Hi, The latest draft, draft-moskowitz-hip-08, lists 8 DH groups. Are all these groups required to be implemented, or just optional? If optional, how do we signal the responder that we do not support certain DH group? Do the other implementations support all 8 groups? -- Kristian Slavov Research Assistant Helsinki Institute for Information Technology Gsm: +358-40-7220960 From Julien.Laganier@Sun.COM Tue Dec 2 09:20:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Dec 2 09:20:01 2003 Subject: [Hipsec] DH Group selection References: <3FCC7C27.3040907@hiit.fi> Message-ID: <3FCCA7A0.6050901@Sun.COM> Kristian Slavov wrote: > Hi, > > The latest draft, draft-moskowitz-hip-08, lists 8 DH groups. Are all > these groups required to be implemented, or just optional? Dunno... > If optional, how do we signal the responder that we do not support > certain DH group? Do the other implementations support all 8 groups? My implementation support 8 groups. If some DH groups are optionnal, perhaps the initiator needs to signal what DH groups it supports before receiving a DH from the responder. It means that the signalisation should be done in I1. Hence, since I1 isn't protected at all, this signal might be subject to a bidding down attack, by choosing 768 bits, right? So I don't know what to do with that. One solution might be to make group 1, 2, 3 and 4 (up to 2048 bits) mandatory so that the responder can freely choose a security level up to 2048 bits. When it'd be required to have more than 2048 bits, we can increment the HIP version number and make others DH groups mandatory... Thoughts? Thanks, --julien From rgm@htt-consult.com Tue Dec 2 12:44:00 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Tue Dec 2 12:44:00 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <3FCCA7A0.6050901@Sun.COM> References: <3FCC7C27.3040907@hiit.fi> <3FCCA7A0.6050901@Sun.COM> Message-ID: <6.0.1.1.2.20031202131552.03f9edf8@localhost> I am getting ready for a meeting, but IIRC, the DH group is selected in R1 and I2. the Responder supplies what it will play with and the initiator selects what it can deal with. At 06:23 AM 12/2/2003, Julien Laganier wrote: >Kristian Slavov wrote: >>Hi, >>The latest draft, draft-moskowitz-hip-08, lists 8 DH groups. Are all >>these groups required to be implemented, or just optional? > >Dunno... > >>If optional, how do we signal the responder that we do not support >>certain DH group? Do the other implementations support all 8 groups? > >My implementation support 8 groups. > >If some DH groups are optionnal, perhaps the initiator needs to signal >what DH groups it supports before receiving a DH from the responder. It >means that the signalisation should be done in I1. Hence, since I1 isn't >protected at all, this signal might be subject to a bidding down attack, >by choosing 768 bits, right? > >So I don't know what to do with that. One solution might be to make group >1, 2, 3 and 4 (up to 2048 bits) mandatory so that the responder can freely >choose a security level up to 2048 bits. When it'd be required to have >more than 2048 bits, we can increment the HIP version number and make >others DH groups mandatory... > >Thoughts? > >Thanks, > >--julien > >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Tue Dec 2 23:21:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Dec 2 23:21:01 2003 Subject: [Hipsec] DH Group selection Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > Sent: Tuesday, December 02, 2003 10:17 AM > To: Julien Laganier; Kristian Slavov > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] DH Group selection >=20 >=20 > I am getting ready for a meeting, but IIRC, the DH group is=20 > selected in R1=20 > and I2. >=20 > the Responder supplies what it will play with and the=20 > initiator selects=20 > what it can deal with. > The R1 could get large with public values if the responder=20 enumerates many possibilities. i) unlike other parameters, there is no "MUST" implement Group ID. We have been using the 1536-bit MODP group in interop testing-- perhaps require that one? Perhaps we could state that the R1 contains at most (two?) DIFFIE_HELLMAN TLVs, of which one must be the required group? If two are included, the non-mandatory Group ID is understood to be the responder's preferred selection? An alternative would be to require that initiators support all Group IDs, and have the R1 just send a single TLV. Or else Julien's suggestion of signaling in I1 (with the=20 resultant bid-down problem to deal with). ii) there should be some text describing how the D-H TLV is inserted and processed. e.g. according to above: =20 "Responder includes in R1 a DIFFIE_HELLMAN TLV for at most two Group ID that it can support. The 1536-bit=20 MODP group MUST be among the one or two TLVs. If two TLVs are present, the second TLV corresponds to the=20 responder's preferred Group ID if different from the=20 mandatory Group ID." "Initiator selects, from among the DIFFIE_HELLMAN TLVs sent in the R1, a single Group ID and public value, and=20 sends only a single DIFFIE_HELLMAN TLV (corresponding to the selected Group ID and its own public value) in=20 the I2. The 1536-bit MODP group MUST be supported. The initiator SHOULD select the responder's preferred=20 TLV unless it conflicts with local policy rules or=20 is not supported by the implementation." =20 From petri.jokela@nomadiclab.com Wed Dec 3 03:10:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Dec 3 03:10:01 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> Message-ID: <1070441072.13767.15.camel@n69> On Wed, 2003-12-03 at 06:54, Henderson, Thomas R wrote: > The R1 could get large with public values if the responder > enumerates many possibilities. > > i) unlike other parameters, there is no "MUST" implement > Group ID. We have been using the 1536-bit MODP group in > interop testing-- perhaps require that one? > > Perhaps we could state that the R1 contains at most (two?) > DIFFIE_HELLMAN TLVs, of which one must be the required > group? If two are included, the non-mandatory Group ID > is understood to be the responder's preferred selection? This could be one possibility. With the currently specified one D_H TLV there is no idea of putting any of the groups mandatory. > An alternative would be to require that initiators support > all Group IDs, and have the R1 just send a single TLV. This would be the best solution (I think). The Responder is the "king" of the communication, thus it defines the group to be used. > Or else Julien's suggestion of signaling in I1 (with the > resultant bid-down problem to deal with). This has some effect on the Responder side. Currently, the Responder doesn't have to do "anything" when I1 is received. Just pull one R1 and send it back. If there is a set of group-ids in the I1, the Responder must do some processing before it can send the R1. /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 Julien.Laganier@Sun.COM Wed Dec 3 04:16:02 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Dec 3 04:16:02 2003 Subject: [Hipsec] DH Group selection References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> Message-ID: <3FCDB1E5.6030909@Sun.COM> Petri Jokela wrote: > On Wed, 2003-12-03 at 06:54, Henderson, Thomas R wrote: > > >>The R1 could get large with public values if the responder >>enumerates many possibilities. >> >>i) unlike other parameters, there is no "MUST" implement >>Group ID. We have been using the 1536-bit MODP group in >>interop testing-- perhaps require that one? >> >>Perhaps we could state that the R1 contains at most (two?) >>DIFFIE_HELLMAN TLVs, of which one must be the required >>group? If two are included, the non-mandatory Group ID >>is understood to be the responder's preferred selection? > > > This could be one possibility. With the currently specified > one D_H TLV there is no idea of putting any of the groups > mandatory. > > >>An alternative would be to require that initiators support >>all Group IDs, and have the R1 just send a single TLV. > > > This would be the best solution (I think). The Responder > is the "king" of the communication, thus it defines the > group to be used. > > >>Or else Julien's suggestion of signaling in I1 (with the >>resultant bid-down problem to deal with). > > > This has some effect on the Responder side. Currently, > the Responder doesn't have to do "anything" when I1 is > received. Just pull one R1 and send it back. If there is > a set of group-ids in the I1, the Responder must do some > processing before it can send the R1. If the responder precomputed eight R1 with the eigth differents possibles DH TLV's, it doesn't seems to require additionnal processing on the receiver side compared to the current behavior. But AFAICS, the only defense against the bid-down attack of this scheme would be to specify a minimum security level that must be supported (says 1536). Thus, the security level cannot be bid-down to less than 1536, while not precluding the responder from choosing a lower security level if it wants to (after all he's the king). --julien From Julien.Laganier@Sun.COM Wed Dec 3 04:17:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Dec 3 04:17:00 2003 Subject: [Hipsec] DH Group selection References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> Message-ID: <3FCDB206.6060307@Sun.COM> Petri Jokela wrote: > On Wed, 2003-12-03 at 06:54, Henderson, Thomas R wrote: > > >>The R1 could get large with public values if the responder >>enumerates many possibilities. >> >>i) unlike other parameters, there is no "MUST" implement >>Group ID. We have been using the 1536-bit MODP group in >>interop testing-- perhaps require that one? >> >>Perhaps we could state that the R1 contains at most (two?) >>DIFFIE_HELLMAN TLVs, of which one must be the required >>group? If two are included, the non-mandatory Group ID >>is understood to be the responder's preferred selection? > > > This could be one possibility. With the currently specified > one D_H TLV there is no idea of putting any of the groups > mandatory. > > >>An alternative would be to require that initiators support >>all Group IDs, and have the R1 just send a single TLV. > > > This would be the best solution (I think). The Responder > is the "king" of the communication, thus it defines the > group to be used. > > >>Or else Julien's suggestion of signaling in I1 (with the >>resultant bid-down problem to deal with). > > > This has some effect on the Responder side. Currently, > the Responder doesn't have to do "anything" when I1 is > received. Just pull one R1 and send it back. If there is > a set of group-ids in the I1, the Responder must do some > processing before it can send the R1. If the responder precomputed eight R1 with the eigth differents possibles DH TLV's, it doesn't seems to require additionnal processing on the receiver side compared to the current behavior. But AFAICS, the only defense against the bid-down attack of this scheme would be to specify a minimum security level that must be supported (says 1536). Thus, the security level cannot be bid-down to less than 1536, while not precluding the responder from choosing a lower security level if it wants to (after all he's the king). --julien From petri.jokela@nomadiclab.com Wed Dec 3 06:57:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Dec 3 06:57:01 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <3FCDB206.6060307@Sun.COM> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> Message-ID: <1070454701.13761.142.camel@n69> On Wed, 2003-12-03 at 11:51, Julien Laganier wrote: > > This has some effect on the Responder side. Currently, > > the Responder doesn't have to do "anything" when I1 is > > received. Just pull one R1 and send it back. If there is > > a set of group-ids in the I1, the Responder must do some > > processing before it can send the R1. > > If the responder precomputed eight R1 with the eigth differents > possibles DH TLV's, it doesn't seems to require additionnal processing > on the receiver side compared to the current behavior. The "hint" field in the I1 would require one additional TLV that would be included in the I1 packet. The processing of this TLV must be done like the processing of other TLVs. The role of the I1 packet also changes from a simple wake-up packet to a negotiation packet. > But AFAICS, the only defense against the bid-down attack of this scheme > would be to specify a minimum security level that must be supported > (says 1536). Thus, the security level cannot be bid-down to less than > 1536, while not precluding the responder from choosing a lower security > level if it wants to (after all he's the king). If we set a minimum security value, there is no reason why the responder would go below that. In fact, the responder should never go below the security level that is configured on it as the default. Thus, the negotiation would make sense only in case when the initiator requires higher security than the responder would by default propose. My feeling is that negotiation would make things a bit more complicated, when compared to the requirement that everyone must implement all the groups, responder selects the one that it want's to use and the initiator either accepts or rejects the proposal that arrived in the R1 packet. As I wrote earlier, there is the problem, how to kick the responder to go for better security than it's default value, if required by the initiator. /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 pekka.nikander@nomadiclab.com Thu Dec 4 10:42:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Dec 4 10:42:01 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <1070454701.13761.142.camel@n69> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> Message-ID: <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> On Dec 3, 2003, at 14:31, Petri Jokela wrote: > If we set a minimum security value, there is no reason why the > responder would go below that. In fact, the responder should never go > below the security level that is configured on it as the default. Yes, there is: performance. Some servers might prefer very short D-H keys for performance reasons. That is, some servers might opt to use HIP mainly for mobility and multi-homing reasons, or some other reasons but security, and want to use fairly short D-H keys that just make MitM attacks hard but not impossible > My feeling is that negotiation would make things a bit more > complicated, I agree. How about if Initiators MUST implement two groups, one that is reasonable strong and another one that is fairly weak, maybe deliberately "too" weak from a strict security point of view. A Responder would then be free to use either of these? That would prevent bidding-down attacks since all Initiators MUST implement also the stronger one, allowing the Responder to select it if it wishes to have good security. This could be combined with a simple (optional) I1 parameter that would simply list what groups the Initiator support. However, I don't see much usability for such. Usually, using any other than mandatory groups would be based on mutual agreement, i.e. the Responder recognizing the Initiator HIT. --Pekka Nikander From jeffrey.m.ahrenholz@boeing.com Thu Dec 4 12:19:00 2003 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Thu Dec 4 12:19:00 2003 Subject: [Hipsec] DH Group selection Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2703C4966D@xch-nw-09.nw.nos.boeing.com> > > My feeling is that negotiation would make things a bit more > > complicated, >=20 > I agree. >=20 My vote is that we leave the I1 alone. It seems that the existing = implementations support all (most?) of the DH groups. As far as what = MUST be supported, I think that two group idea might suffice, or just = require support of all the groups. As Petri said, since the Responder is = "king", the Initiator could just be stuck with whatever the Responder = decides inside the R1. -Jeff From jrh@it.uc3m.es Thu Dec 4 14:56:02 2003 From: jrh@it.uc3m.es (Juan Rodriguez Hervella) Date: Thu Dec 4 14:56:02 2003 Subject: [Hipsec] Status of the HIP implementation for BSD Message-ID: <200312042130.40276.jrh@it.uc3m.es> Hello, I'd like to know when the status of the implementation for BSD will be released. Is an open source project ? Can anybody make contributions to it ? Thanks! -- ****** JFRH ****** From Julien.Laganier@Sun.COM Fri Dec 5 03:23:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Dec 5 03:23:01 2003 Subject: [Hipsec] DH Group selection References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> Message-ID: <3FD0487E.9030007@Sun.COM> Pekka Nikander wrote: > On Dec 3, 2003, at 14:31, Petri Jokela wrote: > >> If we set a minimum security value, there is no reason why the >> responder would go below that. In fact, the responder should never go >> below the security level that is configured on it as the default. > > > Yes, there is: performance. Some servers might prefer very > short D-H keys for performance reasons. That is, some servers > might opt to use HIP mainly for mobility and multi-homing reasons, > or some other reasons but security, and want to use fairly short > D-H keys that just make MitM attacks hard but not impossible I agree. >> My feeling is that negotiation would make things a bit more >> complicated, > > > I agree. Me too. > How about if Initiators MUST implement two groups, one > that is reasonable strong and another one that is fairly > weak, maybe deliberately "too" weak from a strict > security point of view. A Responder would then be free > to use either of these? That would prevent bidding-down > attacks since all Initiators MUST implement also the > stronger one, allowing the Responder to select it if it > wishes to have good security. Sounds good to me. > This could be combined with a simple (optional) I1 parameter > that would simply list what groups the Initiator support. > However, I don't see much usability for such. Usually, > using any other than mandatory groups would be based on > mutual agreement, i.e. the Responder recognizing the > Initiator HIT. If there are two mandatory security level (a weak and a strong), I agree that an optionnal I1 "DH group hint" would probably not be very useful. So let's keep I1 simple and make two DH groups mandatory. What are we going to require? I guess 1 and 3 (or 4)? Thanks, --julien From pekka.nikander@nomadiclab.com Fri Dec 5 04:24:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 5 04:24:00 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <3FD0487E.9030007@Sun.COM> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> <3FD0487E.9030007@Sun.COM> Message-ID: <9F494C02-2709-11D8-8F28-000393CE1E8C@nomadiclab.com> On Dec 5, 2003, at 10:57, Julien Laganier wrote: >> How about if Initiators MUST implement two groups, one >> that is reasonable strong and another one that is fairly >> weak, maybe deliberately "too" weak from a strict >> security point of view. >> > Sounds good to me. > > So let's keep I1 simple and make two DH groups mandatory. What are we > going to require? I guess 1 and 3 (or 4)? I would suggest 1 and 3, with 6 as a strong SHOULD, meaning that only PDAs and such may consider not to implement it. Then when we start to consider 4 weak we can fairly easily upgrade to 6. All others would be OPTIONAL to implement. Or should we define yet another group that would be still weaker than 1? Has anyone got performance figures for 1, preferably both on slow (100 Mhz, PDA) and fast (2 GHz+, server) hardware? BTW, at least in -08 there seems to be a typo. Aren't MODP 1536 Oakley group 3, not Oakley group 5? --Pekka From Julien.Laganier@Sun.COM Fri Dec 5 09:31:02 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Dec 5 09:31:02 2003 Subject: [Hipsec] DH Group selection References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> <3FD0487E.9030007@Sun.COM> <9F494C02-2709-11D8-8F28-000393CE1E8C@nomadiclab.com> Message-ID: <3FD09EA8.2040201@Sun.COM> Pekka Nikander wrote: > > On Dec 5, 2003, at 10:57, Julien Laganier wrote: > >>> How about if Initiators MUST implement two groups, one >>> that is reasonable strong and another one that is fairly >>> weak, maybe deliberately "too" weak from a strict >>> security point of view. >>> >> Sounds good to me. >> >> So let's keep I1 simple and make two DH groups mandatory. What are we >> going to require? I guess 1 and 3 (or 4)? > > > I would suggest 1 and 3, with 6 as a strong SHOULD, meaning > that only PDAs and such may consider not to implement it. > Then when we start to consider 4 weak we can fairly easily > upgrade to 6. All others would be OPTIONAL to implement. Fine. > Or should we define yet another group that would be still > weaker than 1? Has anyone got performance figures for 1, > preferably both on slow (100 Mhz, PDA) and fast (2 GHz+, > server) hardware? I found in google that Id 1, 768-bit takes about 5.75 seconds on an Intel StrongARM PDA processor, but the frequency wasn't indicated (I guess it's about 100MhZ). It seems acceptable. Another way of supporting slow devices might be to support Elliptic Curve DH exchange (Id 3 and 4 in RFC2409) which seems to be faster and smaller... > BTW, at least in -08 there seems to be a typo. > Aren't MODP 1536 Oakley group 3, not Oakley group 5? I don't think so. Quoting RFC3526: -------------------------------- 2. 1536-bit MODP Group The 1536 bit MODP group has been used for the implementations for quite a long time, but was not defined in RFC 2409 (IKE). Implementations have been using group 5 to designate this group, we standardize that practice here. -------------------------------- And then 2048-bit has id 14, 3072 has 15, 4096 has 16, etc. --julien From pekka.nikander@nomadiclab.com Fri Dec 5 10:33:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 5 10:33:01 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <3FD09EA8.2040201@Sun.COM> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> <3FD0487E.9030007@Sun.COM> <9F494C02-2709-11D8-8F28-000393CE1E8C@nomadiclab.com> <3FD09EA8.2040201@Sun.COM> Message-ID: <2BA25560-273D-11D8-AF73-000393CE1E8C@nomadiclab.com> On Dec 5, 2003, at 17:05, Julien Laganier wrote: >> BTW, at least in -08 there seems to be a typo. >> Aren't MODP 1536 Oakley group 3, not Oakley group 5? > > I don't think so. Quoting RFC3526: > > -------------------------------- > 2. 1536-bit MODP Group > > The 1536 bit MODP group has been used for the implementations for > quite a long time, but was not defined in RFC 2409 (IKE). > Implementations have been using group 5 to designate this group, we > standardize that practice here. > -------------------------------- You are right. I got confused since RFC2412 first states... > APPENDIX E The Well-Known Groups > > The group identifiers: > > 0 No group (used as a placeholder and for non-DH exchanges) > 1 A modular exponentiation group with a 768 bit modulus > 2 A modular exponentiation group with a 1024 bit modulus > 3 A modular exponentiation group with a 1536 bit modulus (TBD) > 4 An elliptic curve group over GF[2^155] > 5 An elliptic curve group over GF[2^185] ... but then later ... > E.5. Well-Known Group 5: A 1536 bit prime Hence, RFC2412 is internally inconsistent, and apparently the real definition matters, not the list of groups at the beginning of Appendix E. --Pekka From pekka.nikander@nomadiclab.com Sat Dec 6 05:42:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Dec 6 05:42:01 2003 Subject: [Hipsec] Status of the HIP implementation for BSD In-Reply-To: <200312042130.40276.jrh@it.uc3m.es> References: <200312042130.40276.jrh@it.uc3m.es> Message-ID: On Dec 4, 2003, at 22:30, Juan Rodriguez Hervella wrote: > > I'd like to know when the status of the implementation > for BSD will be released. We have been working towards a release. Our original goal was the end of October, but there has been a large number of small issues that each have delayed the process. Anyway, as far as I know, the release should be any day now. On the other hand, it is better that I do not state any fixed dates any more, since such promises would be empty, given the experience so far. > Is an open source project ? Can anybody make contributions > to it ? The initial release will basically be a snapshot of our current development. The code will be released under a new license that should be open source compatible but does not have open source status, at least not yet. Once the code is out, we would be happy to see anyone to use it. We will also accept bug fixes and integrate them to the code. However, since at this time we will be only releasing time-to-time snapshots, I'm afraid that doing any larger modifications may be hard. At some future date we may put up a live repository in a public access CVS site, but that depends largely on how much demand there would be for such a service. --Pekka Nikander From petri.jokela@nomadiclab.com Sat Dec 6 06:13:00 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Sat Dec 6 06:13:00 2003 Subject: [Hipsec] DH Group selection In-Reply-To: <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1B5@xch-nw-27.nw.nos.boeing.com> <1070441072.13767.15.camel@n69> <3FCDB206.6060307@Sun.COM> <1070454701.13761.142.camel@n69> <22626E90-2675-11D8-8F28-000393CE1E8C@nomadiclab.com> Message-ID: On Thu, 4 Dec 2003, Pekka Nikander wrote: > > On Dec 3, 2003, at 14:31, Petri Jokela wrote: > > If we set a minimum security value, there is no reason why the > > responder would go below that. In fact, the responder should never go > > below the security level that is configured on it as the default. > > Yes, there is: performance. Some servers might prefer very > short D-H keys for performance reasons. That is, some servers > might opt to use HIP mainly for mobility and multi-homing reasons, > or some other reasons but security, and want to use fairly short > D-H keys that just make MitM attacks hard but not impossible Yes, but then that lower security is the default for that server. If not, then the server must do some decision making already when the I1 packet is received. This must be based on the HIT in the I1 packet. Does this create problems with large servers with lots of traffic? > > My feeling is that negotiation would make things a bit more > > complicated, > > I agree. > > How about if Initiators MUST implement two groups, one > that is reasonable strong and another one that is fairly > weak, maybe deliberately "too" weak from a strict > security point of view. A Responder would then be free > to use either of these? That would prevent bidding-down > attacks since all Initiators MUST implement also the > stronger one, allowing the Responder to select it if it > wishes to have good security. If we decide to select two mandatory groups and one as a SHOULD with better security (I refer to your other e-mail) what will happen to the rest of the grouups? I just feel that either they become "de facto" mandatory if servers start to use them more (otherwise it may be difficult to contact some servers that use non-mandatory groups as default) or then these non-mandatory groups will just not be used. One problem is that the server never learns who actually responds and who not to some R1 packets as it does not keep any information about the I1s and R1s. So, the server should make HIT based decisions and it should be told which of the HITs should use these non-mandatory groups. I think that if the two (+ one) mandatory groups are decent, the operators (server maintainers) use only the mandatory and nothing else. People are lazy by their nature :-) > This could be combined with a simple (optional) I1 parameter > that would simply list what groups the Initiator support. > However, I don't see much usability for such. Usually, > using any other than mandatory groups would be based on > mutual agreement, i.e. the Responder recognizing the > Initiator HIT. The GPRS is just too slow for this ssh-connection, so I won't fix any typos :-) /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 pekka.nikander@nomadiclab.com Mon Dec 8 14:22:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 8 14:22:01 2003 Subject: [Hipsec] Tentative minutes for the Minneapolis BOF Message-ID: A tentative version of the HIPBOF minutes are now available at http://www.tml.hut.fi/~pnr/HIP/ietf58_hipbof_minutes.html Please send any corrections before or on Dec 14th. I will send the minutes to the secretariat on Dec 15th, to be included into the proceedings. --Pekka Nikander From Jan.Melen@nomadiclab.com Tue Dec 9 03:29:00 2003 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Tue Dec 9 03:29:00 2003 Subject: [Hipsec] HIP for *BSD release Message-ID: <200312091103.40150.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Our first HIP release is now available at:=20 http://www.hip4inter.net/download.shtml Currently it is a patch file that can be applied on FreeBSD 5.1-p10 sources. B.R. HIP for *BSD team =2D --=20 Jan M. Mel=E9n Research Scientist NomadicLab, IP Networks Ericsson Research Oy LM Ericsson Ab Telecom R&D Tel: +358 9 299 3056 =46ax: +358 9 299 2448 Mobile: +358 400 83 6926 Jan.Melen@ericsson.com http://www.ericsson.com =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/1Y/mp4iklvjQtTgRApoNAKC2Gnl3EMf50INa5DyTRrd6S3urjQCghZxa bR7j8v3e4eGVDMnjrzqg9mo=3D =3DteKA =2D----END PGP SIGNATURE----- From shep@alum.mit.edu Tue Dec 9 09:29:00 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Tue Dec 9 09:29:00 2003 Subject: [Hipsec] HIP for *BSD release In-Reply-To: Your message of Tue, 09 Dec 2003 11:03:28 +0200. <200312091103.40150.Jan.Melen@nomadiclab.com> Message-ID: > Our first HIP release is now available at:=20 > http://www.hip4inter.net/download.shtml > > Currently it is a patch file that can be applied on FreeBSD 5.1-p10 sources. > This is great, and I know that some of you have worked very hard and very long to make this happen. Unfortunately, the license appears to be new (is not one of the 47 licenses already recognized by opensource.org), and it is going to take a while to understand it. It would help me (and I expect others) if you would explain why it was necessary to reject the 47 licenses already recognized by opensource.org and develop yet another. In particular, do you believe you could (and is it perhaps your intent to) get this license approved using the opensource.org certification process? (See http://opensource.org/docs/certification_mark.php ). -Tim Shepard shep@alum.mit.edu From Julien.Laganier@Sun.COM Tue Dec 9 09:58:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Dec 9 09:58:00 2003 Subject: [Hipsec] Issue #5: state machine bug Message-ID: <200312091632.09584.julien.laganier@sun.com> --Boundary_(ID_Pv4SwYj7PzIwH41YCU7y+g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Folks, Getting back to issue #5, I've tried to add a new substate to the state machine (E4-resync) to be able to receive R2 when the corresponent node rebooted and send R1 in reply to an ESP packet with unknown SPI. I also renamed E4 in E4-rekey to avoid creating to much substates, as per Pekka's suggestion. Let's try to describe the approach: The new state machine transitions to E4-resync while in E3 or E4-rekey, upon recept of a valid R1 which succesfully passed through SA and birthday check. The new substate E4-resync is pretty similar to E3, except that R2 is accepted. A counter is fired when transitionning to E4-resync, and when timeout is occuring the state machine go back to E3. Note that E4-rekey and E4-resync might be better named E3-rekey and E3-resync... I dunno. The remaining question is whether or not a state machine need to go back to E4-rekey while in E4-resync and timeout. If it is the case, I guess we need to split E4-resync in E4-resync and E4-resync-while-rekey, both reached upon recept of a R1 while being in resp. E4-rekey and E3. If we split E4-resync, perhaps we can keep the original E4 state (rekeying), and then name the new two substates E3-resync (resync when in E3) and E4-rekey (resync when rekeying in E4). If you a few spare minutes, please take a look at the attached modified state machine describing the first approach, compare it with the original one, and let me know your thoughts about it. Thanks, --julien --Boundary_(ID_Pv4SwYj7PzIwH41YCU7y+g) Content-type: text/plain; charset=us-ascii; name=STATE Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=STATE 5.4.1 HIP States E0 State machine start E1 Initiating HIP E2 Waiting to finish HIP E3 HIP SA established E4-rekey HIP SA established, rekeying E4-resync HIP SA established, resynchronizing with rebooted correspondent E-FAILED HIP SA establishment failed 5.4.2 HIP State Processes +---------+ | E0 | Start state +---------+ Datagram to send, send I1 and go to E1 Receive I1, send R1 and stay at E0 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E0 Receive ESP for unknown SA, send R1 and stay at E0 Receive ANYOTHER, drop and stay at E0 +---------+ | E1 | Initiating HIP +---------+ Receive I1, send R1 and stay at E1 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E1 Receive R1, process if successful, send I2 and go to E2 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E1 Timeout, increment timeout counter If counter is less than I1_RETRIES_MAX, send I1 and stay at E1 If counter is greater than I1_RETRIES_MAX, go to E-FAILED +---------+ | E2 | Waiting to finish HIP +---------+ Receive I1, send R1 and stay at E2 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E2 Receive R2, process if successful, go to E3 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E2 Timeout, increment timeout counter If counter is less than I2_RETRIES_MAX, send I2 and stay at E2 If counter is greater than I2_RETRIES_MAX, go to E-FAILED +---------+ | E3 | HIP SA established +---------+ Receive I1, send R1 and stay at E3 Receive I2, process with Birthday check if successful, send R2, drop old SA and cycle at E3 if fail, stay at E3 Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and go to E4-resync if fail, stay at E3 Receive R2, drop and stay at E3 Receive ESP for SA, process and stay at E3 Receive NES, process if successful, send NES and stay at E3 if failed, stay at E3 Need rekey, send NES and go to E4-rekey +---------+ |E4-rekey | HIP SA established, rekey pending +---------+ Receive I1, send R1 and stay at E4-rekey Receive I2, process with Birthday check if successful, send R2, drop old SA and go to E3 if fail, stay at E4-rekey Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and go to E4-resync if fail, stay at E4-rekey Receive R2, drop and stay at E4-rekey Receive ESP for SA, process and stay at E4-rekey Receive NES, process if successful, replace SAs and go to E3 if failed, stay at E4-rekey Timeout, increment timeout counter If counter is less than NES_RETRIES_MAX, send NES and stay at E4-rekey If counter is greater than NES_RETRIES_MAX, go to E-FAILED +---------+ |E4-resync| HIP SA established, resync pending +---------+ Receive I1, send R1 and cycle at E4-resync Receive I2, process with Birthday check if successful, send R2, drop old SA and go to E3 if fail, stay at E4-resync Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and cycle at E4-resync if fail, stay at E4-resync Receive R2, process with SA and Birthday check if successful, go to E3 if fail, stay at E4-resync Receive ESP for SA, process and go to E3 Receive NES, process if successful, send NES and go to E3 if failed, stay at E4-resync Timeout, increment timeout counter If counter is less than RESYNC_RETRIES_MAX, send I2 and stay at E4-resync If counter is greater than RESYNC_RETRIES_MAX, go to E3 5.4.3 Simplified HIP State Diagram Receive packets cause a move to a new state. +---------+ | E0 |>---+ +---------+ | | ^ | | | | | Dgm to | +-+ | send | I1 | | (note: ESP- means ESP with unknown SPI) ESP- | | v | +---------+ | | E1 |>---|----------+ +---------+ | | | | | | R1 | | | |I2 |I2 v | | +---------+ | | | E2 |>---|----------|-----+ | | | | | +---------+ | | | | | | | | R2 | | |I2 | | | | v | | | +---------+<---+ | | | | | | | E3 |<--------------+ | | |<--------------------+ | |<--------------------+ | |---------------+ | | |<-------+ | | | |----+ | | | +---------+ | | | | | ^ ^ | | | | | | | | | | | +--+ | | | | | ESP, | rekey| |I2 | | NES, | | | | | I1, |NES | | | | I2 | | | | | | | | | | | | | | | +---------+ | | | | | |<---+ | | | |E4-rekey |>-------+ | | +---------+ | | | ^ v | | I2, R2, ESP | | | R1 | | NES, Timeout +--+ | | | ESP, | | | I1 | | | | v ^ | R1 +---------+ +-------------->| | |E4-resync| +---------+ | ^ | | +--+ I1, R1 --Boundary_(ID_Pv4SwYj7PzIwH41YCU7y+g) Content-type: application/x-trash; name=STATE.old Content-transfer-encoding: 7bit Content-disposition: attachment; filename=STATE.old 5.4.1 HIP States E0 State machine start E1 Initiating HIP E2 Waiting to finish HIP E3 HIP SA established E4 HIP SA established, rekeying E-FAILED HIP SA establishment failed 5.4.2 HIP State Processes +---------+ | E0 | Start state +---------+ Datagram to send, send I1 and go to E1 Receive I1, send R1 and stay at E0 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E0 Receive ESP for unknown SA, send R1 and stay at E0 Receive ANYOTHER, drop and stay at E0 +---------+ | E1 | Initiating HIP +---------+ Receive I1, send R1 and stay at E1 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E1 Receive R1, process if successful, send I2 and go to E2 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E1 Timeout, increment timeout counter If counter is less than I1_RETRIES_MAX, send I1 and stay at E1 If counter is greater than I1_RETRIES_MAX, go to E-FAILED +---------+ | E2 | Waiting to finish HIP +---------+ Receive I1, send R1 and stay at E2 Receive I2, process if successful, send R2 and go to E3 if fail, stay at E2 Receive R2, process if successful, go to E3 if fail, go to E-FAILED Receive ANYOTHER, drop and stay at E2 Timeout, increment timeout counter If counter is less than I2_RETRIES_MAX, send I2 and stay at E2 If counter is greater than I2_RETRIES_MAX, go to E-FAILED +---------+ | E3 | HIP SA established +---------+ Receive I1, send R1 and stay at E3 Receive I2, process with Birthday check if successful, send R2, drop old SA and cycle at E3 if fail, stay at E3 Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and cycle at E3 if fail, stay at E3 Receive R2, drop and stay at E3 Receive ESP for SA, process and stay at E3 Receive NES, process if successful, send NES and stay at E3 if failed, stay at E3 Need rekey, send NES and go to E4 +---------+ | E4 | HIP SA established, rekey pending +---------+ Receive I1, send R1 and stay at E4 Receive I2, process with Birthday check if successful, send R2, drop old SA and go to E3 if fail, stay at E4 Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and go to E3 if fail, stay at E4 Receive R2, drop and stay at E4 Receive ESP for SA, process and stay at E4 Receive NES, process if successful, replace SAs and go to E3 if failed, stay at E4 Timeout, increment timeout counter If counter is less than NES_RETRIES_MAX, send NES and stay at E4 If counter is greater than NES_RETRIES_MAX, go to E-FAILED 5.4.3 Simplified HIP State Diagram Receive packets cause a move to a new state. +---------+ | E0 |>---+ +---------+ | | ^ | | | | | Dgm to | +-+ | send | I1 | | (note: ESP- means ESP with unknown SPI) ESP- | | v | +---------+ | | E1 |>---|----------+ +---------+ | | | | | | R1 | | | |I2 |I2 v | | +---------+ | | | E2 |>---|----------|-----+ | | | | | +---------+ | | | | | | | | R2 | | |I2 | | | | v | | | +---------+<---+ | | | | | | | E3 |<--------------+ | | |<--------------------+ | |<-------+ | |----+ | +---------+ | | | ^ ^ | | | | | | | +--+ | | | ESP, | rekey| |R1,I2 NES, | | | I1, |NES | | I2, | | | R1 | | | | | | +---------+ | | | |<---+ | | E4 |>-------+ +---------+ | ^ | | +--+ ESP, I1, --Boundary_(ID_Pv4SwYj7PzIwH41YCU7y+g)-- From pekka.nikander@nomadiclab.com Tue Dec 9 11:02:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 9 11:02:01 2003 Subject: [Hipsec] Moving NES_INFO before Diffie-Hellman Message-ID: I'd like to move the NES_INFO parameter so that it always preceeds the Diffie-Hellman parameter. That would make middlebox implementation slightly easier, since middle-boxes need to track NES_INFO but they do not need to care about Diffie-Hellman. The change would also make it easier to include several REA parameters in a single NES packet. Hence, the new type values would be something like NES_INFO 9 Old SPI, New SPI and other info needed for NES DIFFIE_HELLMAN 13 variable public key The new format for the NES packet would be IP ( HIP ( NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) Then, when REA is included, it would be IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) This may require some changes to the NES processing logic on some implementations, but that shouldn't be too hard, since the end-hosts need to scan for the HMAC before processing the NES_INFO anyway. Any thoughts? --Pekka Nikander From pekka.nikander@nomadiclab.com Tue Dec 9 11:27:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 9 11:27:01 2003 Subject: [Hipsec] HIP for *BSD release In-Reply-To: References: Message-ID: <5A5727D0-2A69-11D8-B29C-000393CE1E8C@nomadiclab.com> Tim, On Dec 9, 2003, at 17:03, Tim Shepard wrote: > Unfortunately, the license appears to be new (is not one of the 47 > licenses already recognized by opensource.org), and it is going to > take a while to understand it. It would help me (and I expect others) > if you would explain why it was necessary to reject the 47 licenses > already recognized by opensource.org and develop yet another. I didn't follow the process too closely, and therefore I may be missing something. However, my understanding is that GPL or the other "free" licenses were felt inappropriate. It might have been possible to use any of the Mozilla/Apple/Nokia/etc licenses other than that there might have been IPR and public relationship issues about using the license itself. That is, not about the conditions in the license but the intellectual property (copyright) possibly applied to the actual license text itself, and/or the publicity issues created if Ericsson would have used a license that carries the name of another corporation. Hence, my understanding is that the local lawyers felt that creating a new license is the "safest" way, for Ericsson Finland, to avoid possible problems with existing licenses. We know very well that this is a problem from the open source community point of view, but it has been hard enough for us to get a permission to publish the code in the first place. > In particular, do you believe you could (and is it perhaps your intent > to) get this license approved using the opensource.org certification > process? (See http://opensource.org/docs/certification_mark.php ). The intention was and is that the license would be compatible with the OSI open source license approval criteria. However, at this time there are no concrete plans to apply for approval. On the other hand, Ericsson is working on its open source strategy on the corporate level, and it is possible that we might get an OSI approved corporate wide open source license at some point of time (but don't hold your breath). If we get one, we will almost certainly change the licensing to use such a license. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Dec 10 07:01:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 10 07:01:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? Message-ID: As I am working on the revised Mobility and Multi-homing scheme, I have come to a tentative conclusion that it might be good to introduce a new HIP control or alternatively take one bit from the packet Type field into use. I would also like to rename the "New SPI" (NES) packet into a more generic "Update" (UPD) packet, since it looks like a good candidate for various kinds of updates, not just SA updates but also readdressing updates and probably other kinds of updates in the future. Furthermore, if we decide to rename the NES packet into a UPD packet, we can also rename the NES_INFO parameter into a NES parameter, just for simplicity. New control option ------------------ The currently defined controls are the following: C - CER packets follow E - Use 64-bit ESP sequence numbers A - The sender's HIT is anonymous (Actually the E control should be part of the ESP transform parameter and not a control, but that is a different issue.) I would now like to include a new control R - A reply is requested This control would always be set in I1, R2, and I2, and (almost) never in R2. However, it looks like that it would be fairly useful in NES and BOS, at least. Allocating a bit from the packet type option -------------------------------------------- The alternative is to allocate a bit in the Packet type field. Currently the packet type is 8 bits, with no bits having any special meaning. We could now take let's say the lowest bit and use it to indicate whether the sender of the packets expects a reply or not. This would result in the following changes to the packet types: Packet Current type New type I1 1 1 R1 2 3 I2 3 5 R2 4 6 NES 5 8/9 BOS 7 10/11 CER 8 12 PAYLOAD 64 64 More background --------------- The current NES_INFO parameter includes an explicit R-bit, which indicates whether a NES packet is a reply to a previous NES packet or an initial NES packet. In practical terms, it can also be understood as indicating whether a NES reply is needed or not. Now, in the mobility & multi-homing case it has turned out that it is sometimes necessary to create a new SA or multiple new SAs whenever a host changes its connectivity. Therefore we sometimes want to send multiple NES_INFO parameters in one packet. Having the R-bit in the NES_INFO does not make any sense any more. It is really a packet level thing, not a per SPI thing. It also looks like that it would be sometimes useful to introduce new SAs unidirectionally. That is, in certain readdressing situations you really want to update the SA only in one direction and not in another. Therefore it probably makes sense to send NES (or UPD) packets that contain REA and NES_INFO parameters, indicating that the recipient should update the *outgoing* SAs related to the interface identified by the REA, but does not need to really rekey or change its incoming SAs. I also think that having a generic update utility with different kinds of parameters (NES, REA, etc) that indicate what is to be updated creates a more orthogonal micro- architecture within the actual protocol. The obvious counter-argument is, of course, that such orthogonality and generality may create unnecessary complexity. However, in this specific case I don't see that much more complexity. Indeed, a well written implementation may become less complex since it may require less code for handling various cases. Both of the schemes have the added benefit that it would allow sending I1s just to tell one's HIT (a kind of minimal BOS without the actual HI or signature), or maybe to send those R1s that are sent in response to unknown SPIs with the reply requested bit off? Especially the ability to send I1s with no reply requested might be beneficial for delayed HIP context setup; a feature that seems useful from multi6 point of view. Any thoughts? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Dec 10 07:01:05 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 10 07:01:05 2003 Subject: [Hipsec] Issue #5: state machine bug In-Reply-To: <200312091632.09584.julien.laganier@sun.com> References: <200312091632.09584.julien.laganier@sun.com> Message-ID: <5891BC02-2B0D-11D8-9D76-000393CE1E8C@nomadiclab.com> > Getting back to issue #5, I've tried to add a new substate to the state > machine (E4-resync) to be able to receive R2 when the corresponent node > rebooted and send R1 in reply to an ESP packet with unknown SPI. In general, looks very good. > The new state machine transitions to E4-resync while in E3 or > E4-rekey, upon > recept of a valid R1 which succesfully passed through SA and birthday > check. > The new substate E4-resync is pretty similar to E3, except that R2 is > accepted. A counter is fired when transitionning to E4-resync, and when > timeout is occuring the state machine go back to E3. I think this is the correct approach. Minor comments: - since receiving R1 in E3 already causes the state machine to prepare to drop the old SAs, I don't think that we need to do that again if we receive another R1 in the E4-resync state. Furthermore, since it is possible that the first I2 that was sent when going to E4-resync may have been lost, I think that the Birthday check should be dropped here. With these changes, the new R1 rule would become as follows: Receive R1, if similar to one that caused transition to E4-resync, resend I2 and cycle at E4-resync if passes SA and Birthday checks, send I2, and cycle at E4-resync otherwise, stay at E4-resync - The rule for R2 looks like inaccurate since it does not contain a birthday parameter. I think you need to reword it somehow. > Note that E4-rekey and E4-resync might be better named E3-rekey and > E3-resync... I dunno. Yes. Please make the change. > The remaining question is whether or not a state machine need to go > back to > E4-rekey while in E4-resync and timeout. If it is the case, I guess we > need > to split E4-resync in E4-resync and E4-resync-while-rekey, both > reached upon > recept of a R1 while being in resp. E4-rekey and E3. Well, I think that if the state machine enters the E4-resync state, the right thing is to go to E-failed (and not back to E3 or E4-resync) on timeout. Anyway, the I2s should trigger an R2 from the peer even if the peer didn't actually initiate the resync, and that R2 will cause the host to return to E3. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Dec 10 07:16:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 10 07:16:00 2003 Subject: [Hipsec] Issue #5: state machine bug In-Reply-To: <200312091632.09584.julien.laganier@sun.com> References: <200312091632.09584.julien.laganier@sun.com> Message-ID: <6B5D6C84-2B0F-11D8-9D76-000393CE1E8C@nomadiclab.com> Further thoughts after some more consideration: - An I2 may not, after all, generate an R2 from the peer since if it is still up, it may drop the I2 due to failing birthday check. There are a few ways how to deal with that: 1. Define that when you go to E4-resync, you increment your birthday counter. 2. Instead of going to E-FAILED from E4-resync on timeout, go back to E3. Especially, if the host continues to receive valid ESP traffic from the peer, there is definitely no need to go to E-FAILED. - A second question is whether we really want to resend the I2s on timeouts? Would it be sufficient to have one fairly long timeout? The rationale is as follows: If there is still active traffic between the hosts, the host in E4-resync will continue to send traffic with the old SA. That will trigger the recipient to send more R1s, with just rate limitation limiting the number of them. The host in E4-resync will answer with further I2s. The first I2 that the crashed host receives will cause it to send R2 and move to E3. When the host in E4-resync receives the R2, it will move to E3, too. No resending of I2s is needed? The only problem seems to be if the R2 gets lost. I guess that in that case the crashed host will send yet another R1, and the E4-resync host will reply with I2, which will now be dropped since it does not pass the Birthday check. But the very same problem seems to be in the initial handshake already. If R2 gets dropped, the Initiator will stay in E2 while the Responder is already in E3. The Responder will drop the I2s since they don't pass the Birthday check. I don't know what to do about the lost R2 problem. Any thoughts anyone? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Dec 10 07:29:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 10 07:29:01 2003 Subject: [Hipsec] New issue: Birthday check badly defined Message-ID: <549D8FCA-2B11-11D8-9D76-000393CE1E8C@nomadiclab.com> While thinking about the lost R2 problem and reading the -08 spec, I noticed that currently the Birthday check is really only defined for R1. Furthermore, the I2 processing rules don't really consider the Birthday check, it is only mentioned in the state machine. This all needs to be clarified. I still don't know what is the "right" approach to this. --Pekka From thomas.r.henderson@boeing.com Wed Dec 10 11:29:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Dec 10 11:29:00 2003 Subject: [Hipsec] Issue #5: state machine bug Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F10@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > Sent: Tuesday, December 09, 2003 7:32 AM > To: HIPsec > Subject: [Hipsec] Issue #5: state machine bug >=20 >=20 > Folks, >=20 > Getting back to issue #5, I've tried to add a new substate to=20 > the state=20 > machine (E4-resync) to be able to receive R2 when the=20 > corresponent node=20 > rebooted and send R1 in reply to an ESP packet with unknown=20 > SPI. I also=20 > renamed E4 in E4-rekey to avoid creating to much substates,=20 > as per Pekka's=20 > suggestion. Let's try to describe the approach: Before spending too much time resolving this, I would like to raise the discussion again of why we are sending R1s. i) it has been stated that IPsec has made a conscious=20 decision not to respond to unknown received SPIs by rekeying. Why do we do something different with HIP? This implies that we are needing a little more than BEET mode in the IPsec implementations. ii) if we decide to respond to unknown SPIs, how do we know whether the SPI corresponds to a HIP or an IKE SA if both daemons are running? This is why I would vote for maintaining alignment with IPsec current practice. (is reboot that frequent that we need to optimize for it? my experience is that reboot typically kills the=20 application that was using the socket anyway) iii) if, however, we decide to respond, why respond with an R1? Why not an I1 or a new packet type (see below)? I also have a few more suggestions for consideration: iv) Julien's state diagram has started us down the path of appending meaningful names to the state shorthand notation (e.g. E4-rekey). The next logical step might be to drop the prefix "E#" since it doesn't convey much meaning to the reader (especially the new reader). Old name New name -------- -------- E0 START (or UNASSOCIATED or CLOSED) E1 INIT1=09 E2 INIT2 E3 ESTABLISHED (or ACTIVE or ASSOCIATED) E4-rekey REKEYING E4-resync RESYNC E-FAILED (do we even need this?) v) I have often found that overloading packet types to serve multiple purposes leads to ambiguity. In this case, we should consider an explicit packet type for RESYNC if that is what we decide to do (actually, we could reuse I1 or R1 type but set a control bit that explicitly says "I am trying to resync with you"). Whether it is a new packet type or a control bit is not the main issue-- it is rather trying to remove guesswork from the packet processing logic. From thomas.r.henderson@boeing.com Thu Dec 11 12:12:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Dec 11 12:12:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Wednesday, December 10, 2003 1:05 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Indicating Reply Requested and renaming NES? >=20 >=20 > As I am working on the revised Mobility and Multi-homing > scheme, I have come to a tentative conclusion that it might > be good to introduce a new HIP control or alternatively > take one bit from the packet Type field into use. I would > also like to rename the "New SPI" (NES) packet into a more > generic "Update" (UPD) packet, since it looks like a good > candidate for various kinds of updates, not just SA updates > but also readdressing updates and probably other kinds of > updates in the future. Furthermore, if we decide to rename > the NES packet into a UPD packet, we can also rename the > NES_INFO parameter into a NES parameter, just for simplicity. I would support NES->UPD change >=20 > New control option > ------------------ >=20 > The currently defined controls are the following: > C - CER packets follow > E - Use 64-bit ESP sequence numbers > A - The sender's HIT is anonymous > (Actually the E control should be part of the ESP > transform parameter and not a control, but that is a > different issue.) Agreed on the E-bit. We could put a control field in the ESP_TRANSFORM, or else define an ESP64_TRANSFORM Type code. I would vote for the former. Incidentally,=20 16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM=20 and ESP_TRANSFORM. >=20 > I would now like to include a new control > R - A reply is requested >=20 > This control would always be set in I1, R2, and I2, and > (almost) never in R2. However, it looks like that it > would be fairly useful in NES and BOS, at least. A couple of questions/comments: i) what are the specific semantics of the bit? "Must ack"? Is it implied that the packet will be retransmitted if the reply does not arrive? Do we need another "ack" bit that conveys "this is the reply that you requested"? Do we then need to make sure that the protocol operates in "stop and wait" ARQ mode to avoid ambiguities? ii) in most of your examples, it is understood from the packet type definition that a reply is requested. Why have this bit and then have to define rules for e.g. handling an I2 with the R bit off? iii) should we have a more general facility (e.g. packet type and defined ARQ semantics) for UPDATE/UPDATE_ACK that=20 could be used by NES parameters and whatever else is=20 desired in the future? >=20 > I also think that having a generic update utility with > different kinds of parameters (NES, REA, etc) that > indicate what is to be updated creates a more orthogonal > micro- architecture within the actual protocol. The > obvious counter-argument is, of course, that such > orthogonality and generality may create unnecessary > complexity. However, in this specific case I don't see > that much more complexity. Indeed, a well written > implementation may become less complex since it may > require less code for handling various cases. sounds like iii) above. Are you in favor of this, then, instead of R-bit or in addition to R-bit? >=20 > Both of the schemes have the added benefit that it would > allow sending I1s just to tell one's HIT (a kind of minimal > BOS without the actual HI or signature), or maybe to send > those R1s that are sent in response to unknown SPIs with > the reply requested bit off? >=20 > Especially the ability to send I1s with no reply requested > might be beneficial for delayed HIP context setup; a feature > that seems useful from multi6 point of view. why not instead make BOS parameters optional?=20 Tom =20 From petri.jokela@nomadiclab.com Fri Dec 12 01:55:02 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Dec 12 01:55:02 2003 Subject: [Hipsec] Issue #5: state machine bug In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F10@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F10@xch-nw-27.nw.nos.boeing.com> Message-ID: <3FD96E64.5020503@nomadiclab.com> Henderson, Thomas R wrote: > iii) if, however, we decide to respond, why respond with > an R1? Why not an I1 or a new packet type (see below)? A question related to sending the R1 when an unknown SPI is received: If A and B have an established connection between them (both in E3 state). Now, our attacker, C, decides to send a fake packet with unknown SPI to the A using B's source IP address. What will the A host do? A sends R1 to B, while the A-B connection still remains in the E3 state (the sent R1 doesn't have any effect on this). However, B gets an R1 packet and thinks that A has lost the state, maybe rebooted. It starts calculating and finally sends back the I2 packet and moves to state E4-resync. If A sends traffic using the old SA, the B will come back to E3 when traffic is received from the old SA (and just forget the new SA). If the A does not send traffic, the B remains in E4-resync. The A receives the I2 packet related to the SA (it can now be mapped using the received HIT), it generates a new SA and sends R2 back to the B. B receives R2 and generates a new SA. Now, C has initiated a negotiation between A and B resulting in a new SA. If the B is a server (with a thousand connections) and C manages to generate a negotiation between clients and the server, the server has some calculations to do. And, in fact, the server acts now as the Initiator for all those connections thus getting most of the calculation work. Am I missing something or is the automatic R1 sending really a bad idea? /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 pekka.nikander@nomadiclab.com Fri Dec 12 03:03:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 12 03:03:01 2003 Subject: [Hipsec] Problems with resynching Message-ID: <7425BE76-2C7E-11D8-B0C0-000393CE1E8C@nomadiclab.com> I am starting to feel that there are indeed quite a lot of problems with the resynching idea. My current opinion is that either we should drop it (as Tom suggests) or we really need to spend some serious work on getting it right. The problems start from the very beginning. Just sending an R1 when one receives an unknown SPI is not quite enough. We have to remember that anyone can trigger a host to send and R1. It looks also plausible to assume that anyone can trigger a host to bump its Birthday count. (Even if that would be impossible right now, we should not rely on such an assumption.) Hence, an attacker can contact a host, make it to bump up its Birthday count, and get an R1. It can then later send this R1 to another host, making it to start the resynchronization process. There is a fairly easy way of plugging this problem. We just adopt a new packet, RESYNCH, as Tom suggested, and include the ESP packet that triggers the resynching into this packet. Obviously, the included ESP packet cannot be covered by the signature. Now the host that sent the ESP packet can verify that the RESYNCH is sent in response to some data that it sent. It still cannot be sure whether the RESYNCH was sent by the real peer or someone on the path, though. It's a good question whether the RESYNCH should just contain the triggering ESP packet or whether it should be similar to R1. Including the R1 fields would save one round trip time. But is that worth the effort and complexity? And then there are those fundamental questions that Tom asked about the overall sanity of the resynch idea: > i) it has been stated that IPsec has made a conscious > decision not to respond to unknown received SPIs by > rekeying. Why do we do something different with HIP? > > ii) if we decide to respond to unknown SPIs, how do we > know whether the SPI corresponds to a HIP or an IKE SA > if both daemons are running? The next question is that if someone can trick a host into the resynching state, how should the peer react? Clearly, if the peer is still running fine, there is no need for the resynch, and unnecessary resynch would open a DoS vulnerability. The easiest way seems to be continuing to send ESP data, and using fresh ESP data as an indication that resynching is not needed. Julien's state machine figure seems to include this, but the description didn't. Finally, we have the problem of dropped R2s. Clearly, just keeping on sending I2s don't quite work. Now, what shall we do? 0. Drop the resynch altogether? 1. Keep running this discussion on the mailing list? 2. Form a design team, e.g. for the duration of January, with regular telecon meetings, to get this right? 3. Have a volunteer to work out all the transitions in the state machine, verify it with a protocol analyser, and run it with a crypto protocol analyser to get all multiparty attack scenarios considered? --pekka From pekka.nikander@nomadiclab.com Fri Dec 12 03:15:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 12 03:15:02 2003 Subject: [Hipsec] Issue #5: state machine bug In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F10@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F10@xch-nw-27.nw.nos.boeing.com> Message-ID: <3D63BE0F-2C80-11D8-B0C0-000393CE1E8C@nomadiclab.com> > i) it has been stated that IPsec has made a conscious > decision not to respond to unknown received SPIs by > rekeying. Why do we do something different with HIP? I don't really know all the reasons Bob had this. There is one architectural issue, though. In a way, HIP can be considered to be part of the "IP substrate" from the transport protocol point of view. That is, there will often be HIP state between a pair of hosts even if there are no active transport associations. On the flip side, whenever you open a transport association, you must first establish HIP state. Hence, if there is still ongoing traffic, it might make sense to recreate HIP state as soon as possible, if for no other reason then to generate a (secure) TCP RST. > ii) if we decide to respond to unknown SPIs, how do we > know whether the SPI corresponds to a HIP or an IKE SA > if both daemons are running? As you imply, we don't. OTOH, sending severely rate limited RESYNCH packets is not necessarily that bad. If the peer is an IKE-only peer, it will just drop them. > iii) if, however, we decide to respond, why respond with > an R1? Why not an I1 or a new packet type (see below)? I agree that a new packet type would most probably be best. That avoids the ambiguity you are referring to. > iv) Julien's state diagram has started us down the path of > appending meaningful names to the state shorthand notation > (e.g. E4-rekey). The next logical step might be to > drop the prefix "E#" since it doesn't convey much meaning > to the reader (especially the new reader). Let's do this. > Old name New name > -------- -------- > E0 START (or UNASSOCIATED or CLOSED) I like UNASSOCIATED. > E1 INIT1 I1-SENT? > E2 INIT2 I2-SENT? > E3 ESTABLISHED (or ACTIVE or ASSOCIATED) I like ESTABLISHED. > E4-rekey REKEYING > E4-resync RESYNC Ok. > E-FAILED (do we even need this?) Conceptually, yes. In real life, you probably want to delay in the FAILED state, generating canned ICMP host unreachable packets to the upper layer protocols, before trying again. It would be good to have an appendix on this. Any takers? > v) I have often found that overloading packet types > to serve multiple purposes leads to ambiguity. In this case, > we should consider an explicit packet type for RESYNC if > that is what we decide to do. While I agree with you in this specific case, i.e. that we need to make a distinction between R1 and RESYNC(H), I would be more cautious about the generic comment. We have to remember that we are developing a new piece of very fundamental architecture here. (Or at least we think that we are doing that :-) Hence, we really do not know what people will like to use our technology for. Consequently, it makes sense to design the technology so that - the mechanisms are as simple as feasible but at the same time - the mechanisms are as generic and extensible as feasible Much of the difficulty goes into finding the (golden) balance between these two extremes. That is, while we want to make very simple design, we do not want to nail down the protocol so that it is impossible to extend it later on. From the other extreme point of view, while we want to have generic and extensible mechanisms, we do not want the mechanism to become complex just because of generality or extensibility. IMHO, the current extension mechanism is a fairly good compromise. It is reasonably simple, but still offers quite a lot of generality and extensibility. The forthcoming revised mobility and multi- homing draft will be an example of how this extensibility could be utilized. --Pekka Nikander From pekka.nikander@nomadiclab.com Fri Dec 12 03:30:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 12 03:30:03 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> Message-ID: <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> >> I would >> also like to rename the "New SPI" (NES) packet into a more >> generic "Update" (UPD) packet, since it looks like a good >> candidate for various kinds of updates, not just SA updates >> but also readdressing updates and probably other kinds of >> updates in the future. Furthermore, if we decide to rename >> the NES packet into a UPD packet, we can also rename the >> NES_INFO parameter into a NES parameter, just for simplicity. > > I would support NES->UPD change Good. Are you OK also with the parameter name change? Any other opinions anyone? Any more supporters? >> E - Use 64-bit ESP sequence numbers >> (Actually the E control should be part of the ESP >> transform parameter and not a control, but that is a >> different issue.) > > Agreed on the E-bit. We could put a control field > in the ESP_TRANSFORM, or else define an ESP64_TRANSFORM > Type code. I would vote for the former. Incidentally, > 16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM > and ESP_TRANSFORM. Petri, could you provide us with sample text of how the draft would be changed? >> I would now like to include a new control >> R - A reply is requested >> > > A couple of questions/comments: > i) what are the specific semantics of the bit? "Must ack"? > Is it implied that the packet will be retransmitted if > the reply does not arrive? Do we need another "ack" bit > that conveys "this is the reply that you requested"? Do we > then need to make sure that the protocol operates in > "stop and wait" ARQ mode to avoid ambiguities? Good questions. I didn't think that far. Thanks. Now considering this, I think that the "the packet will be retransmitted if not replied" sounds good. This could even be integrated with an explicit retransmission counter in the packet. We already have retransmission counters in the state machine side. Including the field into the packets (even outside of signature) might help with protocol robustness. Unfortunately I have too little generic protocol design experience so that I could tell how useful that would be. I don't think we need an ACK bit. In the case of the base exchange, the packet sequence is clear enough. In the case of UPD/BOS/..., the parameters include an ID that must be present in the reply. But is this good design? Should we have some complexity in the base header, maybe including a packet ID? Then we would not need to have IDs in the parameters. > ii) in most of your examples, it is understood from the > packet type definition that a reply is requested. Why > have this bit and then have to define rules for e.g. > handling an I2 with the R bit off? I would not define what to do with I2 with the bit off. That would not be I2, it would be I2' or something, not defined now. It would just open up a possibility for a (perhaps unnecessary) future extension. > iii) should we have a more general facility (e.g. packet > type and defined ARQ semantics) for UPDATE/UPDATE_ACK that > could be used by NES parameters and whatever else is > desired in the future? Rethinking the issue, this might be the best approach. I.e. forget the idea about a generic R-bit, and just once more redesign the rekeying procedure, this time with a generic UPDATE packet. I guess there would be several flavors of the UPD packet: - initial, unidirectional, no reply requested - initial, reply requested - reply, no further replies needed - reply, a further reply needed We clearly would need a kind of transaction ID (assinged in the initial packet and used later), and a reply requested bit. Anything else? I would imagine each transaction would form a stop-and-wait protocol, with the possibility of running several transactions in parallel. > sounds like iii) above. Are you in favor of this, then, > instead of R-bit or in addition to R-bit? I guess I'm still exploring possibilities. Right now a generic UPDATe and no R seems best. But I still don't really know. Right now I should do other things but ponder this. :-) I guess I'll write a proposal for a generic UPDATE, possibly to be included into -09, and send it to the list. Maybe today, maybe next week. --Pekka Nikander From petri.jokela@kolumbus.fi Fri Dec 12 06:47:01 2003 From: petri.jokela@kolumbus.fi (Petri Jokela) Date: Fri Dec 12 06:47:01 2003 Subject: [Hipsec] Pre-1 version of draft-moskowitz-hip-09 Message-ID: <3FD9B011.40000@kolumbus.fi> I uploaded the current version (-09-pre1) of the hip draft to hip4inter.net: http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-09-pre1.txt What has happened: Issue #9 Diffie-Hellman: ======================== We have discussed about those groups and we propose now a new set of groups: - A new 384-bit group This group does not actually yet exist, but the reasoning behind a "weaker" group is that the 768-bit may be too heavy for some PDAs. As Julien earlier wrote, the calculation with 768-bit may take almost 6 seconds. In many cases, this is not acceptable. If this new weaker group is accepted, the values must be generated. - removed 1K, 2K and 4K groups If there are many groups in SHOULD category, some of them will disappear. Thus, it may be better to limit the number of groups now. - defined 1 and 3 as mandatory. The gid 5 is a SHOULD+, meaning "almost-MUST": this should exist on all hosts except on some PDAs. The rest of the groups are normal "SHOULD". I don't know how to write this down, my brains just refuse to co-operate with me when writing this text. Any opinions on the new group ID structure or on the new text (I'm more than happy if I get some better text...) Issue #2 Parameter numbering ============================= Changed according to the patch sent by Miika. Issue #3 Section 9 and 11 rewriting =================================== Changed section 9 and new 11.1 and 11.2. Issue #6 ENCRYPTED ================== I added one sentence in 6.2.15 (first paragraph): "Each of the TLVs to be encrypted, must be padded according to rules in 6.2.1 before encryption." I tried to clarify the current situation, so that there would not be any different views, how TLVs exist inside the encrypted part. Issue #5 State machine ====================== This is still in its original format. There seems to be pressure to fix the "unknown SPI, send R1" problem, thus I didn't yet change anything here. OTHER: ====== Few typos fixed. Ltrunc clarification added in 4.1.1: the ltrunc as a function is not necessarily unambiguous, thus I added one sentence to clarify the function. Open issues can be found from http://hip4inter.net/issues userid: guest passwd: guest Group: Host Identity Protocol (there is also a group for mobility and multihoming issues) /petri From Julien.Laganier@Sun.COM Fri Dec 12 07:52:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Dec 12 07:52:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> Message-ID: <200312121426.50947.julien.laganier@sun.com> On Friday 12 December 2003 10:05, Pekka Nikander wrote: > >> I would > >> also like to rename the "New SPI" (NES) packet into a more > >> generic "Update" (UPD) packet, since it looks like a good > >> candidate for various kinds of updates, not just SA updates > >> but also readdressing updates and probably other kinds of > >> updates in the future. Furthermore, if we decide to rename > >> the NES packet into a UPD packet, we can also rename the > >> NES_INFO parameter into a NES parameter, just for simplicity. > > > > I would support NES->UPD change > > Good. Are you OK also with the parameter name change? > > Any other opinions anyone? Any more supporters? I support this change too. > >> E - Use 64-bit ESP sequence numbers > >> (Actually the E control should be part of the ESP > >> transform parameter and not a control, but that is a > >> different issue.) > > > > Agreed on the E-bit. We could put a control field > > in the ESP_TRANSFORM, or else define an ESP64_TRANSFORM > > Type code. I would vote for the former. Incidentally, > > 16-bits is probably overkill for Suite-IDs in HIP_TRANSFORM > > and ESP_TRANSFORM. I'd prefer the former too; it avoids to create one more TLV type. > >> I would now like to include a new control > >> R - A reply is requested > > > > A couple of questions/comments: > > i) what are the specific semantics of the bit? "Must ack"? > > Is it implied that the packet will be retransmitted if > > the reply does not arrive? Do we need another "ack" bit > > that conveys "this is the reply that you requested"? Do we > > then need to make sure that the protocol operates in > > "stop and wait" ARQ mode to avoid ambiguities? > > Good questions. I didn't think that far. Thanks. > > Now considering this, I think that the "the packet will > be retransmitted if not replied" sounds good. This could > even be integrated with an explicit retransmission counter > in the packet. We already have retransmission counters in > the state machine side. Including the field into the packets > (even outside of signature) might help with protocol > robustness. Unfortunately I have too little generic protocol > design experience so that I could tell how useful that > would be. > > I don't think we need an ACK bit. In the case of the > base exchange, the packet sequence is clear enough. In > the case of UPD/BOS/..., the parameters include an ID that > must be present in the reply. > > But is this good design? Should we have some complexity > in the base header, maybe including a packet ID? Then > we would not need to have IDs in the parameters. What do you guys think of combining the transaction ID (as used by NES) and the birthday counter into the same base header field? They seem to have a pretty much similar semantic. Thus, one would normally reply with the same ID as the one contained in the packet triggering the reply, and increment it in case of loss or updating of a HIP association state, or when updating SA's. Furthermore, birthday and cookie are now packed together within a single BIRTHDAY_COOKIE parameter and I can't really see the relation between birthday and cookie. AFAICS, it gives the opportunity to use some sort of birthday check on transaction ID in all packets that needs it (NES and R1 amongst the others). Thoughts? > > ii) in most of your examples, it is understood from the > > packet type definition that a reply is requested. Why > > have this bit and then have to define rules for e.g. > > handling an I2 with the R bit off? > > I would not define what to do with I2 with the bit off. > That would not be I2, it would be I2' or something, > not defined now. It would just open up a possibility > for a (perhaps unnecessary) future extension. I like the idea to keep the base protocol as much flexible as possible. As long as it doesn't introduce a huge amount of complexity I think it's worth keeping the extension door open, even on packets that doesn't apparently need it. > We clearly would need a kind of transaction ID > (assinged in the initial packet and used later), > and a reply requested bit. Anything else? This looks like very much like the birthday counter... Thanks, --julien From thomas.r.henderson@boeing.com Fri Dec 12 11:33:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Dec 12 11:33:01 2003 Subject: [Hipsec] Issue #5: state machine bug Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F41@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Thursday, December 11, 2003 11:30 PM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Issue #5: state machine bug >=20 >=20 > Henderson, Thomas R wrote: > > iii) if, however, we decide to respond, why respond with > > an R1? Why not an I1 or a new packet type (see below)? >=20 > A question related to sending the R1 when an unknown SPI is received: >=20 > If A and B have an established connection between them (both in E3=20 > state). Now, our attacker, C, decides to send a fake packet=20 > with unknown=20 > SPI to the A using B's source IP address. What will the A host do? >=20 > A sends R1 to B, while the A-B connection still remains in=20 > the E3 state=20 > (the sent R1 doesn't have any effect on this). However, B gets an R1=20 > packet and thinks that A has lost the state, maybe rebooted.=20 B would discard the R1 in general based on Birthday count. The potential attack is if C could somehow get A to bump its birthday count first. If C and A have an association that times out=20 and is restarted, birthday would increase (note that in Section 4.1.3,=20 there is a statement that "The Birthday also has to be increased in=20 accordance with the system's SA timeout parameter."). However, if A and = anyone else have an association that times out, C could take advantage=20 of the Birthday count (C could probe A with I1s intermittently to=20 find A's current birthday count). So anytime a machine increments its birthday count, under the current rules, it could expose all active associations to a "fake reboot" attack. From pekka.nikander@nomadiclab.com Tue Dec 16 06:43:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 16 06:43:00 2003 Subject: [Hipsec] WG charter proposal Message-ID: --Apple-Mail-10-928091257 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Folks, Here is a new proposal for the WG charter, based on the discussions on this list and with the ADs. We should find some kind of consensus on the charter fairly soon, in order to get it in time to the IESG meeting agendas etc, if we want to have a WG chartered before Seoul. Hence, please send your comments as soon as possible, even if it is just a plain "looks good". This proposal is based on the assumption that there will be a short term, very focused WG, and a parallel RG. The purpose of the WG is to finalize those parts of HIP design that are either fairly mature already, or seem to be very straightforward. I am still working on a proposal for the RG charter. Note that this charter does *not* address Steve Kent's request for a problem statement. IMHO, it would be unwise to try to define a precise problem statement for the WG. To me, it looks better to start from the architecture document and from the requirement of providing "minimal infrastructure support." The large, overall problem statement is to be understood from the context, and is partially discussed in the architecture draft. --Pekka Nikander --Apple-Mail-10-928091257 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="hip_charter_proposal_031216.txt" Content-Disposition: attachment; filename=hip_charter_proposal_031216.txt Host Identity Protocol (HIP) Chairs (tentative, subject to AD decision): David Ward Gonzalo Camarillo Internet Area Directors: Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Security Area Liason: TBD. Mailing Lists: General Discussion: hipsec@honor.trusecure.com Send mail to: hipsec-request@honor.trusecure.com With a subject line: subscribe List archive: http://honor.trusecure.com/pipermail/hipsec/ Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: draft-moskowitz-hip-arch-05.txt (at RFC editor) and draft-moskowitz-hip-08.txt (soon -09.txt) There are five publicly known, interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ In particular, the objective of this working group is to complete the base protocol specification, define one or more DNS resource records for storing HIP related data, to complete the existing work on basic mobility and multi-homing, and produce Experimental RFCs for these. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet in the large. It is expected that there will be a rougly parallel IRTF Research Group that will focus both on more forward looking aspects of the HIP architecture and on the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: 1) Complete the HIP base protocol specification. Starting point: draft-moskowitz-hip-08.txt (or newer) 2) Complete the basic mobility and multi-homing support for HIP. Starting point: draft-nikander-hip-mm-01.txt (or newer) While this work partially overlaps the work in Mobile IP and Multi6 Working Groups, it is very different in the sense that is based on the Experimental HIP specification, and cannot function without it. 3) Define one or more new DNS Resource Records for storing HIP related data, such as Host Identifiers and Host Identity Tags (HITs). This task explicitly excludes the task of defining reverse DNS entries based on HITs. 4) Define a basic HIP rendezvous mechanism. A basic HIP rendezvous server allows mobile and non-mobile HIP hosts to register their current IP addresses at the server. Other hosts can then send the initial I1 packets to the rendezvous server, which forwards the packets to the HIP host's current address. This task explicitly excludes solving more general problems, such as the referral problem. Also excluded is the problem of finding the right rendezvous server. It is expected that the DNS records will be used for that. The Working Group bases all the work on the HIP achitecture specification (as defined above). Goals and Milestones: Mar 04 WG LC on the base protocol specification. Mar 04 First version of the HIP basic mobility and multi-homing mechanism specification. Mar 04 First version of the HIP DNS resource record(s) specification. Apr 04 Complete the base protocol specification and submit it to the IESG for Experimental. Apr 04 First version of the HIP basic rendezvous mechanism specification. May 04 WG LC on the HIP DNS resource record(s) specification. Jun 04 WG LC on the HIP basic mobility and multi-homing specification. Jun 04 Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Jul 04 Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Aug 04 WG LC on the basic HIP rendezvous mechanism specification. Sep 04 Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Oct 04 Recharter the WG. Current Internet-Drafts: draft-moskowitz-hip-arch-05.txt (at RFC editor) draft-moskowitz-hip-08.txt (soon -09.txt) draft-nikander-hip-mm-00.txt (soon -01.txt) Proposed WG items: draft-ietf-hip-protocol-XX.txt (HIP base exchange) draft-ietf-hip-mm-XX.txt (HIP basic mobility and multihoming) draft-ietf-hip-dns-rr-XX.txt (HIP DNS resource record) draft-ietf-hip-rendezvous-XX.txt (HIP basic rendezvous) --Apple-Mail-10-928091257 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-10-928091257-- From jari.arkko@piuha.net Tue Dec 16 08:25:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Dec 16 08:25:01 2003 Subject: [Hipsec] WG charter proposal In-Reply-To: References: Message-ID: <3FDF0FC6.8000800@piuha.net> Pekka, The charter looks good to me. A few nits: - What's the box that is drawn around "The purpose of this Working..."? - s/rougly/roughly/ --Jari From Julien.Laganier@Sun.COM Tue Dec 16 09:38:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Dec 16 09:38:01 2003 Subject: [Hipsec] WG charter proposal In-Reply-To: References: Message-ID: <200312161612.30944.julien.laganier@sun.com> Hi Pekka, The WG charter proposal looks quite good to me. Thanks, --julien From pekka.nikander@nomadiclab.com Tue Dec 16 10:07:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 16 10:07:01 2003 Subject: [Hipsec] Teaching NATs to understand SPIs? Message-ID: <8AC38C1B-2FDE-11D8-8CC1-000393CE1E8C@nomadiclab.com> [While this is strictly out-of-topic at the mobike mailing list, I am sending this message to both mobike and hipsec mailing list. To mobike since there has recently been quite a lot of discussion about the complications of IPsec NAT-T and mobility, and to the hipsec mailing list since the HIP folks have been discussing various SPI-based NAT traversal issues already for a few years. Please use your own judgement on where to send replies.] In the HIP community, there has been a desire to make HIP to work through NATs for quite some time. Recently this work has been proposed to be outside of any WG work, but that there would be an item for this at the IRTF side. [The intention is that there would be a HIP WG and a HIP-related but wider RG. The RG would study both HIP and other issues related to identifier/locator splitting.] The current HIP approach is based on the idea that the key management protocol sends the SPIs in clear text, thereby allowing knowledgeable NAT boxes to create mappings between HIP Host Identifiers and pairs. Technically, that would allow a NAT box to create HIP-connection specific mappings on the fly, and to NAT directly ESP instead of requiring UDP tunneling. There has also been the idea that the public key signatures in HIP packets could be used to verify the any changes in this mapping, caused by mobility. However, those ideas are less baked: doing PK verification at a NAT box may be too expensive, in HIP only the responder's public key becomes public information while the initiator's public key can be kept hidden (not sent in clear text in key exchange), etc. Some people are looking at alternatives. Now, the real question is whether it is sufficient that these issues are studied in an IRTF RG, or if there is sufficient interest to start a working group on the issue? Basically, I see at least two options: 1. Let the proposed HIP-related IRTF RG to initially tackle this problem space, and wait until we see if there comes out anything usable. 2. Try to run a BOF in Seoul or San Diego, and form a WG to solve the problem on how to teach NAT boxes to understand SPIs and create SPI based mappings instead of using UDP encapsulation. Maybe there are others that I am not aware of, or other people working on the area. If so, I'd very much would like to know. --Pekka Nikander From pekka.nikander@nomadiclab.com Tue Dec 16 10:17:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 16 10:17:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <200312121426.50947.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> Message-ID: On Dec 12, 2003, at 15:26, Julien Laganier wrote: >>>> I would now like to include a new control >>>> R - A reply is requested >> Now considering this, I think that the "the packet will >> be retransmitted if not replied" sounds good. This could >> even be integrated with an explicit retransmission counter >> in the packet. ... >> I don't think we need an ACK bit. ... > What do you guys think of combining the transaction ID (as used by > NES) and > the birthday counter into the same base header field? They seem to > have a > pretty much similar semantic. I have to admit that I have never quite understood all the issues behind the Birthday counter. It would be good if Bob would have time to clarify that. However, remembering that caveat, to me the idea sounds good. Besides, 64 bits looks like a big enough counter that it will never roll over during the lifetime of the protocol. That is, we will have a new protocol version before the birthday counter rolls over. (But can we reset the birthday counter when the protocol number is incremented? Probably yes, if we act proactively enough now.) > Thus, one would normally reply with the same ID as the one contained > in the > packet triggering the reply, and increment it in case of loss or > updating of > a HIP association state, or when updating SA's. Is it that simple? Don't we have birthday counters at both ends? I think we couldn't increment the peer's birthday counter (transaction id). Hmm. Maybe we could combine the low order bits from the birthday counter (say 24 low order bits) with a short within-transaction counter that is incremented on all resends? Hmmmmm. This all sounds so much of how to design generic reliable protocols that I really should not open my mouth here. We really should get someone with proper protocol design experience -- I don't have that outside of crypto protocols. > Furthermore, birthday and cookie are now packed together within a > single > BIRTHDAY_COOKIE parameter and I can't really see the relation between > birthday and cookie. Good point. > AFAICS, it gives the opportunity to use some sort of birthday check on > transaction ID in all packets that needs it (NES and R1 amongst the > others). Sounds great. Should we include the birthday field in the base protocol header so that it is included in all HIP packets? > I like the idea to keep the base protocol as much flexible as > possible. As > long as it doesn't introduce a huge amount of complexity I think it's > worth > keeping the extension door open, even on packets that doesn't > apparently need > it. Agreed. --Pekka Nikander From kempf@docomolabs-usa.com Tue Dec 16 13:58:01 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Tue Dec 16 13:58:01 2003 Subject: [Hipsec] Re: [Mobike] Teaching NATs to understand SPIs? References: <8AC38C1B-2FDE-11D8-8CC1-000393CE1E8C@nomadiclab.com> Message-ID: <010901c3c3f5$ea5db740$5b6015ac@dclkempt40> I think the intent of NSIS is that it will be a protocol for communicating with general middleboxes. MIDCOM was supposed to do this as well near term, I think they decided to use SNMP, don't know where they are at. jak ----- Original Message ----- From: "Pekka Nikander" To: "MOBIKE Mailing List" ; Sent: Tuesday, December 16, 2003 7:43 AM Subject: [Mobike] Teaching NATs to understand SPIs? > [While this is strictly out-of-topic at the mobike mailing > list, I am sending this message to both mobike and hipsec > mailing list. To mobike since there has recently been > quite a lot of discussion about the complications of IPsec > NAT-T and mobility, and to the hipsec mailing list since > the HIP folks have been discussing various SPI-based NAT > traversal issues already for a few years. Please use > your own judgement on where to send replies.] > > In the HIP community, there has been a desire to make > HIP to work through NATs for quite some time. Recently > this work has been proposed to be outside of any WG work, > but that there would be an item for this at the IRTF side. > [The intention is that there would be a HIP WG and a > HIP-related but wider RG. The RG would study both HIP and > other issues related to identifier/locator splitting.] > > The current HIP approach is based on the idea that the > key management protocol sends the SPIs in clear text, > thereby allowing knowledgeable NAT boxes to create > mappings between HIP Host Identifiers and > pairs. Technically, that would allow a NAT box to > create HIP-connection specific mappings on the fly, and > to NAT directly ESP instead of requiring UDP tunneling. > There has also been the idea that the public key signatures > in HIP packets could be used to verify the any changes > in this mapping, caused by mobility. However, those ideas > are less baked: doing PK verification at a NAT box may > be too expensive, in HIP only the responder's public > key becomes public information while the initiator's > public key can be kept hidden (not sent in clear text > in key exchange), etc. Some people are looking at > alternatives. > > Now, the real question is whether it is sufficient that > these issues are studied in an IRTF RG, or if there > is sufficient interest to start a working group on the > issue? > > Basically, I see at least two options: > > 1. Let the proposed HIP-related IRTF RG to initially > tackle this problem space, and wait until we see > if there comes out anything usable. > > 2. Try to run a BOF in Seoul or San Diego, and form > a WG to solve the problem on how to teach NAT > boxes to understand SPIs and create SPI based > mappings instead of using UDP encapsulation. > > Maybe there are others that I am not aware of, or other > people working on the area. If so, I'd very much > would like to know. > > --Pekka Nikander > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo/mobike > From jeffrey.m.ahrenholz@boeing.com Tue Dec 16 14:15:01 2003 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Tue Dec 16 14:15:01 2003 Subject: [Hipsec] WG charter proposal Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2703F620F0@xch-nw-09.nw.nos.boeing.com> Pekka, The WG charter looks good, with an ambitious timeline. Some comments: -the parts that limit the WG scope are very good -charters sometimes feature a "Background" section, and I'm wondering if = the text about existing work/implementations fits in the large = "Description of Working Group" block. -what about any interactions with other WGs? (this may have been = purposely omitted, as an unknown) -Jeff From jari.arkko@piuha.net Tue Dec 16 15:18:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Dec 16 15:18:01 2003 Subject: [Hipsec] Re: [Mobike] Teaching NATs to understand SPIs? In-Reply-To: <010901c3c3f5$ea5db740$5b6015ac@dclkempt40> References: <8AC38C1B-2FDE-11D8-8CC1-000393CE1E8C@nomadiclab.com> <010901c3c3f5$ea5db740$5b6015ac@dclkempt40> Message-ID: <3FDF70BB.2060100@piuha.net> James Kempf wrote: > I think the intent of NSIS is that it will be a protocol for communicating > with general middleboxes. MIDCOM was supposed to do this as well near term, > I think they decided to use SNMP, don't know where they are at. I'm scared about the kind of discovery, deployment, and security considerations that would apply to the use of SNMP from clients to middle boxes. But I confess I know nothing at all about MIDCOM, so maybe their solution is good and takes care of all the considerations. I guess I need to read about MIDCOM and NSIS to learn more... The rest of this e-mail is about history, and 20-20 hindsight into decisions that were taken years ago. It is fascinating to think about how we must have ended up with the current state of the art. It must have been a small, almost insignificant design decision: put the IKE SPIs in the encrypted part of the packet. That's where all the other parameters go, so its logical. Yet this turns out to have a significant impact on what NATs could do about IPsec -- perhaps it even made an impact to how fast IPsec got deployed, since NATs were a problem for some time. And it continues to have an impact today, in the form of extra UDP tunneling that is needed. Why does the SPI location matter? Because if the SPIs are hidden, the NAT box does not know how to create a mapping. This would not be such a big problem if the NAT box could learn the SPIs on the fly, but the fact that the SPIs are different in each direction prevents this. Note: there was no security reason to prevent the SPIs from being exposed, as they are in any case visible in ESP & AH. I wonder what kind of protocols and NAT devices we would have today if the SPIs had been outside the encrypted part? I don't want to claim that a cleartext SPI would have solved all problems. It would certainly work only for those NAT devices that were co-operative. I have a feeling that some fraction NATs are of a more evil sort, the get-yourself-a-more- expensive-subscription-if-you-want-servers-or-vpns type... Similar considerations may apply to protocols that carry other data than SPIs, such as RTP port numbers. --Jari From thomas.r.henderson@boeing.com Tue Dec 16 16:09:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Dec 16 16:09:00 2003 Subject: [Hipsec] WG charter proposal Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F7E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Ahrenholz, Jeffrey M=20 > Pekka, > The WG charter looks good, with an ambitious timeline. I agree. It is probably not reasonable to expect much implementation experience with features beyond base spec before the August meeting. So I can't see how we could be moving to last call at those times. =20 I would suggest a projected date after the Aug. meeting=20 for the DNS draft and a date after the Nov. meeting for the other two drafts.=20 Tom From petri.jokela@nomadiclab.com Wed Dec 17 02:40:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Dec 17 02:40:01 2003 Subject: [Hipsec] WG charter proposal In-Reply-To: References: Message-ID: <3FE010C0.5090304@nomadiclab.com> Pekka Nikander wrote: > Folks, > > Here is a new proposal for the WG charter, based on I think it looks good. /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 pekka.nikander@nomadiclab.com Wed Dec 17 05:06:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 17 05:06:02 2003 Subject: [Hipsec] Including birthday into the base header Message-ID: I did some strawman design on how one could put the birthday value in the base header, so that it would be present in all packets. I am NOT happy with the result, but I'm still posting it so that others might get better ideas than I've had. --Pekka ----------------------------------------------------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | Type | VER. | RES. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply ID | Sender ID | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controls | Birthday, 7 bytes | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... The birthday field contains the sender's bithday from the time when the HIP association was created. In other words, when a host creates an HIP association, it stores its current birthday to the association, and continues to use that birthday value for the duration of the association. If the association is re-established due to any reason, the new association MUST get a new birthday value that MUST be strictly higher than the old value. A receiver SHOULD ignore HIP packet that have a birthday value that is smaller than the currently stored peer birthday value. A receive SHOULD ignore all other HIP packets but I1, R1 and I2 packets whose birthday value is higher than the currently stored peer birthday value. DISCUSSION: The birthday value used to be in a separate parameter in the R1 and I2 packets. However, including the birthday value in all packets has the additional benefit that it effectively blocks DoS attacks where an attacker records packets from an ongoing HIP association and then later re-sends them while a new HIP association is going on. In other words, the birthday value functions as a simple cookie, limiting capture & replay DoS attacks for the duration of the current association. The Sender ID contains a rolling sequence number, incremented every time the sender sends or resends a packet. That is, the Sender ID is initialized to zero when the association is created, and incremented every time the sender sends a packet. When the Sender ID reaches 255, the next packet will have the zero value again. Note that the Sender ID is not covered by the HMAC or SIGNATURE parameters, and therefore can be spoofed by a man-in-the-middle attacker. However, a man-in-the-middle attacker that is powerful enough to change the Sender ID field in the fly can cause much worse problems. It is also possible for an eavesdropper to re-send captured packets with a higher Sender ID, potentially causing a receiver to ignore future packets with lower Sender ID. This is the reason why the receiver MUST limit its filtering to requests that are identical with already processed ones. DISCUSSION: Whether to include the Sender ID within the HMAC or SIGNATURE is basically a design choice that can be made. Leaving it outside of protection gives a small performance gain: the sender does not have to recompute HMACs or SIGNATUREs if it needs to re-send a packet, and the receiver may ignore packets that have identical contents other than Sender ID. The Reply ID value depends on the R-bit in Controls. If the R-bit is one, the packet is a reply to an earlier packet, and the Receiver ID contains a copy of the Sender ID from the replied-to packet. If the R-bit is zero, the Receiver ID MUST be initialized to zero by sender and ignored by receiver. The Sender IDs and Reply IDs are used to associate together requests and replies. That is, a sender keeps sending a request until it either receives a reply to any of the request it has sent, or a maximum number of retries is exceeded. As a general rule, the receiver MAY remember the highest Sender ID (modulo 256) it has received so far, allowing it to pass handling out-of-order old requests. If it does so, it still MUST process all received packet unless a potential out-of-order request is identical, sans Sender ID, with to a recently received request. In other words, the receiver MAY check if the request is identical to a one it has recently processed, other than that the Sender ID is smaller than the one received, and if both conditions are met, drop the packet. Alternatively, the receiver MAY simply answer to all requests received. Note that if the receiver needs to reply to a request that it has already handled, with a lower or higher Sender ID, it MAY include the earlier replied-to Sender ID into the Reply ID field, thereby allowing it to re-send the earlier generated reply, without needing to recompute the HMAC and/or SIGNATURE fields. DISCUSSION: While it might first look appealing to leave the Reply ID outside of protection, similar to Sender ID, the balance seems to go otherwise here. That is, it is often significant to know that a reply is indeed a reply to a certain request. On the other hand, if the sender has sent several copies of a request, with different Sender IDs, a reply with any of those Sender IDs in the Reply ID field are equally good. Hence, the receiver can simply resend an earlier packet, with the protected Reply ID, instead of generating a new one with a new Reply ID. DISCUSSION: Since the Sender ID and Reply ID fields are only 8-bit long, and since a typical request may be retransmitted 5 times, it is possible that an eavesdropping attacker that has recorded all traffic during a HIP association is able to launch a reply attack with a packet that has a proper Reply ID (within the retransmission window) and is also otherwise an apparent reply to a request. However, unless there is excessive packet loss so that the original request is unlikely to receive the destionation, the real peer will also receive the packet and will reply. As a result, the sender will receive two different replies. It is unclear what should be done about this attack, if anything. One possibility is to increase the size of the Sender and Reply ID fields. Another possibility is to bump the bithday value very time the Sender ID field rolls over, and to include the peer birthday or some low order bits of the peer birthday in (some) replies. Yet another possibility is to include transaction IDs in sensitive parameters. Note that due to the possiblity that a receiver may re-send a packet with an earlier Reply ID, the Sender and Reply IDs cannot be used for reliable round-trip-time estimation. The effect is basically that the RTT estimate will be larger than what the real RTT is. When this restriction is understood, they MAY be used for (unreliable) RTT estimation. From mkousa@cc.hut.fi Wed Dec 17 05:18:00 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Dec 17 05:18:00 2003 Subject: [Hipsec] WG charter proposal In-Reply-To: <200312161612.30944.julien.laganier@sun.com> References: <200312161612.30944.julien.laganier@sun.com> Message-ID: On more "me too". The charter looks good to me, too. -- "Real programmers don't comment their code. It was hard to write, it should be hard to understand." From Spencer Dawkins" Message-ID: <02c101c3c49a$54061bc0$0400a8c0@DFNJGL21> I would also make a plea for achievable estimates the first time round. You'll have plenty of opportunties for late milestones after you're chartered ;-} Spencer, who finds our continued insistence on short-term milestones in original charters frustrating because we meet them so rarely ... ----- Original Message ----- From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: Sent: Tuesday, December 16, 2003 3:40 PM Subject: RE: [Hipsec] WG charter proposal > -----Original Message----- > From: Ahrenholz, Jeffrey M > Pekka, > The WG charter looks good, with an ambitious timeline. I agree. It is probably not reasonable to expect much implementation experience with features beyond base spec before the August meeting. So I can't see how we could be moving to last call at those times. I would suggest a projected date after the Aug. meeting for the DNS draft and a date after the Nov. meeting for the other two drafts. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From Gonzalo.Camarillo@ericsson.com Wed Dec 17 07:27:00 2003 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Dec 17 07:27:00 2003 Subject: [Hipsec] WG charter proposal In-Reply-To: <02c101c3c49a$54061bc0$0400a8c0@DFNJGL21> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F7E@xch-nw-27.nw.nos.boeing.com> <02c101c3c49a$54061bc0$0400a8c0@DFNJGL21> Message-ID: <3FE0539C.4030202@ericsson.com> Folks, as you know, we want this WG-to-be to be a short and focused effort. Nevertheless, we do not want to rush things too much either. We are talking to the ADs to see whether we can stretch the initial lifetime of the WG a little. Closing down in Dec 2004 (instead of Oct 04) would give us two more months and one face-to-face meeting more, for instance. We'll keep you updated. Gonzalo Spencer Dawkins wrote: > I would also make a plea for achievable estimates the first time > round. You'll have plenty of opportunties for late milestones after > you're chartered ;-} > > Spencer, who finds our continued insistence on short-term milestones > in original charters frustrating because we meet them so rarely ... > > ----- Original Message ----- > From: "Henderson, Thomas R" > To: "Pekka Nikander" > Cc: > Sent: Tuesday, December 16, 2003 3:40 PM > Subject: RE: [Hipsec] WG charter proposal > > >>-----Original Message----- >>From: Ahrenholz, Jeffrey M > > >>Pekka, >>The WG charter looks good, with an ambitious timeline. > > > I agree. It is probably not reasonable to expect much > implementation experience with features beyond base spec > before the August meeting. So I can't see how we could > be moving to last call at those times. > > I would suggest a projected date after the Aug. meeting > for the DNS draft and a date after the Nov. meeting for the > other two drafts. > > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From pekka.nikander@nomadiclab.com Thu Dec 18 08:47:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Dec 18 08:47:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> Message-ID: [Responding to oneself is not nice, but I realize that HIP is not the first priority to everyone :-) and that people are leaving for holidays.] >> What do you guys think of combining the transaction ID (as used by >> NES) and >> the birthday counter into the same base header field? They seem to >> have a >> pretty much similar semantic. After some more thinking, I think that the birthday counter and transaction ID are pretty different things, even though they may look like the same, and even though it may be good to bind them together. The birthday is basically a value assigned to an incarnation of a HIP association. That is, whenever two hosts create an HIP association, or resynchronize an association, they set their birthday values and stick to those for the duration of the association. That may be years. The transaction ID, on the other hand, is basically a value used to link together requests and replies. This function could be extended to give sequence numbers to all HIP packets, making possible packet loss explicit. That I tried to make in my previous proposal, but the solution wasn't of almost any good. Now, the purpose of the birthday value is to protect the hosts from replay attacks where the attacker simulates loss of state at one of the hosts. Here we have now a problem, as it is possible for an attacker to make a host to increment the birthday value and get an R1 with an incremented birthday value. Since the R1 does not have the peer's HIT, it can be sent to any peer, triggering it to perform I2 computation. The purpose of the transaction ID, on the other hand, is to prevent reply attacks using earlier messages captured (during the current incarnation of the HIP SA). Hence, the birthday value protects the hosts from simulated state loss, and the transaction ID protects the host from captured and replayed packets. I think that these two functions should be kept separate, but I agree that somehow linking them might increase security. That is, if a reply contained both the birthday value (or low order bits of it) and a transaction ID, that would make naive replay attacks slightly harder. Right now I'm inclined towards the following conclusions: - We should replace the R1, when sent on response to ESP, with a RESYNC packet. That would contain the R1 puzzle plus (some part of) the ESP packet that triggered it. A vanilla R1 should be only sent in response to an I1. Since the Initiator knows when it has sent an I1 and when it has sent an ESP packet using a given SPI and SA, this should plug the problem of simulated state loss, provided that the Initiator can check that the included portion of the ESP packet was indeed sent by it. How that is done, exactly, seems to require some more thinking. - It looks like a good idea to add explicit sequence numbers into the base HIP header. The sending sequence number could simply be a few low order bits (maybe 8), since the HIP association is terminated anyway after some number of control packets have been sent unanswered. The reply sequence number must be larger, however, and probably should include low order bits of the birthday, to prevent replay attacks. (The birthday bits are not really needed, since the KEYMAT is different, but if they can be easily included, they provide some minimal added robustness against the case where the network reorders packets during resynchronization.) Comments? --Pekka Nikander From jukka.ylitalo@nomadiclab.com Thu Dec 18 09:39:01 2003 From: jukka.ylitalo@nomadiclab.com (Jukka Ylitalo) Date: Thu Dec 18 09:39:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> Message-ID: <3FE1C409.70701@nomadiclab.com> Pekka Nikander wrote: >>> What do you guys think of combining the transaction ID (as used by >>> NES) and >>> the birthday counter into the same base header field? They seem to >>> have a >>> pretty much similar semantic. >> > > Right now I'm inclined towards the following conclusions: > > - We should replace the R1, when sent on response to ESP, > with a RESYNC packet. That would contain the R1 puzzle > plus (some part of) the ESP packet that triggered it. > A vanilla R1 should be only sent in response to an I1. Sounds nice. Currently, when a host reboots and receives ESP packets with unknown SPIs, it replies with some of its R1s. However, a host may have several HIs and it does not know which of them it should use. Instead, if we reply with this new RESYNC packet containing the received SPI number, the peer is able to map the RESYNC packet into its existing state always. > > Since the Initiator knows when it has sent an I1 and when > it has sent an ESP packet using a given SPI and SA, this > should plug the problem of simulated state loss, provided > that the Initiator can check that the included portion of > the ESP packet was indeed sent by it. How that is done, > exactly, seems to require some more thinking. Hmm. The original ESP sender, host A, could reply to the RESYNC with RESYNC-REPLY message (a variant of NES). The RESYNC-REPLY message would contain current SPI-A, ESP sequence number that is expected from B, and a piggybacked ESP message going to B. Host B mirrors the whole received RESYNC-REPLY message including piggybacked ESP message. However, it changes the SPI-B to SPI-A and the ESP sequence number before sending the message back to A. Finally, A verifies the integrity of the ESP message using its own SA. We have to be careful with the SPI values due to the HIP aware middle-boxes. What do you think? > > Comments? > > --Pekka Nikander > br, Jukka -- Jukka Ylitalo Tel: +358 9 299 2622 NomadicLab, Ericsson Research Fax: +358 9 299 3535 Oy L M Ericsson Ab Mobile: +358 400 615 821 FIN-02420 Jorvas, Finland E-mail: jukka.ylitalo@nomadiclab.com From thomas.r.henderson@boeing.com Thu Dec 18 21:15:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Dec 18 21:15:00 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FA0@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] >=20 > What do you guys think of combining the transaction ID (as=20 > used by NES) and=20 > the birthday counter into the same base header field? They=20 > seem to have a=20 > pretty much similar semantic. >=20 In thinking about this and Pekka's posts some more, this=20 option appeals to me if it is made a parameter or part of an existing parameter rather than base header. In my view, birthday's primary role is to prevent replay attacks of packets that are vulnerable to such. The main (only?) one seems to be NES. Note that I am=20 discounting the R1 at this time because, as I've posted=20 before, I am not sure that this is the right response=20 (or if any response should occur) to unknown SPI. But=20 RESYNCH might also be a candidate for "avoidance of replay". A host also wants its NES acked. So it would seem that=20 there needs to be at least a one-bit sequence number of some sort to identify it. If we could guarantee that NES sequence number increased each time, and that there were well defined modulo=20 sequence number comparisons, then a multi-bit number=20 (let's say 16-bit) would be more useful. This could be=20 defined as "Sequence number" and could be used for both=20 positive acknowledgment when needed and also=20 avoiding replays. There could be a global sequence number for the host, (e.g., birthday). A minor technicality would be that long running associations on busy servers might need to do a NES just because the global sequence number has drifted far enough along that the modulo sequence number=20 comparison of "greater than/less than" will start to fail=20 for a particular association. If sequence numbers were maintained per-association, that could be avoided.=20 The overhead of putting it into the base header could be avoided since it really only pertains to a couple of packets. Counter-thoughts? Tom From pekka.nikander@nomadiclab.com Fri Dec 19 05:54:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 19 05:54:00 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <3FE1C409.70701@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> <3FE1C409.70701@nomadiclab.com> Message-ID: Jukka, >> Since the Initiator knows when it has sent an I1 and when >> it has sent an ESP packet using a given SPI and SA, this >> should plug the problem of simulated state loss, provided >> that the Initiator can check that the included portion of >> the ESP packet was indeed sent by it. How that is done, >> exactly, seems to require some more thinking. > > Hmm. The original ESP sender, host A, could reply to the RESYNC > with RESYNC-REPLY message (a variant of NES). The RESYNC-REPLY > message would contain current SPI-A, ESP sequence number that is > expected > from B, and a piggybacked ESP message going to B. Host B mirrors the > whole received RESYNC-REPLY message including piggybacked ESP > message. However, it changes the SPI-B to SPI-A and the ESP sequence > number > before sending the message back to A. Finally, A verifies the > integrity of > the ESP message using its own SA. We have to be careful with the SPI > values due to the HIP aware middle-boxes. What do you think? I don't see why we need this complicated mechanism. Can't the rebooted host simply include the R1 parameters and the (beginning of) the ESP packet into the RESYNCH packet? You don't need to sign or anything the ESP part, just sign the R1 part as in R1. Why do you need an explicit RESYNC-REPLY packet? The hard part I was referring to is to find out whether the host really sent the ESP packet included into the RESYNCH packet. There is no obvious way of doing this, since the hosts do not store the ESP packets they send. So, what was your reason for this complicated three message sequence? And what are those SPI-A and SPI-B? Maybe I was unclear in my original message? I'm sorry to say but I'm really confused. --Pekka From pekka.nikander@nomadiclab.com Fri Dec 19 06:10:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Dec 19 06:10:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FA0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FA0@xch-nw-27.nw.nos.boeing.com> Message-ID: Tom, > In thinking about this and Pekka's posts some more, this > option appeals to me if it is made a parameter or part of > an existing parameter rather than base header. I'm, on the other hand, inclined to think that we most probably should have sequence numbers in the base header. That would make the protocol more future proof, i.e., I would foresee less complications with future extensions. I don't see any real need to reflect the birthday value in all packets. Since the birthday value is tied to incarnation of the HIP association, and each incarnation has a different DH session key (and therefore different HMAC values), the only case where we need the birthday as replay protection is in resynching. > In my view, birthday's primary role is to prevent replay > attacks of packets that are vulnerable to such. The > main (only?) one seems to be NES. Well, using birthday to protect NES replays would require that you bump up birthday on each NES. You are still using the same HIP keys, and therefore the HIP keys (i.e. the HMAC) does not provide enough of replay protection. I would really like to separate replay protection on incarnation level, semantic packet level, and retransmission level. (See below.) Remember that Bob's original design used ESP sequence numbers as replay protection in NES. We removed it since it would have been very cumbersome to implement in many cases. > But RESYNCH might also be a candidate for > "avoidance of replay". Resynch would need birthday protection. As far as I understand, resynching was the reason why the birthday value was added to the protocol in the first place. > A host also wants its NES acked. So it would seem that > there needs to be at least a one-bit sequence number of > some sort to identify it. Yes. However, just to make the protocol more future proof, I would prefer to have generic, per packet sequence numbers. Let me try to explain my current understanding in detail: The main goal of this exercise is replay protection. We seem to have potential replay in at least four different cases: 1. A RESYNCH packet could be replayed. Birthday and including a portion of the ESP packet can be used to plug this. 2. A message from an earlier incarnation of a HIP association (between a given pair of HITs) could be replayed. The different DH session key, together with HMACs, already plugs this. 3. A message from the current incarnation of the HIP association can be replayed. There is currently no generic mechanism for protecting against this. In his earlier design, Bob re-used ESP replay counters. This is hard to implement, and won't work when you have several parallel SAs (as in the case of multi-homing). Random transaction IDs would work, but would be fairly complex to implement right. Explicit sequence numbers, included in each packet, looks like the most generic and simplest solution, at least to me. 4. An attacker can replay a message to simulate message retransmission. This is not a security problem, since messages may get duplicated in the network anyway. Does that sound right? If so, then it should be fairly easy to derive design recommendations from the above. --Pekka From Julien.Laganier@Sun.COM Fri Dec 19 12:35:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Dec 19 12:35:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> Message-ID: <200312191910.15147.julien.laganier@sun.com> On Thursday 18 December 2003 15:22, Pekka Nikander wrote: > [Responding to oneself is not nice, but I realize > that HIP is not the first priority to everyone :-) > and that people are leaving for holidays.] [Responding so late isn't nice either, but Xmas takes a lot of time... I Apologize] > >> What do you guys think of combining the transaction ID (as used > >> by NES) and > >> the birthday counter into the same base header field? They seem > >> to have a > >> pretty much similar semantic. > > After some more thinking, I think that the birthday counter and > transaction ID are pretty different things, even though they may > look like the same, and even though it may be good to bind them > together. > > The birthday is basically a value assigned to an incarnation > of a HIP association. That is, whenever two hosts create an > HIP association, or resynchronize an association, they set their > birthday values and stick to those for the duration of the > association. That may be years. > > The transaction ID, on the other hand, is basically a value > used to link together requests and replies. This function > could be extended to give sequence numbers to all HIP packets, > making possible packet loss explicit. That I tried to make > in my previous proposal, but the solution wasn't of almost > any good. > > Now, the purpose of the birthday value is to protect the hosts > from replay attacks where the attacker simulates loss of > state at one of the hosts. Here we have now a problem, as > it is possible for an attacker to make a host to increment > the birthday value and get an R1 with an incremented > birthday value. Since the R1 does not have the peer's HIT, > it can be sent to any peer, triggering it to perform I2 > computation. > > The purpose of the transaction ID, on the other hand, is to > prevent reply attacks using earlier messages captured (during > the current incarnation of the HIP SA). Hence, the birthday > value protects the hosts from simulated state loss, and the > transaction ID protects the host from captured and replayed > packets. > > I think that these two functions should be kept separate, but I > agree that somehow linking them might increase security. That > is, if a reply contained both the birthday value (or low order > bits of it) and a transaction ID, that would make naive replay > attacks slightly harder. Thanks for this insight ! It's now clear to me that birthday and transaction ID are clearly two separates function, and should consequently be kept separate. About a possible linking between the two, perhaps we can initialize a transaction ID to the low order bits of the association's birthday, thus garantying that a given NES exchange (or whatever packet round trip) is truly bind to a given HIP association (via the association birthday's low order bits). > Right now I'm inclined towards the following conclusions: > > - We should replace the R1, when sent on response to ESP, > with a RESYNC packet. That would contain the R1 puzzle > plus (some part of) the ESP packet that triggered it. > A vanilla R1 should be only sent in response to an I1. Agree. > Since the Initiator knows when it has sent an I1 and when > it has sent an ESP packet using a given SPI and SA, this > should plug the problem of simulated state loss, provided > that the Initiator can check that the included portion of > the ESP packet was indeed sent by it. How that is done, > exactly, seems to require some more thinking. One way to bind the ESP packet chunk to an HIP SA might be to check the ESP Sequence Number (SN) included in it against the current ESP SA SN. Ideally the current ESP SN should be a few more than the SN included in the returned ESP chunk (because there's only one RTT). Perhaps the protocol can defines an anti replay window against returned ESP SN (in RESYNC packets), but I dunno how many packets long it should be. This is, in essence, equivalent to include the ESP SN in some HIP parameters... > - It looks like a good idea to add explicit sequence numbers > into the base HIP header. The sending sequence number could > simply be a few low order bits (maybe 8), since the HIP > association is terminated anyway after some number of > control packets have been sent unanswered. The reply > sequence number must be larger, however, and probably should > include low order bits of the birthday, to prevent replay > attacks. (The birthday bits are not really needed, since > the KEYMAT is different, but if they can be easily included, > they provide some minimal added robustness against the case > where the network reorders packets during resynchronization.) I'm not sure we need a sending _and_ a reply SN, but I guess I'm missing something; My understanding is that the SN is used by a peer to link together request and replies, so if a peer receive a request stamped with SN_i, it replies with a reply stamped with SN_i+1; And while reXmit, a peer increment by 1 the SN it used the last time (i.e., sending packet with SN SN_i, and reXmit with SN_i+1) Having that being said, I'm in favor of adding SN in the base header, and furthermore to initialize the SN to the birthday counter of the initial sending party (as stated above). [I'm leaving for two weeks of vacation, so I apologize in advance for my unresponsiveness. However I wish you all a very good christmas and a happy new year] Thanks, --julien From Julien.Laganier@Sun.COM Fri Dec 19 13:02:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Dec 19 13:02:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FA0@xch-nw-27.nw.nos.boeing.com> Message-ID: <200312191937.41789.julien.laganier@sun.com> On Friday 19 December 2003 12:45, Pekka Nikander wrote: > Tom, > > > In thinking about this and Pekka's posts some more, this > > option appeals to me if it is made a parameter or part of > > an existing parameter rather than base header. > > I'm, on the other hand, inclined to think that we most > probably should have sequence numbers in the base header. > That would make the protocol more future proof, i.e., > I would foresee less complications with future extensions. Agree. > I don't see any real need to reflect the birthday value > in all packets. Since the birthday value is tied to > incarnation of the HIP association, and each incarnation > has a different DH session key (and therefore different > HMAC values), the only case where we need the birthday as > replay protection is in resynching. Agree too, thanks to your insight in your previous mail. > > In my view, birthday's primary role is to prevent replay > > attacks of packets that are vulnerable to such. The > > main (only?) one seems to be NES. > > Well, using birthday to protect NES replays would > require that you bump up birthday on each NES. You > are still using the same HIP keys, and therefore the > HIP keys (i.e. the HMAC) does not provide enough of > replay protection. I would really like to separate > replay protection on incarnation level, semantic > packet level, and retransmission level. (See below.) > > Remember that Bob's original design used ESP sequence > numbers as replay protection in NES. We removed it > since it would have been very cumbersome to implement > in many cases. > > > But RESYNCH might also be a candidate for > > "avoidance of replay". > > Resynch would need birthday protection. As far as > I understand, resynching was the reason why the > birthday value was added to the protocol in the first > place. > > > A host also wants its NES acked. So it would seem that > > there needs to be at least a one-bit sequence number of > > some sort to identify it. > > Yes. However, just to make the protocol more future > proof, I would prefer to have generic, per packet > sequence numbers. Yet another 'agree too'. > Let me try to explain my current understanding in detail: > > The main goal of this exercise is replay protection. > We seem to have potential replay in at least four > different cases: > > 1. A RESYNCH packet could be replayed. Birthday > and including a portion of the ESP packet can > be used to plug this. Yes. I was thinking to use the ESP SN to do that [but as you stated before, It might be (really) hard to implement this without trashing all around in the IP/IPsec stack] > 2. A message from an earlier incarnation of a > HIP association (between a given pair of HITs) > could be replayed. The different DH session > key, together with HMACs, already plugs this. Yes, but then I feel we need to emphasize the need for frequent rekeying in the spec. > 3. A message from the current incarnation of the > HIP association can be replayed. There is > currently no generic mechanism for protecting > against this. > > In his earlier design, Bob re-used ESP > replay counters. This is hard to implement, > and won't work when you have several parallel > SAs (as in the case of multi-homing). > > Random transaction IDs would work, but would > be fairly complex to implement right. > > Explicit sequence numbers, included in each > packet, looks like the most generic and > simplest solution, at least to me. Yes. And binding SNs to the initial sending party birthday counter might add some security against SN roll over. > 4. An attacker can replay a message to simulate > message retransmission. This is not a security > problem, since messages may get duplicated in > the network anyway. Yep. > Does that sound right? If so, then it should be > fairly easy to derive design recommendations from > the above. AFAICS, I agree with your analysis, but let's other people speak [if they have time to ;-] Thanks, --julien From thomas.r.henderson@boeing.com Fri Dec 19 21:32:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Dec 19 21:32:00 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FB2@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, December 19, 2003 3:46 AM > To: Henderson, Thomas R > Cc: Julien Laganier; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Indicating Reply Requested and renaming NES? >=20 >=20 > Tom, >=20 > > In thinking about this and Pekka's posts some more, this > > option appeals to me if it is made a parameter or part of > > an existing parameter rather than base header. >=20 > I'm, on the other hand, inclined to think that we most > probably should have sequence numbers in the base header. > That would make the protocol more future proof, i.e., > I would foresee less complications with future extensions. OK, I am willing to concede this point for the sake of potential extension. But can we put it in 8-bits in the=20 existing control field? And I assume that it monotonically increases with each packet sent (such as I1 =3D 0, R1=3D 0, I2=3D1, R2=3D1, ...)? >=20 > Remember that Bob's original design used ESP sequence > numbers as replay protection in NES. We removed it > since it would have been very cumbersome to implement > in many cases. we found this to be true-- requires PF_KEY extensions >=20 > > But RESYNCH might also be a candidate for > > "avoidance of replay". >=20 > Resynch would need birthday protection. As far as > I understand, resynching was the reason why the > birthday value was added to the protocol in the first > place. >=20 I am thinking that birthday may not be needed if we make Resynch a variant of I1 and I2 and if we have the=20 host generate new R1s upon every successful Resynch. =20 By variant, I mean that it turns on a "resynch" bit in the control field. Can you elaborate an attack on Resynch if it follows the below procedures, *not* using birthday? =20 Resynch I1 -> <- R1 Resynch I2 -> <- R2 (responder regenerates R1s) Tom From petri.jokela@nomadiclab.com Tue Dec 23 02:24:00 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Dec 23 02:24:00 2003 Subject: [Hipsec] Pre-1 version of draft-moskowitz-hip-09 In-Reply-To: <3FD9B011.40000@kolumbus.fi> References: <3FD9B011.40000@kolumbus.fi> Message-ID: <3FE7F603.3040701@nomadiclab.com> Petri Jokela wrote: > I uploaded the current version (-09-pre1) of the hip draft to > hip4inter.net: > > http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-09-pre1.txt XML2RFC script cut some stuff away from the draft, so I had to run it again. On the web-site, there is now a new version of the txt-file (still under the same name), a html-version and a diff between -08 and -09-pre1. Issue-tracker broke down for some reason. I hope I get the new tracker up and running before 2004. /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 jukka.ylitalo@nomadiclab.com Mon Dec 29 02:37:01 2003 From: jukka.ylitalo@nomadiclab.com (Jukka Ylitalo) Date: Mon Dec 29 02:37:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> <3FE1C409.70701@nomadiclab.com> Message-ID: <3FEFE241.6010100@nomadiclab.com> Pekka Nikander wrote: > Jukka, > >>> Since the Initiator knows when it has sent an I1 and when >>> it has sent an ESP packet using a given SPI and SA, this >>> should plug the problem of simulated state loss, provided >>> that the Initiator can check that the included portion of >>> the ESP packet was indeed sent by it. How that is done, >>> exactly, seems to require some more thinking. >> >> >> Hmm. The original ESP sender, host A, could reply to the RESYNC >> with RESYNC-REPLY message (a variant of NES). The RESYNC-REPLY >> message would contain current SPI-A, ESP sequence number that is >> expected >> from B, and a piggybacked ESP message going to B. Host B mirrors the >> whole received RESYNC-REPLY message including piggybacked ESP >> message. However, it changes the SPI-B to SPI-A and the ESP >> sequence number >> before sending the message back to A. Finally, A verifies the >> integrity of >> the ESP message using its own SA. We have to be careful with the SPI >> values due to the HIP aware middle-boxes. What do you think? > > > I don't see why we need this complicated mechanism. > Can't the rebooted host simply include the R1 parameters > and the (beginning of) the ESP packet into the RESYNCH > packet? You don't need to sign or anything the ESP part, > just sign the R1 part as in R1. Why do you need an explicit > RESYNC-REPLY packet? Hi Pekka, You are right. My initial proposal was complex and it didn't explain my thoughts. Basically, it is good to avoid the signature checking at the Initiator's end-point when it receives resynch-R1. I may be wrong, but I belive that a malicious node may send a storm of resync-R1s. The R1 receiver must always verify the signature in R1 to be sure that the peer has rebooted. Therefore, a malicious node may course a CPU DoS attack and consume CPU power at the initiator's end-point. (A buzy server may receive a storm of resync-R1s. It must either drop the resync-R1s, or verify them.) One way to avoid the attack is to make a Return Routability test to check, using symmetric cryptography, that the peer has really rebooted. If the RR test fails the resync-R1 receiver should believe that the peer has rebooted. [May be I have not understood the problem well enough, but I presented anyway this viewpoint.] --Jukka > > The hard part I was referring to is to find out whether > the host really sent the ESP packet included into the > RESYNCH packet. There is no obvious way of doing this, > since the hosts do not store the ESP packets they send. > > So, what was your reason for this complicated three > message sequence? And what are those SPI-A and SPI-B? > Maybe I was unclear in my original message? I'm sorry > to say but I'm really confused. > > --Pekka > > > From pekka.nikander@nomadiclab.com Mon Dec 29 02:52:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 29 02:52:00 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <3FEFE241.6010100@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> <3FE1C409.70701@nomadiclab.com> <3FEFE241.6010100@nomadiclab.com> Message-ID: <10E07D45-39D9-11D8-8BF8-000393CE1E8C@nomadiclab.com> Jukka, >>>> Since the Initiator knows when it has sent an I1 and when >>>> it has sent an ESP packet using a given SPI and SA, this >>>> should plug the problem of simulated state loss, provided >>>> that the Initiator can check that the included portion of >>>> the ESP packet was indeed sent by it. How that is done, >>>> exactly, seems to require some more thinking. >> >> >> I don't see why we need this complicated mechanism. > > You are right. My initial proposal was complex and it didn't explain > my thoughts. > Basically, it is good to avoid the signature checking at the > Initiator's end-point when > it receives resynch-R1. I may be wrong, but I belive that a malicious > node may send a storm > of resync-R1s. Yes, I agree, and you are right. > The R1 receiver must always verify the signature in R1 to be sure that > the peer has rebooted. Therefore, a malicious node may course a CPU > DoS attack and consume CPU power at the initiator's end-point. (A buzy > server may receive a storm of resync-R1s. It must either drop the > resync-R1s, or verify them.) Well, the purpose for including a portion of the ESP packet is to include a kind of RR check into the procedure. The to-be-Initiator sends an ESP packet, and gets back an resynch-R1. It checks that the resynch-R1 contains (a portion) of the ESP packet it has recently sent. The only problem I see is the way of checking that the ESP packet has been recently sent. The SPI and replay protection fields probably help, but the details need to be worked out. > One way to avoid the attack is to make a Return Routability test to > check, using symmetric cryptography, that the peer has really > rebooted. If the RR test fails the resync-R1 receiver > should believe that the peer has rebooted. I don't see how symmetric crypto helps here. You don't have any shared state since the other host has (assumedly) rebooted. Hence, what you can use is simple RR. Including the ESP packet into the resynch-R1 creates a simple RR test. But maybe I am missing something? --Pekka From jukka.ylitalo@nomadiclab.com Mon Dec 29 05:24:03 2003 From: jukka.ylitalo@nomadiclab.com (Jukka Ylitalo) Date: Mon Dec 29 05:24:03 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <10E07D45-39D9-11D8-8BF8-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <44EF98AA-2C82-11D8-A25D-000393CE1E8C@nomadiclab.com> <200312121426.50947.julien.laganier@sun.com> <3FE1C409.70701@nomadiclab.com> <3FEFE241.6010100@nomadiclab.com> <10E07D45-39D9-11D8-8BF8-000393CE1E8C@nomadiclab.com> Message-ID: <3FF00976.9000403@nomadiclab.com> Pekka Nikander wrote: > Well, the purpose for including a portion of the ESP packet is > to include a kind of RR check into the procedure. The > to-be-Initiator sends an ESP packet, and gets back an > resynch-R1. It checks that the resynch-R1 contains (a portion) > of the ESP packet it has recently sent. > > The only problem I see is the way of checking that the > ESP packet has been recently sent. The SPI and replay > protection fields probably help, but the details need > to be worked out. Right. Buffering every outgoing ESP packet is not a feasible solution. One alternative would be to implement a reply protection window mechanism also for outgoing ESP packets. (The window's right end would be at the latest outgoing sequence number.) Whenever, the to-be-initiator receives resynch-R1, it may verify the sequence number of the included ESP message, using the outgoing replay protection window. The problems arises, when the reply protection window left end is advanced too fast. Another alternative is to buffer every x:th outgoing ESP sequence number, and store it in the HIP context. The problem arises at the other end-point. In other words, How the responder knows, which of the incoming ESP message it should include into the resync-R1 message? The to-be-initiator should "tag" the special ESP messages. The responder could use the lowest order bit of the SPI number for tagging. That is, every SA would be identified with two SPIs with different low order bit. The to-be-initiator sends every x:th packet with "tagged" SPI. When, the responder receives the SPI with low order bit 1, it replies with resync-R1. However, this approach would require changes in the IPSec implementation. Another alternative would be to use an extra "reboot" SA between the hosts. The to-be-initiator should send every x:th messages using the "reboot" SA. The "reboot" SAs would be identified with SPIs with low order bit 1. Normal SPIs would contain low order bit 0. (I believe, that there are several other, and probably better solutions.) > >> One way to avoid the attack is to make a Return Routability test to >> check, using symmetric cryptography, that the peer has really >> rebooted. If the RR test fails the resync-R1 receiver >> should believe that the peer has rebooted. > > > I don't see how symmetric crypto helps here. You don't > have any shared state since the other host has > (assumedly) rebooted. Hence, what you can use is simple RR. > Including the ESP packet into the resynch-R1 creates > a simple RR test. > > But maybe I am missing something? Yes, you are rigth. What I meant, is that the resync-R1 receiver should not have to sign anything. The resync-R1 receiver should use HMAC to protect the RR test, instead of using signatures. If the authentic responder has not rebooted and has a context, the authentic responder is able to verify the RR packet and reply to it. However, by sending a storm of resync-R1s, the malicious node may cause extra RR-tests and extra traffic. Finally, I prefer more your original resynch-R1 proposal. > > --Pekka > > > -- Jukka From pekka.nikander@nomadiclab.com Mon Dec 29 06:38:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 29 06:38:02 2003 Subject: [Hipsec] Updated HIP mobility & multi-homing draft Message-ID: I've posted an updated version of the HIP mobility and multi-homing draft to the repositories. In the mean time, it is available from the following URLs. http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.txt http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.html http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.xml This version is *considerably* different from the previous one, in the sense that it has been fully integrated with the new NES mechanism. The AC and ACR packets are gone. It is quite hard to understand the protocol without knowing the details of the base HIP protocol. I'd like to get some feedback of the approach. My belief is that the new approach will result in less code, provided that the hosts already implement NES (which is mandatory in HIP). However, it is also appear harder to understand. I'm now starting to work on another draft, which will explain the HIP multihoming mechanism from a multi6 point of view. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Dec 29 06:59:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 29 06:59:02 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FB2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FB2@xch-nw-27.nw.nos.boeing.com> Message-ID: <90BF2F69-39FB-11D8-BBAE-000393CE1E8C@nomadiclab.com> >> I'm, on the other hand, inclined to think that we most >> probably should have sequence numbers in the base header. >> That would make the protocol more future proof, i.e., >> I would foresee less complications with future extensions. > > OK, I am willing to concede this point for the sake of > potential extension. Good. > But can we put it in 8-bits in the > existing control field? Well, that is a tricky question. We certainly need to have a much longer sequence number counter internally, and that longer count MUST be covered by the HMAC in the packets. On the other hand, I can't foresee how we could have more than a few HIP packets on the fly at the same time. Hence, including only 8 low order bits of the counter to the packet is probably enough. From that point of view, yes, we can put it into 8-bits of the control field. For replies, there could be a separate parameter that contains the sender's full sequence number. (IMHO, 24-bit sequence number would be long enough -- I can't easily imagine HIP associations with more than 2^24-1 packets. Even 16 might do.) The problem is to define where to put the rest of the sequence number bits while computing and verifying HMACs and SIGNATURES. We could use the checksum field (since it is currently zeroed), but the bytes would then be in an awkward order, resulting in pretty silly code. OTOH, we can't exchange the locations of control bits and checksum if we want to retain the possibility of using UDP hardware to compute and check the checksum. Opinions? > And I assume that it > monotonically increases with each packet sent (such > as I1 = 0, R1= 0, I2=1, R2=1, ...)? Yes. >> Resynch would need birthday protection. ... > Can you elaborate an attack on Resynch if it follows > the below procedures, *not* using birthday? > > Resynch I1 -> > <- R1 > Resynch I2 -> > <- R2 > (responder regenerates R1s) You have to explain your thoughts in more detail before I can say anything about it. --Pekka From pekka.nikander@nomadiclab.com Mon Dec 29 07:05:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 29 07:05:01 2003 Subject: [Hipsec] Indicating Reply Requested and renaming NES? In-Reply-To: <200312191910.15147.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5F26@xch-nw-27.nw.nos.boeing.com> <200312191910.15147.julien.laganier@sun.com> Message-ID: <616C6A7D-39FC-11D8-BBAE-000393CE1E8C@nomadiclab.com> Julien, > About a possible linking between the two, perhaps we can initialize a > transaction ID to the low order bits of the association's birthday, > thus garantying that a given NES exchange (or whatever packet round > trip) is truly bind to a given HIP association (via the association > birthday's low order bits). I don't immediately see what's the benefit of initiating the sequence number from the birthday. Would you please explain? > One way to bind the ESP packet chunk to an HIP SA might be to check > the ESP Sequence Number (SN) included in it against the current ESP > SA SN. Ideally the current ESP SN should be a few more than the SN > included in the returned ESP chunk (because there's only one RTT). Agree. But I still fail to see the details. Maybe I need to write code. > Perhaps the protocol can defines an anti replay window against > returned ESP SN (in RESYNC packets), but I dunno how many packets > long it should be. Yes. Probably as large as the underlying ESP replay window. > This is, in essence, equivalent to include the ESP SN in some HIP > parameters... Good observation. OTOH, including the (beginning) of an ESP packet has a couple of benefits: - its easier, you just blindly copy bytes - it gives the receiver the some extra possibilities, e.g., to check also the IV in addition to the SN, or something similar. The receiver can even decrypt the beginning of the encrypted portion, and use some data from there. > I'm not sure we need a sending _and_ a reply SN, but I guess I'm > missing something; My understanding is that the SN is used by a peer > to link together request and replies, so if a peer receive a request > stamped with SN_i, it replies with a reply stamped with SN_i+1; And > while reXmit, a peer increment by 1 the SN it used the last time > (i.e., sending packet with SN SN_i, and reXmit with SN_i+1) I don't believe that all HIP exchanges will happen in lock-step fashion. There will be multiple transactions going on at the same time, especially when you have multiple mobile interfaces. Hence, both parties need to have separate sequence numbers, and the relevant replies need to include the complete sequence number of the packet that they refer to. > [I'm leaving for two weeks of vacation, so I apologize in advance for > my unresponsiveness. However I wish you all a very good christmas and > a happy new year] [I wish you will have had a nice and refreshing vacation by the time you come to read this.] --Pekka From thomas.r.henderson@boeing.com Tue Dec 30 11:06:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Dec 30 11:06:01 2003 Subject: HIP resynch (was RE: [Hipsec] Indicating Reply Requested and renaming NES?) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FD8@xch-nw-27.nw.nos.boeing.com> >=20 > But maybe I am missing something? >=20 > --Pekka I feel this way regarding this discussion. Maybe we are all operating under different assumed requirements. As I've said, I'm not even sure of the requirement that a host respond to an unknown SPI with a HIP message. This seems to me to be a "MAY," if at all, with caveats that hosts should take care in some way to avoid mixing HIP SAs with IKE or otherwise negotiated SAs (how?). =20 So I think that the first step should be to decide=20 whether the receipt of an unknown SPI=20 (MUST|SHOULD|MAY|SHOULD NOT|MUST NOT) trigger a=20 HIP resynchronization attempt.=20 Anyway, it seems to me that any host that is sending some kind of resynch message is playing the role of an initiator, not a responder. So why not use a HIP exchange=20 (I1-R2), which is already designed to be more DoS-resilient for responders? As I mentioned, there could be a resynch=20 bit in the control field, which has the semantics in the=20 I1 of meaning "I think I might have lost my state, so=20 if we succeed in this handshake, please delete any=20 pre-existing HIP SA pertaining to me." The resynch bit also might trigger a harder cookie puzzle if=20 desired, to thwart possible attacks. > > Can you elaborate an attack on Resynch if it follows > > the below procedures, *not* using birthday? > > > > Resynch I1 -> > > <- R1 > > Resynch I2 -> > > <- R2 > > (responder regenerates R1s) >=20 > You have to explain your thoughts in more detail before > I can say anything about it. My thinking is that if one changes the R1s frequently enough, there is immunity to replay attacks, and birthday is not needed. Replay of I1s is not a big deal. Replay of I2s is more of a concern, but that is only possible if there is a match on the cookie puzzle. Tom From thomas.r.henderson@boeing.com Tue Dec 30 20:45:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Dec 30 20:45:01 2003 Subject: [Hipsec] Pre-1 version of draft-moskowitz-hip-09 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1FB@xch-nw-27.nw.nos.boeing.com> Petri, Please see below a proposed Appendix F. Other implementors may want to check these results, since getting checksums to agree has been a sore point in interoperability testing. Tom Internet-Draft Host Identity Protocol December 2003 =20 Appendix F. Example checksums for HIP packets =20 The HIP checksum for HIP packets is specified in Section 6.1.2. =20 Checksums for TCP and UDP packets running over HIP-enabled security=20 associations are specified in Section 3.5. The examples below use IP = addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- compatible IPv6 formats), and type 1 HITs with the first two bits = "01"=20 followed by 124 zeroes followed by a decimal 1 or 2, respectively. =20 =20 F.1. IPv6 HIP example (I1)=20 =20 Source Address: ::c0a8:0001 Destination Address: ::c0a8:0002 Upper-Layer Packet Length: 40 0x28 Next Header: 99 0x63 Payload Protocol: 59 0x3b Header Length: 4 0x04 Packet Type: 1 0x01 Version: 1 0x1 Reserved: 0 0x0 Control: 0 0x0000 Checksum: 49672 0xc208 =20 Sender's HIT: 4000::0001 Receiver's HIT: 4000::0002 =20 F.2. IPv4 HIP packet (I1) =20 The IPv4 checksum value for the same example I1 packet is the same as = the IPv6 checksum (since the checksums due to the IPv4 and IPv6=20 pseudo-header components are the same). =20 F.3. TCP segment=20 =20 Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets=20 use the IPv6 pseudo-header format [8], with the HITs used in place of = the IPv6 addresses. =20 Sender's HIT: 4000::0001 Receiver's HIT: 4000::0002 Upper-Layer Packet Length: 20 0x14 Next Header: 6 0x06 Source port: 32769 0x8001 Destination port: 22 0x0016 Sequence number: 1 0x00000001 Acknowledgment number: 0 0x00000000 Header length: 20 0x14 Flags: SYN 0x02 Window size: 5840 0x16d0 Checksum: 54519 0xd4f7 Urgent pointer: 0 0x0000 From andrew@indranet.co.nz Wed Dec 31 17:01:02 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Dec 31 17:01:02 2003 Subject: HIP resynch (was RE: [Hipsec] Indicating Reply Requested and renaming NES?) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FD8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5FD8@xch-nw-27.nw.nos.boein g.com> Message-ID: <424510.1072957105@[192.168.1.249]> --On Tuesday, 30 December 2003 8:42 a.m. -0800 "Henderson, Thomas R" wrote: > >> >> But maybe I am missing something? >> >> --Pekka > > I feel this way regarding this discussion. Maybe we > are all operating under different assumed requirements. > > As I've said, I'm not even sure of the requirement that > a host respond to an unknown SPI with a HIP message. > This seems to me to be a "MAY," if at all, with caveats > that hosts should take care in some way to avoid mixing > HIP SAs with IKE or otherwise negotiated SAs (how?). > So I think that the first step should be to decide > whether the receipt of an unknown SPI > (MUST|SHOULD|MAY|SHOULD NOT|MUST NOT) trigger a > HIP resynchronization attempt. I'd like to see MAY, with SHOULD by default. I've been doing a lot of embedded work, and we can lose state very easily (we have paranoid hardware watchdogs and no mass storage; all quickly changing state is in RAM). > Anyway, it seems to me that any host that is sending > some kind of resynch message is playing the role of an > initiator, not a responder. So why not use a HIP exchange > (I1-R2), which is already designed to be more DoS-resilient > for responders? As I mentioned, there could be a resynch > bit in the control field, which has the semantics in the > I1 of meaning "I think I might have lost my state, so > if we succeed in this handshake, please delete any > pre-existing HIP SA pertaining to me." The resynch > bit also might trigger a harder cookie puzzle if > desired, to thwart possible attacks. That makes a lot of sense. I've been lurking in this discussion, and it seems to have been generating some really complex ideas for what seems to me to be little benefit, whereas this is a nice, clean and simple solution. >> > Can you elaborate an attack on Resynch if it follows >> > the below procedures, *not* using birthday? >> > >> > Resynch I1 -> >> > <- R1 >> > Resynch I2 -> >> > <- R2 >> > (responder regenerates R1s) >> >> You have to explain your thoughts in more detail before >> I can say anything about it. > > My thinking is that if one changes the R1s frequently enough, > there is immunity to replay attacks, and birthday is > not needed. Replay of I1s is not a big deal. Replay of I2s > is more of a concern, but that is only possible if there is > a match on the cookie puzzle. > > Tom Makes sense to me. --------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet-technologies.com/