From mbagnulo@ing.uc3m.es Fri Jan 2 03:05:03 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Fri Jan 2 03:05:03 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: Message-ID: Hi Pekka, If i understand it correctly, the draft essentially specifies the required mecnahins and extensions to the HIP protocol to safely modify the set of addresses that can be used by two communicating hosts to reach each other. While this is a fundamental part of a mechanism to preserve established communications in multi-homed and mobile environments, it is not by itselt enough to provide multi-homing nor mobility support. Additional mechanisms and tools are required to preserve established communications both in mobile and multihomed environments, including mechanisms to deal with ingress filtering (multi-homing and mobility), detect movment (mobility), detect outages (multi-homing), locator selection for initial contact, etc. It would be interesting to try to understand how HIP (and the extensions presented in this draft ) can deal with all these issues, so it can provide a complete solution to preserve established communications. You mention that another draft is comming, perhaps are you planning to inlcude all the rest of the issues in this next draft? Thanks for the draft, regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Pekka Nikander > Enviado el: lunes, 29 de diciembre de 2003 9:15 > Para: hipsec@honor.trusecure.com > CC: multi6@ops.ietf.org > Asunto: Updated HIP mobility & multi-homing draft > > > 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 jari.arkko@piuha.net Fri Jan 2 05:59:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri Jan 2 05:59:01 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: References: Message-ID: <3FF5576D.9020506@piuha.net> Hi Marcelo, Thanks for your comments. Some discussion inline: > If i understand it correctly, the draft essentially specifies the required > mecnahins and extensions to the HIP protocol to safely modify the set of > addresses that can be used by two communicating hosts to reach each other. > While this is a fundamental part of a mechanism to preserve established > communications in multi-homed and mobile environments, it is not by itselt > enough to provide multi-homing nor mobility support. I agree its just a part of the whole solution. > Additional mechanisms and tools are required to preserve established > communications both in mobile and multihomed environments, including > mechanisms to deal with ingress filtering (multi-homing and mobility), I do not understand why we need anything special for ingress filtering. Hosts should only use the addresses they have been given in the particular interface. If you move around, you will use new addresses. > detect movment (mobility), This is definately an issue. We already realized this in Mobile IPv6. Currently, the IETF is planning a new WG to address movement detection issues, the DNA working group. My hope is that the results of that will be generally applicable to HIP, MIPv6, as well as plain hosts with no mobility support. I think we also want to avoid putting solutions for this in the HIP documents themselves. HIP does introduce a few additional twists to movement detection, however. For instance, in Mobile IPv6 you only care about IPv6 to IPv6 movement. In HIP we also need to deal with IPv4 to IPv6, and its also quite likely that you have both IPv4 and IPv6 available at the same time, making you "multi-homed" even on a single link. Still, my hope is that the DNA WG (and related IPv4 efforts) will address these issues. What might be useful perhaps, is an informational document which explains how to apply DNA and related IPv4 mechanisms in the HIP context. However, that can only be done once the results of DNA are ready. > detect outages (multi-homing), This may go beyond what DNA intends to achieve, at least if you intend to detect outages beyoned link-layer connectivity. I think DNA at least _should_ cover link-layer outages, not sure if they think so. Draft-nikander-hip-mm-01 already says that hosts may initiate its own address change due to learning some new "traffic information" or ICMP errors. But there is not a whole lot of text on what the peer does with the multiple addresses it has. I think we need some of this text -- and we are likely going to need a similar approach as taken in the MOBIKE BOF i.e. the multiple addresses are primarily used for for fail-over, not for load-balancing. Or Pekka were you thinking that only the sender controls his own addresses -- but if this were so, sending one current address would suffice... I think we need a way for the responder to change the address of the peer even when its not getting any instructions from the peer. > locator selection for initial contact, etc. Hmm... what's the problem? Selecting among addresses seems simple enough. Probably the draft should say that addresss with the widest scope should be preferred. Or are RFC 3484 rules already sufficient? --Jari From mbagnulo@ing.uc3m.es Sat Jan 3 03:33:01 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Sat Jan 3 03:33:01 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: <3FF5576D.9020506@piuha.net> Message-ID: > > Additional mechanisms and tools are required to preserve established > > communications both in mobile and multihomed environments, including > > mechanisms to deal with ingress filtering (multi-homing and mobility), > > I do not understand why we need anything special for ingress filtering. > Hosts should only use the addresses they have been given in the > particular interface. If you move around, you will use new addresses. In the multihoming case, one interface has multiple global addresses assigned, and the host must select which one to include in the packet as source address Once that the packet leaves the host, it is up to the intrasite routing system to carry the packet to one of the exit isps. The problem appears when the exit isp selected by the routing system and the source address selected by the host don't match (ingress filtering discards the packet) So a mechanism is needed to coordinate the exit isp and the source address Several options are possible, like source routing in multiple flavors, source address rewriting, letting the routing system inform the host which address to use with a given destination address. I guess that it would be interesting to understand how compatible are those mechanisms with the HIP solution... for instance it would be possible to rewrite the source address of the HIP packets? > > > detect movment (mobility), > > This is definately an issue. We already realized this in Mobile IPv6. > Currently, the IETF is planning a new WG to address movement detection > issues, the DNA working group. My hope is that the results of that will > be generally applicable to HIP, MIPv6, as well as plain hosts with no > mobility support. I think we also want to avoid putting solutions for > this in the HIP documents themselves. > I agree that this document shouldn't contain all the issues that i have mentioned. Actually IMHO this document should only contain the extension to support multiple addresses in HIP Then IMHO it would be interesting to have a separate document describing how HIP interact with the other parts of a multihoming solution (and a similar one for mobility i guess) > HIP does introduce a few additional twists to movement detection, > however. For instance, in Mobile IPv6 you only care about IPv6 to IPv6 > movement. In HIP we also need to deal with IPv4 to IPv6, and its also > quite likely that you have both IPv4 and IPv6 available at the same > time, making you "multi-homed" even on a single link. Still, my hope > is that the DNA WG (and related IPv4 efforts) will address these issues. > What might be useful perhaps, is an informational document which explains > how to apply DNA and related IPv4 mechanisms in the HIP context. However, > that can only be done once the results of DNA are ready. > > > detect outages (multi-homing), > > This may go beyond what DNA intends to achieve, at least if you intend > to detect outages beyoned link-layer connectivity. I think DNA at least > _should_ cover link-layer outages, not sure if they think so. > outage detection is essential to provide fault tolerance in multihoming you have to be able to detect an outage in currently used path in order to change to an alternative one there are several ideas about how to do this, like letting the routing system to deal with this (and we need a mechanism to ensure ingress filtering compatibility), let the host to perform outage detection, like using upper layer protocols hints The point is are those mechanism compatible with the hip solution? how do they interact with them? > Draft-nikander-hip-mm-01 already says that hosts may initiate its own > address change due to learning some new "traffic information" or ICMP > errors. But there is not a whole lot of text on what the peer does > with the multiple addresses it has. I think we need some of this text -- > and we are likely going to need a similar approach as taken in the > MOBIKE BOF i.e. the multiple addresses are primarily used for for > fail-over, not for load-balancing. Or Pekka were you thinking that > only the sender controls his own addresses -- but if this were so, > sending one current address would suffice... I think we need a way > for the responder to change the address of the peer even when its > not getting any instructions from the peer. > > > locator selection for initial contact, etc. > > Hmm... what's the problem? Selecting among addresses seems simple > enough. Probably the draft should say that address with the widest > scope should be preferred. Or are RFC 3484 rules already sufficient? > Maybe, maybe not, depending on other parts of the solution (especially on the mechanism you use to provide ingress filtering compatibility) If you use some form of source routing for instance, a packet may not reach its final destination because of its source address, since the destination address may not be reachable through the isp associated with the selected source address, so you may need to retry with a different source address. This is just one example, there may be different problems depending on the additional mechanisms that you choose. So my point is that there are many parts of a multihoming solution and all of them have to interact. So in order to really understand how the hip solution may work, we need to understand how it will interact with all the rest of the pieces that will be used Does this makes sense to you? Regards, marcelo > --Jari > From jari.arkko@piuha.net Sat Jan 3 03:46:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat Jan 3 03:46:01 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: References: Message-ID: <3FF689E3.5000200@piuha.net> marcelo bagnulo wrote: >>>Additional mechanisms and tools are required to preserve established >>>communications both in mobile and multihomed environments, including >>>mechanisms to deal with ingress filtering (multi-homing and mobility), >> >>I do not understand why we need anything special for ingress filtering. >>Hosts should only use the addresses they have been given in the >>particular interface. If you move around, you will use new addresses. > > > In the multihoming case, one interface has multiple global addresses > assigned, and the host must select which one to include in the packet as > source address > Once that the packet leaves the host, it is up to the intrasite routing > system to carry the packet to one of the exit isps. > The problem appears when the exit isp selected by the routing system and the > source address selected by the host don't match (ingress filtering discards > the packet) > > So a mechanism is needed to coordinate the exit isp and the source address > Several options are possible, like source routing in multiple flavors, > source address rewriting, letting the routing system inform the host which > address to use with a given destination address. Ah yes. This is in fact a discussion we had also in the SEND WG during last couple of days. At least some people that I talk to think that this is a general issue for the IPv6 and multi6 WGs to fix their protocols -- the issue appears even when you do not employ e.g. HIP or SEND or MOBIKE. >>HIP does introduce a few additional twists to movement detection, >>however. For instance, in Mobile IPv6 you only care about IPv6 to IPv6 >>movement. In HIP we also need to deal with IPv4 to IPv6, and its also >>quite likely that you have both IPv4 and IPv6 available at the same >>time, making you "multi-homed" even on a single link. Still, my hope >>is that the DNA WG (and related IPv4 efforts) will address these issues. >>What might be useful perhaps, is an informational document which explains >>how to apply DNA and related IPv4 mechanisms in the HIP context. However, >>that can only be done once the results of DNA are ready. >> >> >>>detect outages (multi-homing), >> >>This may go beyond what DNA intends to achieve, at least if you intend >>to detect outages beyoned link-layer connectivity. I think DNA at least >>_should_ cover link-layer outages, not sure if they think so. >> > > > outage detection is essential to provide fault tolerance > in multihoming you have to be able to detect an outage in currently used > path in order to change to an alternative one > there are several ideas about how to do this, like letting the routing > system to deal with this (and we need a mechanism to ensure ingress > filtering compatibility), let the host to perform outage detection, like > using upper layer protocols hints > The point is are those mechanism compatible with the hip solution? how do > they interact with them? Right. No, we do not have an answer to these questions yet. One potential answer is that we can simply track the usage of the SAs that HIP has created. Details to be worked out, however. >>Draft-nikander-hip-mm-01 already says that hosts may initiate its own >>address change due to learning some new "traffic information" or ICMP >>errors. But there is not a whole lot of text on what the peer does >>with the multiple addresses it has. I think we need some of this text -- >>and we are likely going to need a similar approach as taken in the >>MOBIKE BOF i.e. the multiple addresses are primarily used for for >>fail-over, not for load-balancing. Or Pekka were you thinking that >>only the sender controls his own addresses -- but if this were so, >>sending one current address would suffice... I think we need a way >>for the responder to change the address of the peer even when its >>not getting any instructions from the peer. >> >> >>>locator selection for initial contact, etc. >> >>Hmm... what's the problem? Selecting among addresses seems simple >>enough. Probably the draft should say that address with the widest >>scope should be preferred. Or are RFC 3484 rules already sufficient? >> > > > Maybe, maybe not, depending on other parts of the solution (especially on > the mechanism you use to provide ingress filtering compatibility) I think the ingress filtering compatibility has to be solved generally, outside HIP. Perhaps as a part of updates to ND, or maybe in SEND. > If you use some form of source routing for instance, a packet may not reach > its final destination because of its source address, since the destination > address may not be reachable through the isp associated with the selected > source address, so you may need to retry with a different source address. > This is just one example, there may be different problems depending on the > additional mechanisms that you choose. > > So my point is that there are many parts of a multihoming solution and all > of them have to interact. So in order to really understand how the hip > solution may work, we need to understand how it will interact with all the > rest of the pieces that will be used > > Does this makes sense to you? It does. I'm just trying to understand the best way to address this "big picture" problem. Actually, maybe you or someone else can help here, as I have not been involved in multi6 work. Is there a problem statement or an explanation of functionality that would cover all these aspects? --Jari From mohta@necom830.hpcl.titech.ac.jp Sat Jan 3 06:03:03 2004 From: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat Jan 3 06:03:03 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: <3FF689E3.5000200@piuha.net> References: <3FF689E3.5000200@piuha.net> Message-ID: <3FF6AA64.6020506@necom830.hpcl.titech.ac.jp> Jari Arkko; > marcelo bagnulo wrote: > >>>> Additional mechanisms and tools are required to preserve established >>>> communications both in mobile and multihomed environments, including >>>> mechanisms to deal with ingress filtering (multi-homing and mobility), > Ah yes. This is in fact a discussion we had also in the SEND WG during last > couple of days. At least some people that I talk to think that this is > a general issue for the IPv6 and multi6 WGs to fix their protocols -- the > issue appears even when you do not employ e.g. HIP or SEND or MOBIKE. That's why proposals should be intended to be complete. At this stage, incomplete solutions are totally useless for productive discussions. However, the solutions are not required to solve mobility specific ingress filtering issues, unless they actively disturb exsiting capability of ingress filtering with some existing mobility protocols. > Right. No, we do not have an answer to these questions yet. One > potential answer is that we can simply track the usage of the SAs > that HIP has created. Details to be worked out, however. You can work forever to fix the details, only after which, make public proposals. > It does. I'm just trying to understand the best way to address this "big > picture" problem. Actually, maybe you or someone else can help here, as I > have not been involved in multi6 work. Is there a problem statement or an > explanation of functionality that would cover all these aspects? Multi6 is expected to have a completed solution on multihoming problems of IPv6. Masataka Ohta From mbagnulo@ing.uc3m.es Sat Jan 3 14:40:01 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Sat Jan 3 14:40:01 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: <3FF689E3.5000200@piuha.net> Message-ID: > Ah yes. This is in fact a discussion we had also in the SEND WG > during last > couple of days. At least some people that I talk to think that this is > a general issue for the IPv6 and multi6 WGs to fix their protocols -- the > issue appears even when you do not employ e.g. HIP or SEND or MOBIKE. I agree this is a common problem of many of the multihoming solution, and it should be addressed by each of the particualr solutions. Since we are considering a multihoming solution based in HIP, we should try to understand how a HIP solution can deal with this and how it can interact with possible solutions for this problem. ... > > It does. I'm just trying to understand the best way to address this "big > picture" problem. Actually, maybe you or someone else can help here, as I > have not been involved in multi6 work. I can try to help with this. > Is there a problem statement or an > explanation of functionality that would cover all these aspects? RFC 3582 contains the goals for multihoming Elliot's draft contain a good amount of interesting questions that we should try to answer when designing a multi6 solution (draft-lear-multi6-things-to-think-about-00.txt) You can also read D. Crocker's draft for an analysis of the big picture draft-crocker-mast-analysis-01.txt Hope this helps, Regards, marcelo > > --Jari > > > From mbagnulo@ing.uc3m.es Sat Jan 3 14:40:04 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Sat Jan 3 14:40:04 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: <3FF6AA64.6020506@necom830.hpcl.titech.ac.jp> Message-ID: > That's why proposals should be intended to be complete. > > At this stage, incomplete solutions are totally useless for > productive discussions. FWIW, IMHO this HIP draft is interesting and useful Regards, marcelo From mohta@necom830.hpcl.titech.ac.jp Sat Jan 3 20:45:02 2004 From: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat Jan 3 20:45:02 2004 Subject: [Hipsec] RE: Updated HIP mobility & multi-homing draft In-Reply-To: References: Message-ID: <3FF77928.2030902@necom830.hpcl.titech.ac.jp> marcelo bagnulo; >>That's why proposals should be intended to be complete. >> >>At this stage, incomplete solutions are totally useless for >>productive discussions. > > > FWIW, IMHO this HIP draft is interesting and useful With your context of: > Since we are considering a multihoming solution based in HIP, it should be. But, I am not interested in considering a multihoming solution based on HIP that it is neither interesting nor useful. Masataka Ohta From halestino@ipb.pt Thu Jan 8 11:11:00 2004 From: halestino@ipb.pt (Halestino Pimentel) Date: Thu Jan 8 11:11:00 2004 Subject: [Hipsec] Problem installing Hipl Message-ID: <3FFD8A0E.7020602@ipb.pt> Hello, I'm a "rookie" in HIPL but I would like to make some tests with the recent created package to see if HIP really offers the advantages stated in the drafts. Since it's an experimental version I would like to test it under User Mode Linux but I'm with some problems. Here are all the steps I've made: - host$ mkdir ~/uml - host$ cd ~/uml - host$ tar -xvzf hipl.tar.gz - host$ cd hipl--main--1.0/linux If I issue the "make xconfig" command there is no problem with the kernel options since I can see the Cryptography support (CryptoAPI) options. If I patch the kernel with a uml-patch-2.4.20-X[-X].bz2 to compile it in User Mode Linux, I get any failed hunk but when I issue the "make xconfig ARCH=um" command I can see the Cryptography support (CryptoAPI) options. So, what I'm doing wrong? Thanks for any help. Halestino From halestino@ipb.pt Thu Jan 8 13:09:01 2004 From: halestino@ipb.pt (Halestino Pimentel) Date: Thu Jan 8 13:09:01 2004 Subject: [Fwd: [Hipsec] Problem installing Hipl] Message-ID: <3FFDA5BF.5030309@ipb.pt> After reading my mail I realise that it contained a big mistake. I forward it to the list again but without the error. I would realy apreciate any feedback. Sorry about my english and thanks again. Halestino -------- Original Message -------- Subject: [Hipsec] Problem installing Hipl Date: Thu, 08 Jan 2004 16:49:18 +0000 From: Halestino Pimentel To: hipsec@honor.trusecure.com Hello, I'm a "rookie" in HIPL but I would like to make some tests with the recent created package to see if HIP really offers the advantages stated in the drafts. Since it's an experimental version I would like to test it under User Mode Linux but I'm with some problems. Here are all the steps I've made: - host$ mkdir ~/uml - host$ cd ~/uml - host$ tar -xvzf hipl.tar.gz - host$ cd hipl--main--1.0/linux If I issue the "make xconfig" command there is no problem with the kernel options since I can see the Cryptography support (CryptoAPI) options. If I patch the kernel with a uml-patch-2.4.20-X[-X].bz2 to compile it in User Mode Linux, I get any failed hunk but when I issue the "make xconfig ARCH=um" command I can*'t* see the Cryptography support (CryptoAPI) options. So, what I'm doing wrong? Thanks for any help. Halestino _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From Kristian.Slavov@iki.fi Fri Jan 9 05:57:01 2004 From: Kristian.Slavov@iki.fi (Kristian Slavov) Date: Fri Jan 9 05:57:01 2004 Subject: [Fwd: [Hipsec] Problem installing Hipl] In-Reply-To: <3FFDA5BF.5030309@ipb.pt> References: <3FFDA5BF.5030309@ipb.pt> Message-ID: <3FFE91EE.3040003@iki.fi> Halestino Pimentel wrote: > Hello, > > I'm a "rookie" in HIPL but I would like to make some tests with the > recent created package to see if HIP really offers the advantages stated > in the drafts. > Since it's an experimental version I would like to test it under User > Mode Linux but I'm with some problems. > Here are all the steps I've made: > > - host$ mkdir ~/uml > - host$ cd ~/uml > - host$ tar -xvzf hipl.tar.gz > - host$ cd hipl--main--1.0/linux > > If I issue the "make xconfig" command there is no problem with the > kernel options since I can see the Cryptography support (CryptoAPI) > options. > If I patch the kernel with a uml-patch-2.4.20-X[-X].bz2 to compile it in > User Mode Linux, I get any failed hunk but when I issue the "make > xconfig ARCH=um" command I can*'t* see the Cryptography support > (CryptoAPI) options. > So, what I'm doing wrong? You can't use the default uml-patch-2.4.20-X. You can find two UML patches in test/patches directory of the HIPL source. Try using one of them. I think the safest bet would be the hip-uml-2.4.20-8.patch. If you experience problems or want to give feedback, please use hipl@gaijin.tky.hut.fi -- Kristian Slavov From petri.jokela@nomadiclab.com Fri Jan 9 07:31:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Jan 9 07:31:01 2004 Subject: [Hipsec] Pre-1 version of draft-moskowitz-hip-09 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1FB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC1FB@xch-nw-27.nw.nos.boeing.com> Message-ID: <3FFEA7FA.1070502@nomadiclab.com> Henderson, Thomas R wrote: > 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. Thanks Tom! Has someone already verified these results with other implementations? /petri > Tom > > Internet-Draft Host Identity Protocol December 2003 > > Appendix F. Example checksums for HIP packets > > The HIP checksum for HIP packets is specified in Section 6.1.2. > Checksums for TCP and UDP packets running over HIP-enabled security > 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" > followed by 124 zeroes followed by a decimal 1 or 2, respectively. > > F.1. IPv6 HIP example (I1) > > 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 > Sender's HIT: 4000::0001 > Receiver's HIT: 4000::0002 > > F.2. IPv4 HIP packet (I1) > > 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 > pseudo-header components are the same). > > F.3. TCP segment > > Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets > use the IPv6 pseudo-header format [8], with the HITs used in place of > the IPv6 addresses. > > 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 > > > -- 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 lars.eggert@netlab.nec.de Fri Jan 9 10:41:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Fri Jan 9 10:41:01 2004 Subject: [Hipsec] hip for ns2? Message-ID: <3FFEC590.3060008@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms040201010701050209040007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, is anyone aware of a HIP implementation for ns2 (or any other simulator for that matter?) Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms040201010701050209040007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMTA5MTUxNTI4WjAjBgkqhkiG 9w0BCQQxFgQUPnuUZhOluG6jug1eAGjVhQBD6/UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA Q3YPGO6w/U5VrDnRJvxvITf4a7EjKN3dMCmSo3sbwlgiNUHdcsjMvXlSYd3zY3yOj/dsSYOA RbYstghf3Oa+yxevu2gnRZuLHud+G8yua7Wg0o+H0vDZpzrAknb2DieMGRdhPcWDqMFnPEgM 2wDiZGYgu3W2Od+uBBRoV/NtvlTVhg1JYyFkBr7iOUCVqML+a+ktGe3BKUS2Mibf4F0LGR3D vxlW0M3rTYNfVWzXUTfKJ4MGrXNek2sKlPyGBugNG4ze4J68DRKzuYghj3MjMuSpf+Mda0zZ 4OS9zk27ST7/3HHmlMjjTUhDrXYCW9cQ+5yygAYAMI9MFCvG9fH5DwAAAAAAAA== --------------ms040201010701050209040007-- From thomas.r.henderson@boeing.com Fri Jan 9 11:55:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Jan 9 11:55:01 2004 Subject: [Hipsec] hip for ns2? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B606F@xch-nw-27.nw.nos.boeing.com> Not that I know of. In general, the simulators that I am familiar with do not have existing models of things like=20 IPsec, DNS, or PKI. Tom > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: Friday, January 09, 2004 7:15 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] hip for ns2? >=20 >=20 > Hi, >=20 > is anyone aware of a HIP implementation for ns2 (or any other=20 > simulator=20 > for that matter?) >=20 > Thanks, > Lars > --=20 > Lars Eggert NEC Network=20 > Laboratories >=20 From pekka.nikander@nomadiclab.com Fri Jan 16 04:18:04 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Jan 16 04:18:04 2004 Subject: [Hipsec] A proposal for the HIP related research group Message-ID: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> In the discussions with the ADs during and after the Minneapolis meeting, it was decided that it would be good to charter both a fairly focused HIP WG and a longer term HIP related research group. The WG chartering is now being taken care by the ADs and the to-be chairs, David and Gonzalo, and is on the IESG telechat agenda next week. What comes to the RG, an initial proposal for the HIP related research group charter is now available at http://www.tml.hut.fi/~pnr/HIP/hip_rg_charter_proposal_040114.html Please send your comments to the list. While the IESG charters working groups, the process is different with IRTF research groups. Basically, the charter is discussed with the IRTF chair, Vern Paxon, and the IAB. Vern has already initiated some discussing with the IAB, but Tom and I haven't received any comments from them yet. My assumption is that the final RG charter will be based on this proposal, modified to take into account the comments from IAB and this list. --Pekka Nikander From miika@iki.fi Fri Jan 16 08:48:01 2004 From: miika@iki.fi (Miika Komu) Date: Fri Jan 16 08:48:01 2004 Subject: [Hipsec] A proposal for the HIP related research group Message-ID: On Fri, 16 Jan 2004, Pekka Nikander wrote: > In the discussions with the ADs during and after the Minneapolis > meeting, it was decided that it would be good to charter both > a fairly focused HIP WG and a longer term HIP related research > group. The WG chartering is now being taken care by the ADs and > the to-be chairs, David and Gonzalo, and is on the IESG telechat > agenda next week. > > What comes to the RG, an initial proposal for the HIP related > research group charter is now available at > > http://www.tml.hut.fi/~pnr/HIP/hip_rg_charter_proposal_040114.html > > Please send your comments to the list. RG proposal sounds good to me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From miika@iki.fi Fri Jan 16 11:39:02 2004 From: miika@iki.fi (Miika Komu) Date: Fri Jan 16 11:39:02 2004 Subject: [Hipsec] A proposal for the HIP related research group In-Reply-To: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> References: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> Message-ID: On Fri, 16 Jan 2004, Pekka Nikander wrote: > In the discussions with the ADs during and after the Minneapolis > meeting, it was decided that it would be good to charter both > a fairly focused HIP WG and a longer term HIP related research > group. The WG chartering is now being taken care by the ADs and > the to-be chairs, David and Gonzalo, and is on the IESG telechat > agenda next week. > > What comes to the RG, an initial proposal for the HIP related > research group charter is now available at > > http://www.tml.hut.fi/~pnr/HIP/hip_rg_charter_proposal_040114.html > > Please send your comments to the list. RG proposal sounds good to me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Gonzalo.Camarillo@ericsson.com Sat Jan 17 03:54:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sat Jan 17 03:54:00 2004 Subject: [Hipsec] A proposal for the HIP related research group In-Reply-To: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> References: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> Message-ID: <40090129.60608@ericsson.com> Pekka, I would not mention the policy of our mailing list in the charter, since it is something that might change very easily. If the level of SPAM raises over a certain level, for example, the mailing list might need to become a subscribers-only mailing list. I do not know how fast you can update RG charters, but if it is as slow as the process for updating WG charters in the IETF, you will be better off removing any information that can change so easily. The rest of the charter proposal looks good to me. Gonzalo Pekka Nikander wrote: > In the discussions with the ADs during and after the Minneapolis > meeting, it was decided that it would be good to charter both > a fairly focused HIP WG and a longer term HIP related research > group. The WG chartering is now being taken care by the ADs and > the to-be chairs, David and Gonzalo, and is on the IESG telechat > agenda next week. > > What comes to the RG, an initial proposal for the HIP related > research group charter is now available at > > http://www.tml.hut.fi/~pnr/HIP/hip_rg_charter_proposal_040114.html > > Please send your comments to the list. > > While the IESG charters working groups, the process is different > with IRTF research groups. Basically, the charter is discussed > with the IRTF chair, Vern Paxon, and the IAB. Vern has already > initiated some discussing with the IAB, but Tom and I haven't > received any comments from them yet. > > My assumption is that the final RG charter will be based on this > proposal, modified to take into account the comments from IAB > and this list. > > --Pekka Nikander > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From Spencer Dawkins" <40090129.60608@ericsson.com> Message-ID: <024b01c3df31$7ad273f0$0400a8c0@DFNJGL21> Gonzalo is exactly right. If you guys would spend about fifteen minutes looking at http://www.postel.org/pipermail/end2end-interest/2004-January/thread.html, you would close that list to non-member postings faster than you can type the commands. Please pay special attention to the monthly begging, onlist, that the list be closed to non-member posting, that has gone on for as long as I can remember. I unsubscribed about a month ago, because I was tired of more than half my spam arriving from end2end. I really believe Joe Touch is making every effort to make non-member posting work for end2end. But even if you work as hard as Joe does, and your subscribers all filter all the spam themselves, your archives will be unusable. Unless your research group members also want to enlarge body parts. Then, the archives would be pretty handy. IMHO. Spencer ----- Original Message ----- From: "Gonzalo Camarillo" To: "Pekka Nikander (JO/LMF)" Cc: ; "Thomas Henderson" ; "Vern Paxson" Sent: Saturday, January 17, 2004 3:32 AM Subject: Re: [Hipsec] A proposal for the HIP related research group > Pekka, > > I would not mention the policy of our mailing list in the charter, since > it is something that might change very easily. If the level of SPAM > raises over a certain level, for example, the mailing list might need to > become a subscribers-only mailing list. > > I do not know how fast you can update RG charters, but if it is as slow > as the process for updating WG charters in the IETF, you will be better > off removing any information that can change so easily. > > The rest of the charter proposal looks good to me. > > Gonzalo From pekka.nikander@nomadiclab.com Tue Jan 20 09:05:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Jan 20 09:05:01 2004 Subject: [Hipsec] A proposal for the HIP related research group In-Reply-To: <024b01c3df31$7ad273f0$0400a8c0@DFNJGL21> References: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> <40090129.60608@ericsson.com> <024b01c3df31$7ad273f0$0400a8c0@DFNJGL21> Message-ID: <2B37CD5E-4B57-11D8-BB20-000393CE1E8C@nomadiclab.com> I've now updated the RG charter proposal, removing the line about ML policy. The new proposal is available at http://www.tml.hut.fi/~pnr/HIP/hip_rg_charter_proposal_040120.html If there are no other comments from this list, we basically need a good acronym and name. I hereby open a competition for inventing a name for the RG. I'll buy a beer at Seoul to the person that proposes the name that I personally think is the best one. (Note, however, that the name that will be adopted may be different from the one that I will prefer :-)) --Pekka Nikander From kslavov@hiit.fi Wed Jan 21 09:08:01 2004 From: kslavov@hiit.fi (Kristian Slavov) Date: Wed Jan 21 09:08:01 2004 Subject: [Hipsec] A proposal for the HIP related research group In-Reply-To: <2B37CD5E-4B57-11D8-BB20-000393CE1E8C@nomadiclab.com> References: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> <40090129.60608@ericsson.com> <024b01c3df31$7ad273f0$0400a8c0@DFNJGL21> <2B37CD5E-4B57-11D8-BB20-000393CE1E8C@nomadiclab.com> Message-ID: <400E90FC.1060006@hiit.fi> Pekka Nikander wrote: > > If there are no other comments from this list, we basically > need a good acronym and name. No suggestions yet, so I'll start: SLIP - Separating Locators and Identities in Protocols > I hereby open a competition for inventing a name for the RG. > I'll buy a beer at Seoul to the person that proposes the name I wont be in Seoul, so in case I win, I think Miika will be more than happy to collect the prize :) -- Kristian Slavov Research Assistant Helsinki Institute for Information Technology Gsm: +358-40-7220960 From Julien.Laganier@Sun.COM Wed Jan 21 10:48:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Jan 21 10:48:01 2004 Subject: [Hipsec] A proposal for the HIP related research group In-Reply-To: <400E90FC.1060006@hiit.fi> References: <4B41EAB4-480A-11D8-86DC-000393CE1E8C@nomadiclab.com> <2B37CD5E-4B57-11D8-BB20-000393CE1E8C@nomadiclab.com> <400E90FC.1060006@hiit.fi> Message-ID: <200401211726.55122.julien.laganier@sun.com> On Wednesday 21 January 2004 15:47, Kristian Slavov wrote: > Pekka Nikander wrote: > > If there are no other comments from this list, we basically > > need a good acronym and name. > > No suggestions yet, so I'll start: > SLIP - Separating Locators and Identities in Protocols I like SLIP. BTW, permutting letters a bit: SPLIT - Separating Protocols Identifier and Locator Tags --julien From thomas.r.henderson@boeing.com Wed Jan 21 15:12:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jan 21 15:12:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> I have some questions regarding the mobility draft. Some=20 things have changed considerably since the time that REA was in the base spec, and I don't understand the motivation for many of=20 these changes, and am wondering whether they are necessary. Here are some fundamental questions: i) we used to have a REA that updated the (primary) destination address to use for the HIP SA. This did not cause rekeying or new SPI generation, nor did it require a return routability check. REA could be authenticated based on signature. We now seem to have drifted far from this basic approach. =20 Why does readdressing require return routability check (what is the attack?) and new SPI generation? Asked another way, what is it about a simple REA/REA-ACK=20 handshake, and modification of the preferred outbound IP address without otherwise changing the SA, that is undesirable?=20 ii) There is an additional level of abstraction introduced called=20 an "interface." This is a new architectural component-- IPsec SAs are now bound to interfaces rather than to hosts, and more than one SA may be active between hosts. This is a departure=20 from the premise adopted in the base specification that HIP=20 supports only one SA between hosts. For HIP to support more=20 than one SA between any two hosts requires some way to index=20 SAs within the context of the HIP association-- this is how I=20 view the logical "interface" concept introduced in this draft. =20 But I question whether it is necessary, and if it is, shouldn't=20 it be in the base spec and in the architecture doc? (also, the overloading of the term "interface" may cause confusion=20 because most people have rather concrete conceptions of what an interface is.) =20 iii) as for multihoming, the architecture is unclear. How does this play with SCTP dynamic address reconfiguration, which=20 looks similar to me (allows multiple addresses to be in use, for purposes of recovery via alternate path-- and in the future,=20 load balancing?-- and allows one address to be "primary"). =20 Are both needed? Should HIP mechanism replace transport level multi-address handling? Should more work on the SLAP concept be done? Note also that if congestion control=20 continues to live in the transport protocol above HIP, it is not appropriate to hide the presence of multiple possible source and destination addresses (multiple paths) from transport, so it is probably not appropriate to infer that transport level connections need not have any notion of underlying IP addresses anymore with HIP. =20 This also gets into the question of whether it is HIP's job to determine which of possible addresses should be primary. Maybe the approach, suggested by Marcelo in a previous post, towards specifying only a basic mechanism for mobility (change primary destination address to use for IPsec transport layer outer header) is the prudent approach for now, with more comprehensive multihoming (and perhaps mobility extensions) coming later. minor comments: - Sec 5-- insulated -> decoupled - end of section 5: "space specification" -> "base specification" - Section 5, I would say "without causing SA reestablishment" instead=20 of "without causing loss of connectivity." - Mention the double jump problem at the end of section 1 as an issue that this draft does not discuss? - Sending REA in R1 seems to lead to same issues we have been=20 discussing with respect to using R1 for HIP loss of state=20 From Julien.Laganier@Sun.COM Thu Jan 22 06:03:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Jan 22 06:03:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: <200401221236.33647.julien.laganier@sun.com> On Wednesday 21 January 2004 21:43, Henderson, Thomas R wrote: > I have some questions regarding the mobility draft. Some > things have changed considerably since the time that REA was in > the base spec, and I don't understand the motivation for many of > these changes, and am wondering whether they are necessary. > > Here are some fundamental questions: > > i) we used to have a REA that updated the (primary) destination > address to use for the HIP SA. This did not cause rekeying or > new SPI generation, nor did it require a return routability > check. REA could be authenticated based on signature. We now > seem to have drifted far from this basic approach. > > Why does readdressing require return routability check (what > is the attack?) and new SPI generation? RR check is required to avoid DoS on third parties (attacker asks a server to send huge stream of packets, then send REA to the server with the IP address of the attack's target). The new SPI generation is used as a cookie in the RR check, thus avoiding a new parameter. > Asked another way, what is it about a simple REA/REA-ACK > handshake, and modification of the preferred outbound IP address > without otherwise changing the SA, that is undesirable? Doing RR check with REA/REA-ACK seems to require another packet for carrying cookie: --> REA <-- REA-ACK|cookie --> REA-CONF|cookie > ii) There is an additional level of abstraction introduced called > an "interface." This is a new architectural component-- IPsec > SAs are now bound to interfaces rather than to hosts, and more > than one SA may be active between hosts. This is a departure > from the premise adopted in the base specification that HIP > supports only one SA between hosts. For HIP to support more > than one SA between any two hosts requires some way to index > SAs within the context of the HIP association-- this is how I > view the logical "interface" concept introduced in this draft. > But I question whether it is necessary, and if it is, shouldn't > it be in the base spec and in the architecture doc? My understanding is that per logical interface SAs abstract IPsec from the different characteristics of interfaces. Also it might be useful for ULPs doing flow control to be exposed to the concept of "interface", for instance when doing handover from one interface to another, flow control algorithms can be resetted. > (also, the overloading of the term "interface" may cause confusion > because most people have rather concrete conceptions of what an > interface is.) Why not call them "virtual interfaces" as their MIP and IPsec counterparts? > iii) as for multihoming, the architecture is unclear. How does > this play with SCTP dynamic address reconfiguration, which > looks similar to me (allows multiple addresses to be in use, > for purposes of recovery via alternate path-- and in the future, > load balancing?-- and allows one address to be "primary"). > > Are both needed? Should HIP mechanism replace transport > level multi-address handling? It seems to me that HIP implements sort of "network level" multi-adressing, so I guess it's redundant with transport level support, and both shouldn't be used simultaneously. > Should more work on the SLAP > concept be done? Note also that if congestion control > continues to live in the transport protocol above > HIP, it is not appropriate to hide the presence of multiple > possible source and destination addresses (multiple paths) > from transport, so it is probably not appropriate to infer > that transport level connections need not have any notion > of underlying IP addresses anymore with HIP. While the logical interfaces is exposed to ULPs, multiple src/dst can be hiden without preventing flow control if each logical interface is laid on "apparented" interfaces (by apparented, I want to denote similarity in bandwith, routing path, link quality, like two ethernet connected on the same router, or two GPRS with similar ISPs) > This also gets into the question of whether it is HIP's job > to determine which of possible addresses should be primary. It makes sense to me to factor this functionnality as down in the stack as possible. As it doesn't seems to be IP's job, I tend to think that it is HIP's one. Thanks, --julien From mbagnulo@ing.uc3m.es Thu Jan 22 06:21:01 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Thu Jan 22 06:21:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: Hi Thomas, > Here are some fundamental questions: I include my opinions about htis questions FWIW > > i) we used to have a REA that updated the (primary) destination > address to use for the HIP SA. This did not cause rekeying or > new SPI generation, nor did it require a return routability > check. REA could be authenticated based on signature. We now > seem to have drifted far from this basic approach. > > Why does readdressing require return routability check (what > is the attack?) As far as i understand, this is very important in order to prevent flooding attacks. The attack would be the following: attacker A streaming server S that generates very big load victim S A contacts S and ask for a heavy data flow S starts sending the load to A A then redirects the flow to V, he can do it becuase he can authenticate the request V is flooded with the stream In order to prevent this, you need to verify that address V really belongs to A, which in this case is not true, you can address this by doin a RR check For a much better explanation about this attack, please check draft-nikander-mobileip-v6-ro-sec-02.txt > and new SPI generation? > > Asked another way, what is it about a simple REA/REA-ACK > handshake, and modification of the preferred outbound IP address > without otherwise changing the SA, that is undesirable? > > ii) There is an additional level of abstraction introduced called > an "interface." This is a new architectural component-- IPsec > SAs are now bound to interfaces rather than to hosts, and more > than one SA may be active between hosts. This is a departure > from the premise adopted in the base specification that HIP > supports only one SA between hosts. For HIP to support more > than one SA between any two hosts requires some way to index > SAs within the context of the HIP association-- this is how I > view the logical "interface" concept introduced in this draft. > But I question whether it is necessary, and if it is, shouldn't > it be in the base spec and in the architecture doc? > > (also, the overloading of the term "interface" may cause confusion > because most people have rather concrete conceptions of what an > interface is.) > I really don't have an opinion about the term interface, but i think that a introcuding a way to group multiple addresses and not all of them as in a node it would be useful. I think there are possible scenarios where you want that a certain communication can use a set of addresses but not all the addresses available in the host. This may be because using different addresses may have different properties. For instance, if you consider a multihomed site, that obtains addresses from each of its providers, and you also assume that some ingress filtering is in place, using a certain address implies selecting a certain provider. So you have 3 addresses and 3 providers. Perhaps you want to use only two of these isps (that is only two of these addresses) for a certain type of communications. As i understand what is being proposed, you could just play with the interface concept and only allow such communications to use a certain interface that groups only those selected addresses. But perhaps i am misunderstanding something here.... > iii) as for multihoming, the architecture is unclear. How does > this play with SCTP dynamic address reconfiguration, which > looks similar to me (allows multiple addresses to be in use, > for purposes of recovery via alternate path-- and in the future, > load balancing?-- and allows one address to be "primary"). > > Are both needed? Should HIP mechanism replace transport > level multi-address handling? Should more work on the SLAP > concept be done? Note also that if congestion control > continues to live in the transport protocol above > HIP, it is not appropriate to hide the presence of multiple > possible source and destination addresses (multiple paths) > from transport, so it is probably not appropriate to infer > that transport level connections need not have any notion > of underlying IP addresses anymore with HIP. Very good questions. My view is that those different mechanism complement each other. LEt me ask you a question from a different perspective, what happens with regular TCP communications, or with UDP communications? Enabling multihoming and mobility mechanisms at the HIP layer enables these single address tranpsort layer to benefit from multiaddresssing. So fully agree with you, if the transport layer is aware of the multiple addresses and knows how to handle them, so let him do it. But if the transport layer don't know how to deal with this, handling multiple addresses at the HIP layer IMHO clearly provides a benefit. agree? > > This also gets into the question of whether it is HIP's job > to determine which of possible addresses should be primary. > > Maybe the approach, suggested by Marcelo in a previous post, > towards specifying only a basic mechanism for mobility (change > primary destination address to use for IPsec transport > layer outer header) is the prudent approach for now, with > more comprehensive multihoming (and perhaps mobility > extensions) coming later. > I think tha defining extensions to add and remove addresses are important for multiple problems, such as mobility and multihoming. Those extensions are common to all these problems, so that what i think that they should be defined in a separate doc independeltlly of multihoming or mobility. This is also becasue only this extension don't really address these problems completelly, they are just a part of the solution. Then separate docs addressing the mobility and the multihoming problems would be required, (i think the Pekka is working on them, especially the multihoming draft) regards, marcelo > minor comments: > > - Sec 5-- insulated -> decoupled > > - end of section 5: "space specification" -> "base specification" > > - Section 5, I would say "without causing SA reestablishment" instead > of "without causing loss of connectivity." > > - Mention the double jump problem at the end of section 1 as an > issue that this draft does not discuss? > > - Sending REA in R1 seems to lead to same issues we have been > discussing with respect to using R1 for HIP loss of state > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From mbagnulo@ing.uc3m.es Thu Jan 22 07:30:01 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Thu Jan 22 07:30:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: Hi Thomas, > Here are some fundamental questions: I include my opinions about htis questions FWIW > > i) we used to have a REA that updated the (primary) destination > address to use for the HIP SA. This did not cause rekeying or > new SPI generation, nor did it require a return routability > check. REA could be authenticated based on signature. We now > seem to have drifted far from this basic approach. > > Why does readdressing require return routability check (what > is the attack?) As far as i understand, this is very important in order to prevent flooding attacks. The attack would be the following: attacker A streaming server S that generates very big load victim S A contacts S and ask for a heavy data flow S starts sending the load to A A then redirects the flow to V, he can do it becuase he can authenticate the request V is flooded with the stream In order to prevent this, you need to verify that address V really belongs to A, which in this case is not true, you can address this by doin a RR check For a much better explanation about this attack, please check draft-nikander-mobileip-v6-ro-sec-02.txt > and new SPI generation? > > Asked another way, what is it about a simple REA/REA-ACK > handshake, and modification of the preferred outbound IP address > without otherwise changing the SA, that is undesirable? > > ii) There is an additional level of abstraction introduced called > an "interface." This is a new architectural component-- IPsec > SAs are now bound to interfaces rather than to hosts, and more > than one SA may be active between hosts. This is a departure > from the premise adopted in the base specification that HIP > supports only one SA between hosts. For HIP to support more > than one SA between any two hosts requires some way to index > SAs within the context of the HIP association-- this is how I > view the logical "interface" concept introduced in this draft. > But I question whether it is necessary, and if it is, shouldn't > it be in the base spec and in the architecture doc? > > (also, the overloading of the term "interface" may cause confusion > because most people have rather concrete conceptions of what an > interface is.) > I really don't have an opinion about the term interface, but i think that a introcuding a way to group multiple addresses and not all of them as in a node it would be useful. I think there are possible scenarios where you want that a certain communication can use a set of addresses but not all the addresses available in the host. This may be because using different addresses may have different properties. For instance, if you consider a multihomed site, that obtains addresses from each of its providers, and you also assume that some ingress filtering is in place, using a certain address implies selecting a certain provider. So you have 3 addresses and 3 providers. Perhaps you want to use only two of these isps (that is only two of these addresses) for a certain type of communications. As i understand what is being proposed, you could just play with the interface concept and only allow such communications to use a certain interface that groups only those selected addresses. But perhaps i am misunderstanding something here.... > iii) as for multihoming, the architecture is unclear. How does > this play with SCTP dynamic address reconfiguration, which > looks similar to me (allows multiple addresses to be in use, > for purposes of recovery via alternate path-- and in the future, > load balancing?-- and allows one address to be "primary"). > > Are both needed? Should HIP mechanism replace transport > level multi-address handling? Should more work on the SLAP > concept be done? Note also that if congestion control > continues to live in the transport protocol above > HIP, it is not appropriate to hide the presence of multiple > possible source and destination addresses (multiple paths) > from transport, so it is probably not appropriate to infer > that transport level connections need not have any notion > of underlying IP addresses anymore with HIP. Very good questions. My view is that those different mechanism complement each other. LEt me ask you a question from a different perspective, what happens with regular TCP communications, or with UDP communications? Enabling multihoming and mobility mechanisms at the HIP layer enables these single address tranpsort layer to benefit from multiaddresssing. So fully agree with you, if the transport layer is aware of the multiple addresses and knows how to handle them, so let him do it. But if the transport layer don't know how to deal with this, handling multiple addresses at the HIP layer IMHO clearly provides a benefit. agree? > > This also gets into the question of whether it is HIP's job > to determine which of possible addresses should be primary. > > Maybe the approach, suggested by Marcelo in a previous post, > towards specifying only a basic mechanism for mobility (change > primary destination address to use for IPsec transport > layer outer header) is the prudent approach for now, with > more comprehensive multihoming (and perhaps mobility > extensions) coming later. > I think tha defining extensions to add and remove addresses are important for multiple problems, such as mobility and multihoming. Those extensions are common to all these problems, so that what i think that they should be defined in a separate doc independeltlly of multihoming or mobility. This is also becasue only this extension don't really address these problems completelly, they are just a part of the solution. Then separate docs addressing the mobility and the multihoming problems would be required, (i think the Pekka is working on them, especially the multihoming draft) regards, marcelo > minor comments: > > - Sec 5-- insulated -> decoupled > > - end of section 5: "space specification" -> "base specification" > > - Section 5, I would say "without causing SA reestablishment" instead > of "without causing loss of connectivity." > > - Mention the double jump problem at the end of section 1 as an > issue that this draft does not discuss? > > - Sending REA in R1 seems to lead to same issues we have been > discussing with respect to using R1 for HIP loss of state > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From thomas.r.henderson@boeing.com Thu Jan 22 15:29:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Jan 22 15:29:00 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC243@xch-nw-27.nw.nos.boeing.com> replying both to Marcelo and Julian, who had similar responses (marcelo's comments inline) > > > > Why does readdressing require return routability check (what is the=20 > > attack?) >=20 > As far as i understand, this is very important in order to=20 > prevent flooding attacks. OK, I see this now, but there are scenarios for which the two hosts trust each other (e.g., non-anonymous mode) so it would be preferable=20 in my view to make RR an option for the host receiving a REA. I=20 would like to keep a lightweight readdress option--=20 so could we have two possible modes? REA -> <- REA-ACK=20 REA -> <- REA-ACK (cookie) REA-CONF (cookie) -> =20 NES is an option for either of the above exchanges. This puts control in the responder's hands as to whether the REA initiator is trusted enough to readdress without cookie challenge, and it leaves control in the REA initiator's hands as to whether it wants to rekey the SA. > > ii) There is an additional level of abstraction introduced=20 > called an=20 > > "interface." =20 > > >=20 > I really don't have an opinion about the term interface, but=20 > i think that a introcuding a way to group multiple addresses=20 > and not all of them as in a node it would be useful. I think=20 > there are possible scenarios where you want that a certain=20 > communication can use a set of addresses but not all the=20 > addresses available in the host. This may be because using=20 > different addresses may have different properties. >=20 > For instance, if you consider a multihomed site, that obtains=20 > addresses from each of its providers, and you also assume=20 > that some ingress filtering is in place, using a certain=20 > address implies selecting a certain provider. So you have 3=20 > addresses and 3 providers. Perhaps you want to use only two=20 > of these isps (that is only two of these > addresses) for a certain type of communications. > As i understand what is being proposed, you could just play=20 > with the interface concept and only allow such communications=20 > to use a certain interface that groups only those selected=20 > addresses. But perhaps i am misunderstanding something here.... I am not so much questioning whether it may be useful to have multiple SAs (with possibly different address bindings) between=20 hosts; rather,=20 i) whether the interface construct is explicitly needed,=20 as opposed to just using the SPI instead ii) should the concept be introduced here rather than in the base=20 spec or architecture. e.g., what is the Interface ID of the SA set=20 up during base exchange? (I previously had some questions about how to handle multiple SAs between hosts and how it might impact the base exchange-- e.g.=20 Note 3 in the below message): http://honor.trusecure.com/pipermail/hipsec/2003-September/000029.html If we just say that we can have multiple SAs tied to a HIP association, each SA indexed by SPI and with perhaps distinct address sets, what do we lose from not having the interface concept? =20 Is the logical concept of interfaces more of an implementation issue? (that is, an internal housekeeping issue?) I'm not seeing why I couldn't get similar policy granularity with existing mechanisms. >=20 > > iii) as for multihoming, the architecture is unclear. How=20 > does this=20 > > play with SCTP dynamic address reconfiguration, which looks=20 > similar to=20 > > me (allows multiple addresses to be in use, for purposes of=20 > recovery=20 > > via alternate path-- and in the future, load balancing?--=20 > and allows=20 > > one address to be "primary"). > > > > Are both needed? Should HIP mechanism replace transport level=20 > > multi-address handling? Should more work on the SLAP=20 > concept be done? =20 > > Note also that if congestion control continues to live in the=20 > > transport protocol above HIP, it is not appropriate to hide the=20 > > presence of multiple possible source and destination addresses=20 > > (multiple paths) from transport, so it is probably not=20 > appropriate to=20 > > infer that transport level connections need not have any notion > > of underlying IP addresses anymore with HIP. >=20 > Very good questions. >=20 > My view is that those different mechanism complement each other. >=20 > LEt me ask you a question from a different perspective, what=20 > happens with regular TCP communications, or with UDP communications? >=20 well, of course, TCP cannot presently multihome. If you read the dynamic SCTP addressing draft, it looks a lot like HIP readdressing might. However, SCTP as presently specified only does retransmission across alternate paths. The general host multihoming problem has=20 not been thoroughly handled yet IMO. > Enabling multihoming and mobility mechanisms at the HIP layer=20 > enables these single address tranpsort layer to benefit from=20 > multiaddresssing. >=20 > So fully agree with you, if the transport layer is aware of=20 > the multiple addresses and knows how to handle them, so let him do it. >=20 > But if the transport layer don't know how to deal with this,=20 > handling multiple addresses at the HIP layer IMHO clearly=20 > provides a benefit. >=20 > agree? >=20 Yes, but I am thinking that maybe some kind of address change trigger might be needed to the transport layer to indicate that there may have been a path change. I think that HIP should handle multihoming-- I just don't think it is clear yet how it will do so and how it will interact with transport. And some of these questions touch on=20 mechanisms outside the scope of HIP. For example, there is no=20 RFC guidance on what to do with congestion control state if a=20 host changes its source address used on an active transport=20 data flow. > > > > This also gets into the question of whether it is HIP's job to=20 > > determine which of possible addresses should be primary. > > > > Maybe the approach, suggested by Marcelo in a previous=20 > post, towards=20 > > specifying only a basic mechanism for mobility (change primary=20 > > destination address to use for IPsec transport layer outer=20 > header) is=20 > > the prudent approach for now, with more comprehensive=20 > multihoming (and=20 > > perhaps mobility > > extensions) coming later. > > >=20 > I think tha defining extensions to add and remove addresses=20 > are important for multiple problems, such as mobility and=20 > multihoming. Those extensions are common to all these=20 > problems, so that what i think that they should be defined in=20 > a separate doc independeltlly of multihoming or mobility.=20 > This is also becasue only this extension don't really address=20 > these problems completelly, they are just a part of the solution. That was my impression after reading mm-01. Maybe we can fix these things or maybe we need additional drafts. =20 Tom From petri.jokela@nomadiclab.com Fri Jan 23 05:29:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Jan 23 05:29:00 2004 Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 Message-ID: <401100C2.9090307@nomadiclab.com> I have been updating the draft-hip-09-pre1. Changes that are (almost) done: o NES is changed to UPD o NES_INFO parameter changed to NES o State names have been changed o In case of node reboot, incoming unknown ESP packet triggers an I1 packet sending with RESYNC bit set. I include new versions of 5.3 and 5.4 here. The state machine is from Julien's earlier post (not directly copied, it may contain typos...) The HIP basic header will contain a RESYNC -bit. /petri 5.3 Reboot and SA timeout restart of HIP Simulating a loss of state is a potential DoS attack. The following process has been crafted to manage state recovery without presenting a DoS opportunity. If a host reboots or times out, it has lost its HIP state. If the system that lost state has a datagram to deliver to its peer, it simply restarts the HIP exchange. The peer sends an R1 HIP packet, but does not reset its state until it receives the I2 HIP packet. The I2 packet MUST have a Birthday greater than the current SA's Birthday. This is to handle DoS attacks that simulate a reboot of a peer. Note that either the original Initiator or the Responder could end up restarting the exchange, becoming the new Initiator. If a system receives an ESP packet for an unknown SPI, it is possible that it has lost the state and its peer has not. In this case, the system initiates a new HIP exchange for re-establishing the SA. The RESYNC bit in the I1 packet is set to indicate the peer about the possible state loss. The initiating host cannot know, if the SA indicated by the received ESP packet is either a HIP SA or and IKE SA. If the old SA was not a HIP SA, the peer may not respond to the I1 packet. After sending the I1, the HIP negotiaton proceeds as normally and, when successful, the SA is created at the initiating end. The peer end removes the OLD SA and replaces it with the new one. 5.4 HIP State Machine The HIP protocol itself has very little state. In the HIP base exchange, there is an Initiator and a Responder. Once the SAs are established, this distinction is lost. If the HIP state needs to be re-established, the controlling parameters are which peer still has state and which has a datagram to send to its peer. The following state machine attempts to capture these processes. The state machine is presented in a single system view, representing either an Initiator or a Responder. There is not a complete overlap of processing logic here and in the packet definitions. Both are needed to completely implement HIP. Implementors must understand that the state machine, as described here, is informational. Specific implementations are free to implement the actual functions differently. 5.4.1 HIP States UNASSOCIATED State machine start I1-SENT Initiating HIP I2-SENT Waiting to finish HIP ESTABLISHED HIP SA established REKEYING HIP SA established, rekeying RESYNC Peer lost state, resyncing E-FAILED HIP SA establishment failed 5.4.2 HIP State Processes +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to ESTABLISHED if fail, stay at UNASSOCIATED Receive ESP for unknown SA, send I1 and go to I1-SENT Receive ANYOTHER, drop and stay at UNASSOCIATED +---------+ | I1-SENT | Initiating HIP +---------+ Receive I1, send R1 and stay at I1-SENT Receive I2, process if successful, send R2 and go to ESTABLISHED if fail, stay at I1-SENT Receive R1, process if successful, send I2 and go to I2-SENT if fail, go to E-FAILED Receive ANYOTHER, drop and stay at I1-SENT Timeout, increment timeout counter If counter is less than I1_RETRIES_MAX, send I1 and stay at I1-SENT If counter is greater than I1_RETRIES_MAX, go to E-FAILED +---------+ | I2-SENT | Waiting to finish HIP +---------+ Receive I1, send R1 and stay at I2-SENT Receive I2, process if successful, send R2 and go to ESTABLISHED if fail, stay at I2-SENT Receive R2, process if successful, go to ESTABLISHED if fail, go to E-FAILED Receive ANYOTHER, drop and stay at I2-SENT Timeout, increment timeout counter If counter is less than I2_RETRIES_MAX, send I2 and stay at I2-SENT If counter is greater than I2_RETRIES_MAX, go to E-FAILED +------------+ |ESTEBALISHED| HIP SA established +------------+ Receive I1, send R1 and stay at go to RESYNC Receive I2, process with Birthday check if successful, send R2, drop old SA and cycle at ESTABLISHED if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPD, process if successful, send UPD and stay at ESTABLISHED if failed, stay at ESTABLISHED Need rekey, send UPD and go to REKEYING +----------+ | REKEYING | HIP SA established, rekey pending +----------+ Receive I1, send R1 and stay at REKEYING Receive I2, process with Birthday check if successful, send R2, drop old SA and go to ESTABLISHED if fail, stay at REKEYING Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and go to ESTABLISHED if fail, stay at REKEYING Receive R2, drop and stay at REKEYING Receive ESP for SA, process and stay at REKEYING Receive UPD, process if successful, replace SAs and go to ESTABLISHED if failed, stay at REKEYING Timeout, increment timeout counter If counter is less than UPD_RETRIES_MAX, send UPD and stay at REKEYING If counter is greater than UPD_RETRIES_MAX, go to E-FAILED +--------+ | RESYNC | HIP SA established, resync pending +--------+ Receive I1, send R1 and cycle at RESYNC Receive I2, process with Birthday check if successful, send R2, drop old SA and go to ESTABLISHED if fail, stay at RESYNC Receive R1, process with SA and Birthday check if successful, send I2, prepare to drop old SA and cycle at RESYNC if fail, stay at RESYNC Receive R2, process with SA and Birthday check if successful, go to ESTABLISHED if fail, stay at RESYNC Receive ESP for SA, process and go to ESTABLISHED Receive UPD, process if successful, send UPD and go to ESTABLISHED if failed, stay at RESYNC Timeout, increment timeout counter if counter is less than RESYNC_RETRIES_MAX, send I2 and stay at RESYNC if counter is greater than RESYNC_RETRIES_MAX, go to ESTABLISHED 5.4.3 Simplified HIP State Diagram Receive packets cause a move to a new state. +------------+ |UNASSOCIATED|>---+ +------------+ | | ^ | | | | | Dgm to | +-+ | send | I1 | ESP- | (note: ESP- means ESP with unknown SPI) | | v | +---------+ | | I1-SENT |>---|----------+ +---------+ | | | | | | R1 | | | |I2 |I2 v | | +---------+ | | | I2-SENT |>---|----------|-----+ | | | | | +---------+ | | | | | | | | R2 | | |I2 | | | | v | | | +-----------+<-+ | | | | | | |ESTABLISHED|<------------+ | | |<------------------+ | |<------------------+ | |>------------+ | | |<-----+ | | | |--+ | | | +-----------+ | | | | | ^ ^ | | | | | | | | | | | +--+ | | | | | ESP, | rekey| |R1,I2 | | UPD, | | | | | I1, |UPD | | | | I2, | | | | | R1 | | | | | | | | | | +---------+ | | | | | |<---+ | | | |REKEYING |>-------+ | | +---------+ | | | ^ v | | I2, R2, ESP | | | R1 | | UPD, Timeout +--+ | | | ESP, | | | I1, | | | | v ^ | R1 +--------+ +--------------->| RESYNC | +--------+ | ^ | | +--+ I1, R1 -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From petri.jokela@nomadiclab.com Fri Jan 23 05:36:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Jan 23 05:36:01 2004 Subject: [Hipsec] ESP_TRANSFORM (64-bit sequence number) Message-ID: <40110283.7070601@nomadiclab.com> The need for 64-bit sequence numbers was indicated with the E-bit in the HIP header. As discussed earlier on the HIPSEC list, this bit is now removed from the header and moved to the ESP_TRANSFORM parameter. /petri The new version of the ESP_TRANSFORM parameter: 6.2.7 ESP_TRANSFORM 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Reserved | Suite-ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite-ID #2 | Suite-ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite-ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 19 Length length in octets, excluding Type, Length, and padding E One if the ESP transform requires 64-bit sequence numbers Reserved zero when sent, ignored when received Suite-ID defines the ESP Suite to be used The following Suite-IDs are defined ([16],[19]): Suite-ID Value RESERVED 0 ESP-AES-CBC with HMAC-SHA1 1 ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-MD5 3 ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-MD5 6 There MUST NOT be more than six (6) ESP Suite-IDs in one ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least one of the mandatory Suite-IDs. Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL with HMAC-SHA1. -- 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 miika@iki.fi Fri Jan 23 09:58:00 2004 From: miika@iki.fi (Miika Komu) Date: Fri Jan 23 09:58:00 2004 Subject: [Hipsec] DH keymaterial regeneration during base exchange Message-ID: Kristian and me noted an implementation (?) problem that occurs when DH keymaterial is regenerated during a base exchange. The use case is listed below in sequential order. We assume that there is only one DH-key on the host (per group) in the use case, but the problem probably occurs also when there are multiple DH-keys on the host. Please see the boundary conditions after the use case before answering. 1 initiator sends an I1 to responder and goes to I1-SENT 2 responder receives the I1 and sends an R1 with DIFFIE_HELLMAN=DHa and stays in state UNASSOCIATED 3 responder decides to regenerate new Diffie-Hellman keymaterial DHb that overwrites the old DHa completely 4 initiator receives the R1 5 initiator sends an I2 using DHa keymaterial and goes to I2-sent 6 responder receives the I2 in UNASSOCIATED state with an invalid ENCRYPTED param (DHa was used to produce it, not DHb), drops it and stays in UNASSOCIATED state 7 initiator timeouts in I2-sent, resends the I2 using DHa keymaterial 8 responder drops the I2 again (because DHa was used instead of DHb), initiator resends, ... 9 initiator reaches I2_RETRIES_MAX and goes to E-FAILED Some boundary conditions to keep in mind: - The responder has a state only after it has received a sound I2. - Just having multiple DH-keys does not really solve the problem. - Consider when you can deallocate a specific DH-key. - Counter/lock solution: don't deallocate the DH-key until use count is zero. What if the initiator never responds? - DH-keys are tied to the pregenerated R1s. Solution 1: Cache the DHa until it expires. - If DHb did not do the trick on the responder, fall back to using the cached DHa if DHa has not expired (and deallocated). - The probability of fall backing to the cached DHa is quite minimal, so it is difficult to use for DoS. Solution 2: modify the state machine - In UNASSOCIATED, the responder receives an I2 and encryption fails. Resend R1 (with DHb) and don't change state. - In I2_SENT, the initiator receives R1, processes it, resends I2 and stays in I2_SENT. These were just some coarse grained ideas, we haven't had time to think about this in more depth yet. Has anyone solved this problem already? Any ideas? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mbagnulo@ing.uc3m.es Fri Jan 23 10:22:00 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Fri Jan 23 10:22:00 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC243@xch-nw-27.nw.nos.boeing.com> Message-ID: > OK, I see this now, but there are scenarios for which the two hosts > trust each other (e.g., non-anonymous mode) so it would be preferable > in my view to make RR an option for the host receiving a REA. I > would like to keep a lightweight readdress option-- > so could we have two possible modes? > > REA -> > <- REA-ACK > > REA -> > <- REA-ACK (cookie) > REA-CONF (cookie) -> > > NES is an option for either of the above exchanges. This puts > control in the responder's hands as to whether the REA initiator > is trusted enough to readdress without cookie challenge, and it > leaves control in the REA initiator's hands as to whether it > wants to rekey the SA. Well, the point here is who is the victim, i guess. You have A and B that trust each other, so you suggest that they could just skip the RR procedure for additional addresses. So A asks B to start sending its traffic to address C. Now, neither A nor B is damaged here but C is the one who is attacked I mean, if A trusts B it can take some risks that concern him and himself only. However, not performing RR endanger other parts like C so it is not up to A to decide this, IMHO it is up to the protocol designer to make sure that this doesn't happen But my criteria may be wrong here.... [...] > Yes, but I am thinking that maybe some kind of address change > trigger might be needed to the transport layer to indicate that > there may have been a path change. > yes! > I think that HIP should handle multihoming-- I just don't think > it is clear yet how it will do so and how it will interact > with transport. Yes > And some of these questions touch on mechanisms outside the scope of HIP. Yes Agree with you completelly. as you see,we have lots of work to do But imho an incremental approach is good. We clearly need a mechanism to add more addresses, so we need this draft. Then we will need more stuff indeed Regards, marcelo > For example, there is no > RFC guidance on what to do with congestion control state if a > host changes its source address used on an active transport > data flow. > > > > > > > This also gets into the question of whether it is HIP's job to > > > determine which of possible addresses should be primary. > > > > > > Maybe the approach, suggested by Marcelo in a previous > > post, towards > > > specifying only a basic mechanism for mobility (change primary > > > destination address to use for IPsec transport layer outer > > header) is > > > the prudent approach for now, with more comprehensive > > multihoming (and > > > perhaps mobility > > > extensions) coming later. > > > > > > > I think tha defining extensions to add and remove addresses > > are important for multiple problems, such as mobility and > > multihoming. Those extensions are common to all these > > problems, so that what i think that they should be defined in > > a separate doc independeltlly of multihoming or mobility. > > This is also becasue only this extension don't really address > > these problems completelly, they are just a part of the solution. > > That was my impression after reading mm-01. Maybe we can fix > these things or maybe we need additional drafts. > > Tom > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From jrh@it.uc3m.es Fri Jan 23 11:41:01 2004 From: jrh@it.uc3m.es (Juan Rodriguez Hervella) Date: Fri Jan 23 11:41:01 2004 Subject: [Hipsec] Question about how to test the HIP implementation in FreeBSD-5.1 Message-ID: <200401231820.26296.jrh@it.uc3m.es> (Sorry if you received multiple copies of this mail) Hello, I've followed the README guide to set up the HIP protocol, but I don't know how to test it.=20 =46rom the README: "After the script has completed a key pair has been generated to /etc/hip. = The files have been named according to HITs. Now one should add this HIT to the network interface using ifconfig e.g. ifconfig xl0 inet6 7a18:361c:e42b:e4d3:e847:19c8:d432:3c62 prefixlen 2 alia= s" Question: why do you need to assign the HIT to a specific interface ? If I understand it correctly, HITs are global identifiers, so all the possi= ble HITs should belong to all possible interfaces.... =BFis it possible to assi= gn the same HIT to more than one interface ?=20 "Now just use applications as normally you would and if the peer's host name resolves to a HIT-IP-pair then a HIP negotiation will be triggered by the IPSec policy." How can I make this resolution happen ? Would you mind explaining this with a little more precision ? An example would be great (^--^) Thanks! =2D-=20 ****** JFRH ****** Law of Probable Dispersal: Whatever it is that hits the fan will not be evenly distributed. From thomas.r.henderson@boeing.com Fri Jan 23 12:24:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Jan 23 12:24:00 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC249@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es]=20 > Sent: Friday, January 23, 2004 7:54 AM > To: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: RE: [Hipsec] Re: draft-nikander-hip-mm-01.txt >=20 >=20 > > OK, I see this now, but there are scenarios for which the two hosts > > trust each other (e.g., non-anonymous mode) so it would be=20 > preferable > > in my view to make RR an option for the host receiving a REA. I > > would like to keep a lightweight readdress option-- > > so could we have two possible modes? > > > > REA -> > > <- REA-ACK > > > > REA -> > > <- REA-ACK (cookie) > > REA-CONF (cookie) -> > > > > NES is an option for either of the above exchanges. This puts > > control in the responder's hands as to whether the REA initiator > > is trusted enough to readdress without cookie challenge, and it > > leaves control in the REA initiator's hands as to whether it > > wants to rekey the SA. >=20 > Well, the point here is who is the victim, i guess. >=20 > You have A and B that trust each other, so you suggest that=20 > they could just > skip the RR procedure for additional addresses. >=20 > So A asks B to start sending its traffic to address C. >=20 > Now, neither A nor B is damaged here but C is the one who is attacked >=20 > I mean, if A trusts B it can take some risks that concern him=20 > and himself > only. >=20 > However, not performing RR endanger other parts like C so it=20 > is not up to A > to decide this, IMHO it is up to the protocol designer to=20 > make sure that > this doesn't happen >=20 > But my criteria may be wrong here.... >=20 A doesn't get to decide-- B does. B makes a decision that it trusts A enough to not lie about moving to a given address. =20 This is really a policy issue, not a protocol issue. I would instead argue that it is up to the protocol designer to avoid unnecessarily constraining the possible operation of the protocol when there is no technical basis for the restriction, and leave the policy decision to the operator. Tom=20 From jfrherve@ing.uc3m.es Fri Jan 23 12:43:01 2004 From: jfrherve@ing.uc3m.es (Juan Rodriguez Hervella) Date: Fri Jan 23 12:43:01 2004 Subject: [Hipsec] Question about how to test the HIP implementation in FreeBSD-5.1 Message-ID: <200401231654.52673.jfrherve@ing.uc3m.es> Hello, I've followed the README guide to set up the HIP protocol, but I don't know how to test it.=20 =46rom the README: "After the script has completed a key pair has been generated to /etc/hip. = The files have been named according to HITs. Now one should add this HIT to the network interface using ifconfig e.g. ifconfig xl0 inet6 7a18:361c:e42b:e4d3:e847:19c8:d432:3c62 prefixlen 2 alia= s" Question: why do you need to assign the HIT to a specific interface ? If I understand it correctly, HITs are global identifiers, so all the possi= ble HITs should belong to all possible interfaces.... =BFis it possible to assi= gn the same HIT to more than one interface ?=20 "Now just use applications as normally you would and if the peer's host name resolves to a HIT-IP-pair then a HIP negotiation will be triggered by the IPSec policy." How can I make this resolution happen ? Would you mind explaining this with a little more precision ? An example would be great (^--^) Thanks! From pekka.nikander@nomadiclab.com Fri Jan 23 12:50:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Jan 23 12:50:00 2004 Subject: [Hipsec] Question about how to test the HIP implementation in FreeBSD-5.1 In-Reply-To: <200401231820.26296.jrh@it.uc3m.es> References: <200401231820.26296.jrh@it.uc3m.es> Message-ID: <1AAD8741-4DD2-11D8-B286-000393CE1E8C@nomadiclab.com> Hi Juan, > I've followed the README guide to set up the HIP protocol, but > I don't know how to test it. I'm not sure which implementation you are speaking about, but assuming that it is ours (the FreeBSD one), some replies. > =46rom the README: > > "After the script has completed a key pair has been generated to=20 > /etc/hip. The > files have been named according to HITs. Now one should add this HIT=20= > to the > network interface using ifconfig e.g. > ifconfig xl0 inet6 7a18:361c:e42b:e4d3:e847:19c8:d432:3c62 prefixlen 2=20= > alias" > > Question: why do you need to assign the HIT to a specific interface ? Currently the FreeBSD implementation requires that the HITs are routed out from the machine through some interface. That allows packets with HITs in them to be passed normally up to IPsec, which will then intercept them. This is basically an implementation hack, and will probably disappear at some point of time. > If I understand it correctly, HITs are global identifiers, so all the=20= > possible > HITs should belong to all possible interfaces.... =BFis it possible to=20= > assign > the same HIT to more than one interface ? It doesn't matter which interface you assign the HIT to, as long as it is a network interface. (Well, maybe loopback works, too, but at least I haven't tested that.) Hence, it is still global even though it looks like an interface specific thing due to the implementation hack. > "Now just use applications as normally you would and if the peer's=20 > host name > resolves to a HIT-IP-pair then a HIP negotiation will be triggered by=20= > the > IPSec policy." > > How can I make this resolution happen ? Would you mind explaining this > with a little more precision ? An example would be great (^--^) The easiest way is to add peer HITs to /etc/hosts on each machine. Just like they were IPv6 addresses. --Pekka Nikander From pekka.nikander@nomadiclab.com Fri Jan 23 12:55:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Jan 23 12:55:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC249@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC249@xch-nw-27.nw.nos.boeing.com> Message-ID: Tom, [Sorry about delay in answering.] >>> OK, I see this now, but there are scenarios for which the two hosts >>> trust each other (e.g., non-anonymous mode) so it would be preferable >>> in my view to make RR an option for the host receiving a REA. Tom, yes you are right. We have discussed this through already before, but I forgot. I will add this back to the next version of the draft. Sorry about forgetting about this. [I'll answer to the rest of your first message separately.] >>> I would like to keep a lightweight readdress option-- >>> so could we have two possible modes? >>> >>> REA -> >>> <- REA-ACK >>> >>> REA -> >>> <- REA-ACK (cookie) >>> REA-CONF (cookie) -> Yes, definitely. Mea culpa. > A doesn't get to decide-- B does. B makes a decision that it > trusts A enough to not lie about moving to a given address. Right. > This is really a policy issue, not a protocol issue. I would > instead argue that it is up to the protocol designer to avoid > unnecessarily constraining the possible operation of the protocol > when there is no technical basis for the restriction, and leave > the policy decision to the operator. Yes. Again, I am sorry about forgetting this and dropping this from the -01 version of the draft. --Pekka Nikander From jrh@it.uc3m.es Fri Jan 23 13:38:00 2004 From: jrh@it.uc3m.es (Juan Rodriguez Hervella) Date: Fri Jan 23 13:38:00 2004 Subject: [Hipsec] Question about how to test the HIP implementation in FreeBSD-5.1 In-Reply-To: <1AAD8741-4DD2-11D8-B286-000393CE1E8C@nomadiclab.com> References: <200401231820.26296.jrh@it.uc3m.es> <1AAD8741-4DD2-11D8-B286-000393CE1E8C@nomadiclab.com> Message-ID: <200401232017.27588.jrh@it.uc3m.es> On Friday 23 January 2004 19:29, Pekka Nikander wrote: > Hi Juan, > > > "Now just use applications as normally you would and if the peer's > > host name > > resolves to a HIT-IP-pair then a HIP negotiation will be triggered by > > the > > IPSec policy." > > > > How can I make this resolution happen ? Would you mind explaining this > > with a little more precision ? An example would be great (^--^) > > The easiest way is to add peer HITs to /etc/hosts on each > machine. Just like they were IPv6 addresses. > I'm trying to test it on the same machine. I've set up an anonymous FTP server, I've got the following on my interface and "hipd" is running: sis0: flags=8943 mtu 1500 inet 163.117.139.95 netmask 0xffffff00 broadcast 163.117.139.255 inet6 fe80::20d:9dff:fe46:f2c9%sis0 prefixlen 64 scopeid 0x2 inet6 71e1:1a89:9035:770f:2191:d10b:2a64:e369 prefixlen 2 inet6 2001:720:410:100f:20d:9dff:fe46:f2c9 prefixlen 64 autoconf ether 00:0d:9d:46:f2:c9 media: Ethernet autoselect (100baseTX ) status: active You can see that I've added the HIT public key on the interface. This is what I've put on the /etc/hosts: 71e1:1a89:9035:770f:2191:d10b:2a64:e369 hiphurra But when I try: root@cimborrio:~# ftp hiphurra it doesn't work, what else do I have to do ? Besides... even if I were doing it between 2 machines, it wouldn't be enough putting the HIT on /etc/hosts, because it would be necessary to set the destination IP address as well, right ? How can I do it ? something like this on /etc/hosts ? machine machine Thanks alot ! From pekka.nikander@nomadiclab.com Fri Jan 23 13:47:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Jan 23 13:47:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: <1F606C27-4DDA-11D8-B286-000393CE1E8C@nomadiclab.com> Tom, Julien and Marcelo, > I have some questions regarding the mobility draft. Some > things have changed considerably since the time that REA was in > the base spec, and I don't understand the motivation for many of > these changes, and am wondering whether they are necessary. Very good question. I will try to give some motivation below. However, it is far from clear whether -01 is any better than the -00 mechanism. It was mostly an experiment to see if it would be possible to make REA a parameter instead of a separate packet. I don't know whether it adds or reduces semantic complexity. That is something that we need to discuss. > i) we used to have a REA that updated the (primary) destination > address to use for the HIP SA. This did not cause rekeying or > new SPI generation, nor did it require a return routability > check. REA could be authenticated based on signature. We now > seem to have drifted far from this basic approach. Well, REA still still updates the primary destination address. I will add the option of being able to use REA without RR, as I already wrote. I'm not sure if the tight integration with NES, as is done in -01, is the right way of performing RR. I wanted to see whether it is possible at all, and what are the resulting semantics. I think this was a good exercise, even if we decided to abandon it. It showed that we really need HIP association specific sequence numbers to prevent replay attacks. We probably would have noticed that anyway, but probably much later. > Why does readdressing require return routability check (what > is the attack?) and new SPI generation? Return routability check was discussed already. SPI generation is a side effect of integrating with NES. But there is more. When you readdress, your may temporarily loose your connectivity. This may lead one end to send lots of packets that get dropped, and that may eventually lead to a situation where the IPsec SAs replay protection windows get out of sync. Secondly, if you move to a network which is behind a NAT box, you have to inform the NAT box about your SPIs, or otherwise the NAT box is not able to map the SPIs to your IP address. > Asked another way, what is it about a simple REA/REA-ACK > handshake, and modification of the preferred outbound IP address > without otherwise changing the SA, that is undesirable? Considering the going-behind-a-NAT-box case, there were basically two alternatives. One would be to include both SPIs (incoming and outgoing) to the REA, allowing the NAT box to learn the mappings from a single REA. However, that leads to a potential vulnerability, where the sender of the REA lies about the the SPI of the direction where it doesn't have control. It also leads to complications if there are cascading NATs. The other alternative is the one I chose, changing the SPI in both directions in separate packets. Now, Tom, would it suffice to you if the spec allowed one to have the old SPI and new SPI identical, in which case there would be no drawing of new keying material nor other changes in the SA? > ii) There is an additional level of abstraction introduced called > an "interface." > (also, the overloading of the term "interface" may cause confusion > because most people have rather concrete conceptions of what an > interface is.) The name "interface" was a poor choice. I've already now changed it to "address group", more to indicate that it is a logical concept. The basic reason for this concept is that if you have a multi-homed host with different QoS characteristics on the different interfaces, you need different SAs or otherwise some of your packets will arrive outside of the replay protection window. I have no desire to use them for something else. Some other people may have, though. I don't see any reason why they couldn't be used, provided a suitable local policy. But that would be a different extension from REA, I think. > For HIP to support more > than one SA between any two hosts requires some way to index > SAs within the context of the HIP association. Well, you need that in the kernel, yes. But as far as I can see, you don't need to expose that to most applications. (Some applications may want to know, through some new API.) > But I question whether it is necessary, and if it is, shouldn't > it be in the base spec and in the architecture doc? I see it as an extension, extending the logical concept of a single SA just over different paths with different latencies and bandwidths. Due to replay protection you just can't use a single SA any more. On the other hand, all of the parallel SAs have the same policy, and the kernel may select which SA is used, based on the current multi-homing situation. > iii) as for multihoming, the architecture is unclear. How does > this play with SCTP dynamic address reconfiguration, which > looks similar to me (allows multiple addresses to be in use, > for purposes of recovery via alternate path-- and in the future, > load balancing?-- and allows one address to be "primary"). This is a good question to be discussed at the multi6 wg. > Are both needed? No. > Should HIP mechanism replace transport level multi-address > handling? I think so, but apparently a number of people disagree. > Should more work on the SLAP concept be done? Definitely, IMHO. But maybe slightly later. > Note also that if congestion control > continues to live in the transport protocol above > HIP, it is not appropriate to hide the presence of multiple > possible source and destination addresses (multiple paths) > from transport, so it is probably not appropriate to infer > that transport level connections need not have any notion > of underlying IP addresses anymore with HIP. We are envisioning to implement this by having different set of transport QoS estimate data structures, and having the HIP layer to change the structure "underneath". In that way you "change TCPs memory" without TCP being aware of that. However, that is more thought as an implementation hack allowing quick prototyping that the proper way of doing it. > This also gets into the question of whether it is HIP's job > to determine which of possible addresses should be primary. Indeed. > Maybe the approach, suggested by Marcelo in a previous post, > towards specifying only a basic mechanism for mobility (change > primary destination address to use for IPsec transport > layer outer header) is the prudent approach for now, with > more comprehensive multihoming (and perhaps mobility > extensions) coming later. Hmm. Given the current situation in multi6, I think that the kind of proposal I wrote is valuable. Indeed, I was asked to write a HIP based multi-homing spec. The two drafts, draft-nikander-hip-mm-01.txt and draft-nikander-multi6-hip-00.txt, form that now. (I will try to update both before the final Seoul deadline.) > minor comments: I'll address these in -02. Thanks. My current plan is to issue a -02 based on -01, with these minor comments and more text based on this discussion. In parallel, we can discuss whether the -01 approach is any better than -00 approach. Apparently -01 is still not the "right" way. More thinking and experimenting is needed. --Pekka Nikander From pekka.nikander@nomadiclab.com Fri Jan 23 13:49:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Jan 23 13:49:00 2004 Subject: [Hipsec] Question about how to test the HIP implementation in FreeBSD-5.1 In-Reply-To: <200401232017.27588.jrh@it.uc3m.es> References: <200401231820.26296.jrh@it.uc3m.es> <1AAD8741-4DD2-11D8-B286-000393CE1E8C@nomadiclab.com> <200401232017.27588.jrh@it.uc3m.es> Message-ID: <6296B420-4DDA-11D8-B286-000393CE1E8C@nomadiclab.com> > I'm trying to test it on the same machine. If I remember correctly, it doesn't quite work. But I don't remember the details. Currently you need two machines. That's a bug, and should be fixed. But there are worse bugs. Like getting occasional core dumps in some corner cases, not supporting resynching etc. --Pekka From thomas.r.henderson@boeing.com Fri Jan 23 19:02:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Jan 23 19:02:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, January 23, 2004 11:27 AM > To: Henderson, Thomas R; Julien Laganier; Marcelo Bagnulo > Cc: > Subject: Re: [Hipsec] Re: draft-nikander-hip-mm-01.txt >=20 >=20 > Tom, Julien and Marcelo, >=20 > > I have some questions regarding the mobility draft. Some > > things have changed considerably since the time that REA was in > > the base spec, and I don't understand the motivation for many of > > these changes, and am wondering whether they are necessary. >=20 > Very good question. I will try to give some motivation below. > However, it is far from clear whether -01 is any better than > the -00 mechanism. It was mostly an experiment to see if > it would be possible to make REA a parameter instead of > a separate packet. I don't know whether it adds or reduces > semantic complexity. That is something that we need to > discuss. >=20 > > i) we used to have a REA that updated the (primary) destination > > address to use for the HIP SA. This did not cause rekeying or > > new SPI generation, nor did it require a return routability > > check. REA could be authenticated based on signature. We now > > seem to have drifted far from this basic approach. >=20 > Well, REA still still updates the primary destination address. > I will add the option of being able to use REA without RR, > as I already wrote. >=20 > I'm not sure if the tight integration with NES, as is done > in -01, is the right way of performing RR. I wanted to see > whether it is possible at all, and what are the resulting > semantics. >=20 > I think this was a good exercise, even if we decided to > abandon it. It showed that we really need HIP > association specific sequence numbers to prevent replay > attacks. We probably would have noticed that anyway, > but probably much later. >=20 > > Why does readdressing require return routability check (what > > is the attack?) and new SPI generation? >=20 > Return routability check was discussed already. > SPI generation is a side effect of integrating with NES. >=20 > But there is more. When you readdress, your may temporarily > loose your connectivity. This may lead one end > to send lots of packets that get dropped, and that may > eventually lead to a situation where the IPsec SAs replay > protection windows get out of sync. >=20 Good point. Maybe the replay protection window is temporarily inflated = during periods of mobility? =20 > Secondly, if you move to a network which is behind a NAT > box, you have to inform the NAT box about your SPIs, or > otherwise the NAT box is not able to map the SPIs to your > IP address. >=20 > > Asked another way, what is it about a simple REA/REA-ACK > > handshake, and modification of the preferred outbound IP address > > without otherwise changing the SA, that is undesirable? >=20 > Considering the going-behind-a-NAT-box case, there were > basically two alternatives. One would be to include > both SPIs (incoming and outgoing) to the REA, allowing > the NAT box to learn the mappings from a single REA. > However, that leads to a potential vulnerability, where > the sender of the REA lies about the the SPI of the > direction where it doesn't have control. It also > leads to complications if there are cascading NATs. >=20 > The other alternative is the one I chose, changing the > SPI in both directions in separate packets. Understood now-- it is difficult to decouple NES from REA because of = NAT. >=20 > Now, Tom, would it suffice to you if the spec allowed one > to have the old SPI and new SPI identical, in which > case there would be no drawing of new keying material > nor other changes in the SA? Yes, that sounds like the most flexible approach. >=20 > > ii) There is an additional level of abstraction introduced called > > an "interface." > > (also, the overloading of the term "interface" may cause confusion > > because most people have rather concrete conceptions of what an > > interface is.) >=20 > The name "interface" was a poor choice. I've already now > changed it to "address group", more to indicate that it is > a logical concept. >=20 > The basic reason for this concept is that if you have a > multi-homed host with different QoS characteristics on > the different interfaces, you need different SAs or > otherwise some of your packets will arrive outside of the replay > protection window. >=20 > I have no desire to use them for something else. Some > other people may have, though. I don't see any reason > why they couldn't be used, provided a suitable local policy. > But that would be a different extension from REA, I think. >=20 > > For HIP to support more > > than one SA between any two hosts requires some way to index > > SAs within the context of the HIP association. >=20 > Well, you need that in the kernel, yes. But as far as I can > see, you don't need to expose that to most applications. (Some > applications may want to know, through some new API.) >=20 > > But I question whether it is necessary, and if it is, shouldn't > > it be in the base spec and in the architecture doc? >=20 > I see it as an extension, extending the logical concept of a > single SA just over different paths with different latencies > and bandwidths. Due to replay protection you just can't use > a single SA any more. On the other hand, all of the parallel > SAs have the same policy, and the kernel may select which SA > is used, based on the current multi-homing situation. Let me see if I can add some structure to what you are saying, modulated = by what I was arguing for, and you can correct me where I am wrong. address11 =20 SA1 < =20 / address12 =20 / =20 association - SA2 =20 / =20 / SA =20 host - association < =20 SA =20 ... =20 Hosts are defined by their unique host identities. Sockets are bound to = host identities and ports. =20 Each host can have multiple HIP associations, which are stateful = signaling relationships between hosts. Each host has only one HIP = association active with any other given host at a given time. The HIP = associations exist to create and manipulate the SAs. =20 Each HIP association can create one or more SAs used for data transfer = for data emanating from sockets bound to the particular host identities. = The different SAs are indexed by their SPIs and directionality = (inbound/outbound). =20 Each SA is affiliated with a subset of local addresses on the host = machine. By default (without REA), a single outbound SA is set up to = the peer host, with a single destination address affiliated with the = outbound SA. A single inbound SA is set up as well, and the peer host = knows of one address to send data to on that inbound SA as well. =20 A given IP address may be affiliated with more than one SA. Likewise, a = given SA can be affiliated with more than one source and destination = address. Multiple SAs can exist for an association, governed by similar = policy. For outbound packets, the kernel selects the appropriate = outbound SA, and also the appropriate source and destination addresses, = based on the host identities that are bound to the socket and the = current multi-homing situation. (Note: how to select is an open = issue). Inbound packets are accepted on any inbound SA, provided that = they decrypt and pass replay window protection, and the IP addresses are = not used as selectors for the SA. Inbound packets are demultiplexed = based on the host identities bound to the incoming SPI, and the = transport ports. REA is the mechanism for adding an address to or deleting an address = from a SA. More generally, REA is used with NES to set up new SAs with = new SPIs. To possibly traverse NATs at a new location, upon relocation, = both hosts should send NES so that they expose their SPIs to the NAT. = It is the policy of the mobile or multihomed host to decide when to send = REA or NES. There are unresolved issues with respect to transport layer = signaling or hooks to handle the fact that transport connections may be = changing paths over time. >=20 > > iii) as for multihoming, the architecture is unclear. How does > > this play with SCTP dynamic address reconfiguration, which > > looks similar to me (allows multiple addresses to be in use, > > for purposes of recovery via alternate path-- and in the future, > > load balancing?-- and allows one address to be "primary"). >=20 > This is a good question to be discussed at the multi6 wg. >=20 > > Are both needed? >=20 > No. >=20 > > Should HIP mechanism replace transport level multi-address > > handling? >=20 > I think so, but apparently a number of people disagree. I think so too, but we would need to come up with a compelling mechanism = that would convince e.g. SCTP that their mechanism is redundant. =20 >=20 > > Should more work on the SLAP concept be done? >=20 > Definitely, IMHO. But maybe slightly later. >=20 > > Note also that if congestion control > > continues to live in the transport protocol above > > HIP, it is not appropriate to hide the presence of multiple > > possible source and destination addresses (multiple paths) > > from transport, so it is probably not appropriate to infer > > that transport level connections need not have any notion > > of underlying IP addresses anymore with HIP. >=20 > We are envisioning to implement this by having different > set of transport QoS estimate data structures, and having > the HIP layer to change the structure "underneath". In > that way you "change TCPs memory" without TCP being aware > of that. However, that is more thought as an implementation > hack allowing quick prototyping that the proper way of > doing it. >=20 > > This also gets into the question of whether it is HIP's job > > to determine which of possible addresses should be primary. >=20 > Indeed. >=20 > > Maybe the approach, suggested by Marcelo in a previous post, > > towards specifying only a basic mechanism for mobility (change > > primary destination address to use for IPsec transport > > layer outer header) is the prudent approach for now, with > > more comprehensive multihoming (and perhaps mobility > > extensions) coming later. >=20 > Hmm. Given the current situation in multi6, I think that > the kind of proposal I wrote is valuable. Indeed, I was > asked to write a HIP based multi-homing spec. The two drafts, > draft-nikander-hip-mm-01.txt and > draft-nikander-multi6-hip-00.txt, > form that now. (I will try to update both before the final > Seoul deadline.) Sorry, I must have missed the multi6-hip-00 document. Or maybe it is = not published yet. Tom >=20 > > minor comments: >=20 > I'll address these in -02. Thanks. >=20 > My current plan is to issue a -02 based on -01, with these > minor comments and more text based on this discussion. > In parallel, we can discuss whether the -01 approach is any > better than -00 approach. Apparently -01 is still not the > "right" way. More thinking and experimenting is needed. >=20 > --Pekka Nikander >=20 >=20 From thomas.r.henderson@boeing.com Sun Jan 25 16:01:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Jan 25 16:01:01 2004 Subject: [Hipsec] ESP_TRANSFORM (64-bit sequence number) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B6155@xch-nw-27.nw.nos.boeing.com> this is a nit, but I am wondering whether there is any reason to use the most significant bit of the reserved field for the "E" bit, rather than the least significant bit? Use of bits in the HIP control field has started from least significant bit, and that is also the practice I am familiar with in various protocols. Tom > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Friday, January 23, 2004 3:16 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] ESP_TRANSFORM (64-bit sequence number) >=20 >=20 > The need for 64-bit sequence numbers was indicated with the=20 > E-bit in the=20 > HIP header. As discussed earlier on the HIPSEC list, this bit is now=20 > removed from the header and moved to the ESP_TRANSFORM parameter. >=20 >=20 From thomas.r.henderson@boeing.com Sun Jan 25 16:49:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Jan 25 16:49:00 2004 Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Friday, January 23, 2004 3:09 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 >=20 >=20 > I have been updating the draft-hip-09-pre1. Changes that are=20 > (almost) done: >=20 > o NES is changed to UPD > o NES_INFO parameter changed to NES > o State names have been changed > o In case of node reboot, incoming unknown ESP packet triggers an I1=20 > packet sending with RESYNC bit set. >=20 > I include new versions of 5.3 and 5.4 here. The state machine is from=20 > Julien's earlier post (not directly copied, it may contain typos...) > The HIP basic header will contain a RESYNC -bit. >=20 > /petri >=20 >=20 >=20 > 5.3 Reboot and SA timeout restart of HIP >=20 > Simulating a loss of state is a potential DoS attack. =20 > The following > process has been crafted to manage state recovery without=20 > presenting > a DoS opportunity. >=20 > If a host reboots or times out, it has lost its HIP state. If the > system that lost state has a datagram to deliver to its peer, it > simply restarts the HIP exchange. The peer sends an R1=20 > HIP packet, > but does not reset its state until it receives the I2 HIP packet. > The I2 packet MUST have a Birthday greater than the current SA's > Birthday. This is to handle DoS attacks that simulate a=20 > reboot of a > peer. Note that either the original Initiator or the=20 > Responder could > end up restarting the exchange, becoming the new Initiator. >=20 > If a system receives an ESP packet for an unknown SPI, it=20 > is possible > that it has lost the state and its peer has not. In this case, the > system initiates a new HIP exchange for re-establishing=20 > the SA. The > RESYNC bit in the I1 packet is set to indicate the peer about the > possible state loss. I would prefer to make the above a "MAY" (initiate a new exchange). Does it make any difference to the peer whether I1 has RESYNC set or not? (does it cause any different behavior?). Maybe rather than RESYNC bit, we should allow for "Unknown SPI" parameter to be included in the I2. >=20 > The initiating host cannot know, if the SA indicated by=20 > the received > ESP packet is either a HIP SA or and IKE SA. If the old=20 > SA was not a > HIP SA, the peer may not respond to the I1 packet. >=20 > After sending the I1, the HIP negotiaton proceeds as normally and, > when successful, the SA is created at the initiating end. The peer > end removes the OLD SA and replaces it with the new one. >=20 > 5.4 HIP State Machine >=20 > The HIP protocol itself has very little state. In the HIP base > exchange, there is an Initiator and a Responder. Once the SAs are > established, this distinction is lost. If the HIP state=20 > needs to be > re-established, the controlling parameters are which peer=20 > still has > state and which has a datagram to send to its peer. The following > state machine attempts to capture these processes. >=20 > The state machine is presented in a single system view,=20 > representing > either an Initiator or a Responder. There is not a=20 > complete overlap > of processing logic here and in the packet definitions. Both are > needed to completely implement HIP. >=20 > Implementors must understand that the state machine, as described > here, is informational. Specific implementations are free to > implement the actual functions differently. >=20 > 5.4.1 HIP States >=20 > UNASSOCIATED State machine start >=20 > I1-SENT Initiating HIP >=20 > I2-SENT Waiting to finish HIP >=20 > ESTABLISHED HIP SA established >=20 > REKEYING HIP SA established, rekeying >=20 > RESYNC Peer lost state, resyncing >=20 > E-FAILED HIP SA establishment failed >=20 >=20 > 5.4.2 HIP State Processes >=20 > +------------+ > |UNASSOCIATED| Start state > +------------+ >=20 > Datagram to send, send I1 and go to I1-SENT > Receive I1, send R1 and stay at UNASSOCIATED > Receive I2, process > if successful, send R2 and go to ESTABLISHED > if fail, stay at UNASSOCIATED > Receive ESP for unknown SA, send I1 and go to I1-SENT > Receive ANYOTHER, drop and stay at UNASSOCIATED >=20 > +---------+ > | I1-SENT | Initiating HIP > +---------+ >=20 > Receive I1, send R1 and stay at I1-SENT > Receive I2, process > if successful, send R2 and go to ESTABLISHED > if fail, stay at I1-SENT > Receive R1, process > if successful, send I2 and go to I2-SENT > if fail, go to E-FAILED > Receive ANYOTHER, drop and stay at I1-SENT > Timeout, increment timeout counter > If counter is less than I1_RETRIES_MAX, send I1 and=20 > stay at =20 > I1-SENT > If counter is greater than I1_RETRIES_MAX, go to E-FAILED >=20 > +---------+ > | I2-SENT | Waiting to finish HIP > +---------+ >=20 > Receive I1, send R1 and stay at I2-SENT > Receive I2, process > if successful, send R2 and go to ESTABLISHED > if fail, stay at I2-SENT > Receive R2, process > if successful, go to ESTABLISHED > if fail, go to E-FAILED > Receive ANYOTHER, drop and stay at I2-SENT > Timeout, increment timeout counter > If counter is less than I2_RETRIES_MAX, send I2 and=20 > stay at =20 > I2-SENT > If counter is greater than I2_RETRIES_MAX, go to E-FAILED >=20 > +------------+ > |ESTEBALISHED| HIP SA established ESTABLISHED > +------------+ >=20 > Receive I1, send R1 and stay at go to RESYNC > Receive I2, process with Birthday check > if successful, send R2, drop old SA and cycle at ESTABLISHED Should we say "old SAs" in the case of possible multihoming? maybe say: if successful, send R2, drop old SAs, establish new SA, = reenter ESTABLISHED > if fail, stay at ESTABLISHED > Receive R1, drop and stay at ESTABLISHED >=20 >=20 > Receive R2, drop and stay at ESTABLISHED >=20 > Receive ESP for SA, process and stay at ESTABLISHED > Receive UPD, process > if successful, send UPD and stay at ESTABLISHED > if failed, stay at ESTABLISHED > Need rekey, > send UPD and go to REKEYING >=20 > +----------+ > | REKEYING | HIP SA established, rekey pending > +----------+ >=20 > Receive I1, send R1 and stay at REKEYING > Receive I2, process with Birthday check > if successful, send R2, drop old SA and go to ESTABLISHED > if fail, stay at REKEYING > Receive R1, process with SA and Birthday check > if successful, send I2, prepare to drop old SA and=20 > go to =20 > ESTABLISHED > if fail, stay at REKEYING what triggers the above R1? If I am in REKEYING I have recently been in ESTABLISHED and I have sent an UPD. Should R1 be an illegal packet here? > Receive R2, drop and stay at REKEYING >=20 > Receive ESP for SA, process and stay at REKEYING > Receive UPD, process > if successful, replace SAs and go to ESTABLISHED > if failed, stay at REKEYING > Timeout, increment timeout counter > If counter is less than UPD_RETRIES_MAX, send UPD and=20 > stay at REKEYING > If counter is greater than UPD_RETRIES_MAX, go to E-FAILED >=20 > +--------+ > | RESYNC | HIP SA established, resync pending > +--------+ >=20 > Receive I1, send R1 and cycle at RESYNC > Receive I2, process with Birthday check > if successful, send R2, drop old SA and go to ESTABLISHED > if fail, stay at RESYNC > Receive R1, process with SA and Birthday check > if successful, send I2, prepare to drop old SA and=20 > cycle at =20 > RESYNC > if fail, stay at RESYNC > Receive R2, process with SA and Birthday check > if successful, go to ESTABLISHED > if fail, stay at RESYNC >=20 > Receive ESP for SA, process and go to ESTABLISHED > Receive UPD, process > if successful, send UPD and go to ESTABLISHED > if failed, stay at RESYNC > Timeout, increment timeout counter > if counter is less than RESYNC_RETRIES_MAX, send I2 and=20 > stay at RESYNC > if counter is greater than RESYNC_RETRIES_MAX, go to=20 > ESTABLISHED >=20 how about a description for E-FAILED? +----------+ | E-FAILED | HIP failed to establish association with peer +----------+ Implementation-dependent wait until you go back to UNASSOCIATED and = permit=20 retries? Log the error? > 5.4.3 Simplified HIP State Diagram >=20 > Receive packets cause a move to a new state. >=20 > +------------+ > |UNASSOCIATED|>---+ > +------------+ | > | ^ | | > | | | Dgm to | > +-+ | send | > I1 | ESP- | (note: ESP- means ESP with unknown SPI) > | | > v | > +---------+ | > | I1-SENT |>---|----------+ > +---------+ | | > | | | > | R1 | | > | |I2 |I2 > v | | > +---------+ | | > | I2-SENT |>---|----------|-----+ > | | | | | > +---------+ | | | > | | | | > | R2 | | |I2 > | | | | > v | | | > +-----------+<-+ | | > | | | | > |ESTABLISHED|<------------+ | > | |<------------------+ > | |<------------------+ > | |>------------+ | > | |<-----+ | | > | |--+ | | | > +-----------+ | | | | > | ^ ^ | | | | > | | | | | | | > +--+ | | | | | > ESP, | rekey| |R1,I2 | | > UPD, | | | | | > I1, |UPD | | | | > I2, | | | | | > R1 | | | | | > | | | | | > +---------+ | | | | > | |<---+ | | | > |REKEYING |>-------+ | | > +---------+ | | > | ^ v | | I2, R2, ESP > | | | R1 | | UPD, Timeout > +--+ | | | > ESP, | | | > I1, | | | > | v ^ > | R1 +--------+ > +--------------->| RESYNC | > +--------+ > | ^ > | | > +--+ > I1, > R1 >=20 =20 nice artwork. Too bad there is no way to do simple vector graphics other than ASCII in IETF documents. Tom=20 =20 =20 From thomas.r.henderson@boeing.com Sun Jan 25 17:05:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Jan 25 17:05:01 2004 Subject: [Hipsec] DH keymaterial regeneration during base exchange Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24F@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Friday, January 23, 2004 7:37 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] DH keymaterial regeneration during base exchange >=20 >=20 > Solution 1: Cache the DHa until it expires. > - If DHb did not do the trick on the responder, fall back to using the > cached DHa if DHa has not expired (and deallocated). > - The probability of fall backing to the cached DHa is quite minimal, > so it is difficult to use for DoS. >=20 > Solution 2: modify the state machine > - In UNASSOCIATED, the responder receives an I2 and encryption fails. > Resend R1 (with DHb) and don't change state. > - In I2_SENT, the initiator receives R1, processes it, resends I2 and > stays in I2_SENT. >=20 > These were just some coarse grained ideas, we haven't had=20 > time to think > about this in more depth yet. Has anyone solved this problem already? > Any ideas? Caching DHa for a while seems reasonable, and requiring new cookies to be generated when using a new DH, so that the cookie can be linked to the DH that was in effect. I'm wondering how vulnerable Solution 2 is to old R1 replay attacks,=20 getting initiator and responder to be repeatedly misaligned. Tom From pekka.nikander@nomadiclab.com Sun Jan 25 19:26:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Jan 25 19:26:00 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24C@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24C@xch-nw-27.nw.nos.boeing.com> Message-ID: Tom, (Jari, see a note about MOKIKE close to the top.) [Writing off-line, not seeing possible replies in between.] >> But there is more. When you readdress, your may temporarily >> loose your connectivity. This may lead one end >> to send lots of packets that get dropped, and that may >> eventually lead to a situation where the IPsec SAs replay >> protection windows get out of sync. > > Good point. Maybe the replay protection window is temporarily > inflated during periods of mobility? Maybe. This is probably something that we want to consider at the MOBIKE WG. They have the same problem. Jari, do you have an opinion on this? >> Secondly, if you move to a network which is behind a NAT >> box, you have to inform the NAT box about your SPIs, or >> otherwise the NAT box is not able to map the SPIs to your >> IP address. > > Understood now-- it is difficult to decouple NES from REA > because of NAT. It can sure be expressed in that way. I would say that because of NAT, it is always necessary to explicitly carry the SPIs in REAs, leading to considerable overlap in NES and REA syntax. Secondly, for multi-homing with paths with different QoS characteristics, it is often necessary to introduce new SAs in REAs announcing new addresses. =46rom there on, it is a small step to integrate them also functionally and semantically. However, I am still not sure whether this is the right thing. I thought so before writing -01, but I am not *so* sure any more. I guess I need some implementation insight. >> Now, Tom, would it suffice to you if the spec allowed one >> to have the old SPI and new SPI identical, in which >> case there would be no drawing of new keying material >> nor other changes in the SA? > > Yes, that sounds like the most flexible approach. Ok. I'll try to add that. > Let me see if I can add some structure to what you are > saying, modulated by what I was arguing for, and you can > correct me where I am wrong. Ok. In general, your text looks excellent. Maybe we should add it to the introduction in -mm-02? > > address11 > SA1 < > / address12 > / > association - SA2 > / > / SA > host - association < > SA > ... > > Hosts are defined by their unique host identities. > Sockets are bound to host identities and ports. Ok. > Each host can have multiple HIP associations, which are > stateful signaling relationships between hosts. Each > host has only one HIP association active with any other > given host at a given time. Ok. > The HIP associations exist to create and manipulate the SAs. Well, this depends on your point of view. If you take a different angle, you could say that HIP associations exist to allow transport layer sessions to survive changes of underlying IP addresses. > Each HIP association can create one or more SAs used > for data transfer for data emanating from sockets bound > to the particular host identities. The different SAs > are indexed by their SPIs and directionality > (inbound/outbound). Ok. [Well, to be precise, each HIP association seems to require at least two SAs (instead of just one).] > Each SA is affiliated with a subset of local addresses > on the host machine. By default (without REA), a single > outbound SA is set up to the peer host, with a single > destination address affiliated with the outbound SA. > A single inbound SA is set up as well, and the peer host > knows of one address to send data to on that inbound SA > as well. Right. > A given IP address may be affiliated with more than one SA. > Likewise, a given SA can be affiliated with more than one > source and destination address. Multiple SAs can exist for > an [HIP]=A0association, [all] governed by similar policy. Yes. > For outbound packets, the kernel selects the appropriate > outbound SA, and also the appropriate source and destination > addresses, based on the host identities that are bound to > the socket and the current multi-homing situation. Agreed. > (Note: how to select is an open issue). Right. Right now we are looking at simple heuristics based on data coming from the PF_ROUTE socket. > Inbound packets are accepted on any inbound SA, provided > that they decrypt and pass replay window protection, and > the IP addresses are not used as selectors for the SA. > Inbound packets are demultiplexed based on the host > identities bound to the incoming SPI, and the transport > ports. Right. > REA is the mechanism for adding an address to or deleting > an address from a SA. More generally, REA [can be] used > with NES to set up new SAs with new SPIs. To possibly > traverse NATs at a new location, upon relocation, both hosts > should send NES so that they expose their SPIs to the NAT. Yes. > It is the policy of the mobile or multi-homed host to decide > when to send REA or NES. Yes. > There are unresolved issues with respect to transport layer > signaling or hooks to handle the fact that transport > connections may be changing paths over time. That's right. And a very interesting area to study, in my opinion. >>> Should HIP mechanism replace transport level multi-address >>> handling? >> >> I think so, but apparently a number of people disagree. > > I think so too, but we would need to come up with a compelling > mechanism that would convince e.g. SCTP that their mechanism is > redundant. Patience :-). I discussed with Randall Stewart and Michael T=FCxen. Sure they were skeptical, but they were also very interested. And I learned a lot. > Sorry, I must have missed the multi6-hip-00 document. Or maybe > it is not published yet. I sent it to the drafts editor a few days ago. I don't know when it will be public. Once it is, I will announce it also at hipsec list. --Pekka From miika@iki.fi Mon Jan 26 03:00:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Jan 26 03:00:01 2004 Subject: [Hipsec] ESP_TRANSFORM (64-bit sequence number) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B6155@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B6155@xch-nw-27.nw.nos.boeing.com> Message-ID: On Sun, 25 Jan 2004, Henderson, Thomas R wrote: > > The need for 64-bit sequence numbers was indicated with the > > E-bit in the > > HIP header. As discussed earlier on the HIPSEC list, this bit is now > > removed from the header and moved to the ESP_TRANSFORM parameter. > > this is a nit, but I am wondering whether there is any > reason to use the most significant bit of the reserved > field for the "E" bit, rather than the least significant > bit? Use of bits in the HIP control field has started > from least significant bit, and that is also the practice > I am familiar with in various protocols. Perhaps the whole "reserved" field could also be changed to "flags". The flags field could then contain the "E" bit. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From petri.jokela@nomadiclab.com Thu Jan 29 06:02:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Jan 29 06:02:01 2004 Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC24E@xch-nw-27.nw.nos.boeing.com> Message-ID: <4018F16E.4080204@nomadiclab.com> Henderson, Thomas R wrote: >>the SA. The >> RESYNC bit in the I1 packet is set to indicate the peer about the >> possible state loss. > > > I would prefer to make the above a "MAY" (initiate a new exchange). > > Does it make any difference to the peer whether I1 has RESYNC set or > not? (does it cause any different behavior?). Maybe rather than > RESYNC bit, we should allow for "Unknown SPI" parameter to be > included in the I2. I don't know what the host in ESTABLISHED state would gain from the RESYNC bit. What about the case when hosts A and B do not have any association. The host C sends ESP packets to B with A's source IP address. The B would then initiate a connection to A with an I1 (if host B considers that ESP packets may belong to a lost association). The A responds with R1, thinking that someone is trying to establish a connection. Thus, we end up with an SA that neither A nor B needs. If the I1 contains a RESYNC bit, the A could just drop the packet. (Or R1 could include also a RESYNC bit. A responds with R1 without RESYNC bit, saying "I don't have any association, but feel free to continue if you want." and from that B would notice that something is wrong.) >> +------------+ >> >> Receive I1, send R1 and stay at go to RESYNC >> Receive I2, process with Birthday check >> if successful, send R2, drop old SA and cycle at ESTABLISHED > > maybe say: > if successful, send R2, drop old SAs, establish new SA, reenter ESTABLISHED Ok. >> +----------+ >> | REKEYING | HIP SA established, rekey pending >> +----------+ >> >> Receive R1, process with SA and Birthday check >> if successful, send I2, prepare to drop old SA and >>go to >>ESTABLISHED >> if fail, stay at REKEYING > > > what triggers the above R1? If I am in REKEYING I have recently > been in ESTABLISHED and I have sent an UPD. > > Should R1 be an illegal packet here? Yes, I think so. >> >> +--------+ >> | RESYNC | HIP SA established, resync pending >> +--------+ >> >> Receive I1, send R1 and cycle at RESYNC >> Receive I2, process with Birthday check >> if successful, send R2, drop old SA and go to ESTABLISHED >> if fail, stay at RESYNC >> Receive R1, process with SA and Birthday check >> if successful, send I2, prepare to drop old SA and >>cycle at >>RESYNC Here is also the same question: what triggers R1 or R2. The change to RESYNC should be triggered by the incoming I1 and we should not have sent any I1 or I2. > > how about a description for E-FAILED? Ok. /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 thomas.r.henderson@boeing.com Thu Jan 29 11:36:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Jan 29 11:36:01 2004 Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC266@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Thursday, January 29, 2004 3:42 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4 >=20 >=20 > Henderson, Thomas R wrote: >=20 > >>the SA. The > >> RESYNC bit in the I1 packet is set to indicate the peer=20 > about the > >> possible state loss. > >=20 > >=20 > > I would prefer to make the above a "MAY" (initiate a new exchange). > >=20 > > Does it make any difference to the peer whether I1 has RESYNC set or > > not? (does it cause any different behavior?). Maybe rather than > > RESYNC bit, we should allow for "Unknown SPI" parameter to be > > included in the I2. >=20 > I don't know what the host in ESTABLISHED state would gain from the=20 > RESYNC bit. >=20 > What about the case when hosts A and B do not have any=20 > association. The=20 > host C sends ESP packets to B with A's source IP address. The B would=20 > then initiate a connection to A with an I1 (if host B=20 > considers that ESP=20 > packets may belong to a lost association). The A responds with R1,=20 > thinking that someone is trying to establish a connection.=20 > Thus, we end=20 > up with an SA that neither A nor B needs. I agree that this should be avoided. It is easy to envision how this could occur in certain mobility scenarios. >=20 > If the I1 contains a RESYNC bit, the A could just drop the=20 > packet. (Or=20 > R1 could include also a RESYNC bit. A responds with R1 without RESYNC=20 > bit, saying "I don't have any association, but feel free to=20 > continue if=20 > you want." and from that B would notice that something is wrong.) >=20 Yes, you are right, this is probably needed. But notice that it requires more work for the responder A (cross-check the incoming I1 against its list of security associations) than what we have previously specified for the responder, in order to avoid a DoS reflection attack on B. =20 Including an "Unknown SPI" field in the I1 and R1 would probably=20 help A evaluate the best course of action. If the SPI is fake, generated by C, A can check whether it should ignore or reject=20 the I1 (A may actually have an active SA to B on another SPI). Maybe we need an explicit reject to notify B in this case, rather than silently dropping when mischief is detected, to preempt I1 retransmissions? It seems unfortunate that a rogue packet can=20 trigger a two-packet exchange and some work between A and B,=20 but that is probably an unavoidable consequence of the attempt=20 to respond to an "unknown SPI" packet that itself cannot be=20 authenticated up front. That is why I would like to not make this a mandatory response, because we may find that it is abused in practice. Tom From petri.jokela@nomadiclab.com Fri Jan 30 08:22:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Jan 30 08:22:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 Message-ID: <401A63FD.5060104@nomadiclab.com> I uploaded pre2 version of the draft-moskowitz-hip-09 to http://hip4inter.net/drafts.php There are both text and html versions as well as diffs between 08 -> 09pre2 and 09pre1 -> 09pre2. Please, feel free to comment. Shortly (before leaving home): I have fixed the state machine (a bit) and changed the section 8 to meet the current idea of sending I1 as a response to an unknown ESP. This may still require fixes... NES is changed to UPD, NES_INFO parameter to NES, state names changed in the state machine, RESYNC state added and R-bit added to the HIP header for RESYNC purposes (this requires still some thinking). HIP_SIGNATURE (1&2) have new type numbers, we propose to leave some empty space behind them for possible future use (at the same time, HMAC type was changed to keep it below SIGs). Appendix F contains now help for checksum verification. Have a nice weekend! 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 thomas.r.henderson@boeing.com Sat Jan 31 18:04:32 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Jan 31 18:04:32 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> Petri, here are some comments: General: i) In reading through the draft, it struck me that there are lots of instances where HIP silently drops packets (if something goes wrong, etc.). For example, if a certain parameter type is not supported, HIP drops the packet. While it is necessary to prevent exploitation of a "REJECT" mechanism, I think that there probably will be some use to having a HIP REJECT (with type code to denote the error) to tell the peer what went wrong. Something to think about... ii) I'd like to ask that, when the issue tracker is restarted, that "possible removal of Birthday count" be added to the list. (see previous email message: http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.html) Specific: - top of page 5, "identies" -> "identities" - The state machine doesn't seem to allow for retransmitted I2s. If in ESTABLISHED, and I2 is received, it should not necessarily cause drop of SAs or drop of I2 (due to birthday check fail)--=20 it may just mean that R2 needs retransmitted. This means that=20 even though distinction between Initiator and Responder can mostly=20 be dropped when entering ESTABLISHED, there is still the=20 possibility that the Responder will need to retransmit the R2. - how about "UPD" -> "UPDATE" (global change)? - I must have missed this in previous drafts, but why do we need to have different parameter type codes for BIRTHDAY_COOKIE? - regarding the critical parameter, what is the situation for which a critical parameter is not recognized by the recipient (Sec 6.2.1, page 29)? Shouldn't this cause an increment of HIP version number? - in the HOST_ID_FQDN parameter definition, there is a typo error "FDQN" -> "FQDN" - there are a couple of instances where packet processing text is placed in the parameter definition section. e.g., HMAC calculation and processing 6.2.11 and signature processing (6.2.12)-- I think these sections should be in the packet processing section 8, and keep section 6 limited to specifying the syntax and semantics of the parameter fields. - Section 8.2-- processing incoming application data.=20 - first comment is that in sentence 1, it implies that IPsec SAs are selected based on IP addresses, which is not=20 necessarily the case for BEET mode. - in sentence 4, should note that demultiplexing is based=20 on HITs *and port numbers* - page 61, "pacoket" -> "packet" Tom > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Friday, January 30, 2004 6:03 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 >=20 >=20 > I uploaded pre2 version of the draft-moskowitz-hip-09 to >=20 > http://hip4inter.net/drafts.php >=20 > There are both text and html versions as well as diffs between 08 ->=20 > 09pre2 and 09pre1 -> 09pre2. >=20 > Please, feel free to comment. Shortly (before leaving home): >=20 > I have fixed the state machine (a bit) and changed the=20 > section 8 to meet=20 > the current idea of sending I1 as a response to an unknown=20 > ESP. This may=20 > still require fixes... >=20 > NES is changed to UPD, NES_INFO parameter to NES, state names=20 > changed in=20 > the state machine, RESYNC state added and R-bit added to the=20 > HIP header=20 > for RESYNC purposes (this requires still some thinking). >=20 > HIP_SIGNATURE (1&2) have new type numbers, we propose to leave some=20 > empty space behind them for possible future use (at the same=20 > time, HMAC=20 > type was changed to keep it below SIGs). >=20 > Appendix F contains now help for checksum verification. >=20 > Have a nice weekend! >=20 > Petri >=20 >=20 > --=20 > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20