From mkousa@cc.hut.fi Thu Apr 1 05:30:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Apr 1 05:30:01 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: <4062D165.1040509@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403241721.30296.Jan.Melen@nomadiclab.com> <4062D165.1040509@nomadiclab.com> Message-ID: One more thing which occurred while implementing UPDATE: (using section numbers from draft-hip10-pre1) Chapter 8.9 (Initiating rekeying) does not say anything about on setting up some initial IPsec SA, because we need to know the New SPI value in the NES TLV of the UPDATE to be sent. Only after some four pages from 8.9 at section 8.10.2 there is a small sentence "It must also complete its new incoming SA." Why not adding some explicit note on creating the new SA to section 8.9, eg. between bullet points 3 and 4 ? It is always better to read explicit instructions than trying to figure out what is really needed in the real world implementation by reading between the lines and spending n^n hours before the great moment of "aaaa..so this is what was really meant in the specs and this is what I should have done even though the specs give no hints that it is needed" happens. And yes, there is a comment "The following steps define the conceptual processing rules", but future developers of HIP would avoid the same problems as I've had. From pekka.nikander@nomadiclab.com Fri Apr 2 08:50:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Apr 2 08:50:01 2004 Subject: [Hipsec] Update race condition In-Reply-To: <406807A9.4040800@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> Message-ID: <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> [Sorry for the delay in answering.] > In the original KEYMAT generation, the HITs are put into the KEYMAT > "generator" in a certain order. The key retrieval is done depending on > the Initiator / Responder status. Nope. See the draft in more detail :) > K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) > ... > Sort(HIT-I | HIT-R) is defined as the network byte order > concatenation of the two HITs, with the smaller HIT preceding the > larger HIT, resulting from the numeric comparison of the two HITs > interpreted as positive (unsigned) 128-bit integers in network byte > order. > In the UPDATE case, we retrieve keys using the HIT comparison. I don't > see direct analogy between these processes. Or was this what you > meant? To me they seem to be identical. > 8.10 Processing UPDATE packet > > When a host receives an UPDATE packet, it indicates that either the > host > itself has earlier requested rekeying or the peer is initiating > rekeying. > > If either of the hosts requires that a new KEYMAT must be generated, > the generation is done as described in 9. HIP KEYMAT. I think the text above is enough. > The order of the keys retrieved from the KEYMAT during rekeying process > depends on the HIT value comparison. We denote the host with lower HIT > value with HOST_l and, respectively, the host with greater HIT with > HOST_g. The HITs are compared in network byte order. The keys are > retrieved from the KEYMAT in the following order. That nor any of the following suggested text is not needed, as far as I can see. >>> 5. If the received UPDATE does not contain a Diffie-Hellman >>> parameter, the received Keymat Index MUST be larger or equal >>> to >>> the index of the next byte to be drawn from the current >>> KEYMAT. >>> If the host is in REKEYING state, a smaller Keymat Index >>> value >>> MAY be accepted. If the host is in ESTABLISHED state and >>> this >>> test fails, the packet SHOULD be dropped and the system >>> SHOULD >>> log an error message. >> I find this lacking of information. I think there should be some >> description >> of the reasons for the MAY, i.e., under which condition accepting >> such a >> lower index is reasonable. > > ... a smaller Keymat Index MAY be accepted, if the host itself has > skipped part of the KEYMAT and selected a bigger index for the > previously sent UPDATE packet. Ok. --Pekka From pekka.nikander@nomadiclab.com Fri Apr 2 08:56:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Apr 2 08:56:00 2004 Subject: The history of cookie design (was Re: [Hipsec] Cookies) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060515@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060515@xch-nw-27.nw.nos.boeing.com> Message-ID: <25EF1CE0-84B4-11D8-83AA-000393CE1E8C@nomadiclab.com> Tom, > The puzzles allow the responder to control a certain amount > of DoS resilience. I believe that the design was motivated by > work described in: > http://research.microsoft.com/users/tuomaura/Publications/aura- > nikander-leiwo-protocols00.pdf Actually it wasn't, but the original design was earlier by Bob Moskowitz. I don't remember where he got it, but probably from some other people that had been working on the same kind of approaches independent from us. I've just been referring to our paper since it summarises some of the thinking neatly. --Pekka From pekka.nikander@nomadiclab.com Fri Apr 2 09:06:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Apr 2 09:06:00 2004 Subject: [Hipsec] Cookies In-Reply-To: References: Message-ID: <7B64AC42-84B5-11D8-83AA-000393CE1E8C@nomadiclab.com> Jon, [Sorry for the delayed response.] > I'm getting familiar with HIP, and I was wondering > about the design rational behind the way cookies > are currently defined. I am curious why something > like SCTP's cookie method wasn't chosen. IIRC, there were a number of goals behind for the current design: - To include the puzzle. This makes it impractical to have SCTP like opaque cookies. - To make it possible for the Initiator to check that the puzzle has really been generated by the right Responder. This may be desirable for the harder puzzle difficulty levels. - To give the Responder still various options to implement the cookies in different ways. I think there is still an appendix explaining some of the things that you can do. The goal is to allow the responder to make the choice of how much state vs. CPU it would like to use for cookie handling. - And of course, still keep the Responder stateless. Note also that in the later stages, we wanted to explicitly include the HITs into the puzzle, in order to make it impossible to replay the same puzzle solution with different HITs, and to allow the responder to select a suitable cookie based on the initiator IP address, thereby making it impossible to replay a single puzzle solution from multiple IP addresses. I'm too tired right now to be able to figure out if you could achieve these goals with opaque cookies. Maybe. Feel free to propose an alternative cookie design. If it is more flexible, IPR free, and provides at least the same benefits, I don't personally see any reasons why we couldn't adopt one. > Another issue I see with the current mechanism is that > the puzzle I is precomputed, since it is protected by > the signature presumably. This means that an attacker > can solve the puzzle once and then try to pound the > responder by forcing it to do lots of work verifying signatures > and such. This window of opportunity for attack lasts for > the lifetime of the precomputed cookie. Yes, but there are ways to mitigate this. See the appendix. > The root problem here seems to be that I is protected by > the signature, so responders can't hand out a new I in > each R1. So just how important is it that the I is protected > by the signature? Well, now that we have the WG it is up to the WG to decide how important that is. However, the rationale behind that is that you would like to support use cases where the puzzle is very hard, and there you may want to check that you are solving the right puzzle before you start solving that... --Pekka From jonwood@speakeasy.net Fri Apr 2 19:00:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Apr 2 19:00:01 2004 Subject: [Hipsec] Cookies In-Reply-To: <7B64AC42-84B5-11D8-83AA-000393CE1E8C@nomadiclab.com> References: <7B64AC42-84B5-11D8-83AA-000393CE1E8C@nomadiclab.com> Message-ID: <67D7B880-8508-11D8-9FAD-0003930D291E@speakeasy.net> On Apr 2, 2004, at 6:53 AM, Pekka Nikander wrote: > > I'm too tired right now to be able to figure out > if you could achieve these goals with opaque cookies. > Maybe. Feel free to propose an alternative cookie > design. If it is more flexible, IPR free, and provides > at least the same benefits, I don't personally see any > reasons why we couldn't adopt one. OK, I'll write something up and send it to the list. > >> Another issue I see with the current mechanism is that >> the puzzle I is precomputed, since it is protected by >> the signature presumably. This means that an attacker >> can solve the puzzle once and then try to pound the >> responder by forcing it to do lots of work verifying signatures >> and such. This window of opportunity for attack lasts for >> the lifetime of the precomputed cookie. > > Yes, but there are ways to mitigate this. See the > appendix. I did - which is why I started thinking "Is there a simpler way to do this?" :) Jon From jonwood@speakeasy.net Fri Apr 2 21:46:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Apr 2 21:46:01 2004 Subject: [Hipsec] Cookie Proposal Message-ID: [ Apologies if this shows up twice; I sent it from the wrong account last time ] There are two changes proposed. Each is somewhat independant of the other. 1. Make the birthday cookie TLV variable-length. All other fields are identical. The responder MAY put some additional data in this field to help it verify that it has received an answer to the exact puzzle it proposed, and that the sender of the I2 is the same as the sender of the I1. If there is any additional data in the cookie received in the R1, the initiator MUST copy this data unchanged to the cookie it includes in the I2. The rational for this is that implementations can opt to not use the opaque field in favor of something akin to the approach described in the appendix. However, it offers greater flexibility to implementations that wish to use another approach (such as the one I describe below). 2. For the cookie included in an R1, the signature field does not cover the I or K values. If there is any additional data in the cookie's opaque field, the signature also does not cover that data. When computing the signature, these fields MUST be set to zero. Before verifying the signature, these fields must be saved, set to zero, and then restored after verifying the signature. For the cookie included in an I2, the signature covers the entire cookie (this should simplify processing). The idea here is that if an implementation has a cheap source of random numbers, the responder can hand out a new puzzle to each I1 without needing to recompute a signature. The K is also left outside the signature since if a responder is experiencing heavy load and wishes to slow down initiators by increasing K, the last thing it wants to do is to undertake an expensive signing operation. I can't see any security problems with this right now, but if there are any, this suggestion is weakened. The new cookie TLV would look like this: 6.2.4 BIRTHDAY_COOKIE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K or Random # J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (in R1) or 5 (in I2) Length length in octets, excluding Type, Length, and padding Reserved Zero when sent, ignored when received Birthday System boot counter Random # I random number K K is the number of verified bits (in R1 packet) Random # J random number (in I2 packet) Opaque opaque bytes (possible zero), set by responder and returned unchanged by initiator. Birthday, Random #I, K, and Random #J are represented as 64-bit integers, in network byte order. An Example: Handling Cookies with Opaque Data On startup, a HIP implementation pre-computes and signs an R1 with an empty cookie (i.e. the I, K, and opaque fields are zero). It also creates a new random secret. Upon receiving an I1, the responder randomly generates a new I, sets K according to its load and trust of the initiator, and places these values in the cookie in the pre-computed R1. It then concatenates the initiator's HIT, and the I, and K values from the cookie, and creates a MAC using this data and the secret as the key. The MAC and K are placed in the cookie's opaque field. When the responder receives an I2, it first ensures that the opaque field is large enough to contain the K and the MAC, dropping the packet if not. The responder then recreates the MAC by combining the initiator's HIT, the I, and the K from the opaque data, using the same secret as above. If the MAC matches, the responder proceeds with verification of the puzzle solution. A HIP implementation should periodically change its secret. When doing so, it should store the previous value of the secret for a short time in case the secret change occured in between sending an R1 and receiving an I2. If the MAC verification fails with the current secret, the responder should retry the verification with the previous secret. From petri.jokela@nomadiclab.com Mon Apr 5 02:32:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Apr 5 01:32:00 2004 Subject: [Hipsec] Update race condition In-Reply-To: <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> Message-ID: <4070FA19.9050805@nomadiclab.com> Pekka Nikander wrote: > [Sorry for the delay in answering.] > >> In the original KEYMAT generation, the HITs are put into the KEYMAT >> "generator" in a certain order. The key retrieval is done depending on >> the Initiator / Responder status. > > > Nope. See the draft in more detail :) Now you have to point out this for me, because I read from section 9: --8<-- The initial keys are drawn sequentially in the following order: HIP-IR encryption key for Initiator's outgoing HIP packets HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets (... and so on) The IR and RI denotes the direction of the traffic where the key is applied. The IR describes "from the Initiator to the Responder" -direction and the RI the other direction. --8<-- For me this looks clear that the key retrieval is done using Initiator / Responder status. /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 jwnospam@speakeasy.net Tue Apr 6 07:27:05 2004 From: jwnospam@speakeasy.net (JW) Date: Tue Apr 6 06:27:05 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <67D7B880-8508-11D8-9FAD-0003930D291E@speakeasy.net> References: <7B64AC42-84B5-11D8-83AA-000393CE1E8C@nomadiclab.com> <67D7B880-8508-11D8-9FAD-0003930D291E@speakeasy.net> Message-ID: <9B5EB80E-851E-11D8-9FAD-0003930D291E@speakeasy.net> There are two changes proposed. Each is somewhat independant of the other. 1. Make the birthday cookie TLV variable-length. All other fields are identical. The responder MAY put some additional data in this field to help it verify that it has received an answer to the exact puzzle it proposed, and that the sender of the I2 is the same as the sender of the I1. If there is any additional data in the cookie received in the R1, the initiator MUST copy this data unchanged to the cookie it includes in the I2. The rational for this is that implementations can opt to not use the opaque field in favor of something akin to the approach described in the appendix. However, it offers greater flexibility to implementations that wish to use another approach (such as the one I describe below). 2. For the cookie included in an R1, the signature field does not cover the I or K values. If there is any additional data in the cookie's opaque field, the signature also does not cover that data. When computing the signature, these fields MUST be set to zero. Before verifying the signature, these fields must be saved, set to zero, and then restored after verifying the signature. For the cookie included in an I2, the signature covers the entire cookie (this should simplify processing). The idea here is that if an implementation has a cheap source of random numbers, the responder can hand out a new puzzle to each I1 without needing to recompute a signature. The K is also left outside the signature since if a responder is experiencing heavy load and wishes to slow down initiators by increasing K, the last thing it wants to do is to undertake an expensive signing operation. I can't see any security problems with this right now, but if there are any, this suggestion is weakened. The new cookie TLV would look like this: 6.2.4 BIRTHDAY_COOKIE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K or Random # J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (in R1) or 5 (in I2) Length length in octets, excluding Type, Length, and padding Reserved Zero when sent, ignored when received Birthday System boot counter Random # I random number K K is the number of verified bits (in R1 packet) Random # J random number (in I2 packet) Opaque opaque bytes (possible zero), set by responder and returned unchanged by initiator. Birthday, Random #I, K, and Random #J are represented as 64-bit integers, in network byte order. An Example: Handling Cookies with Opaque Data On startup, a HIP implementation pre-computes and signs an R1 with an empty cookie (i.e. the I, K, and opaque fields are zero). It also creates a new random secret. Upon receiving an I1, the responder randomly generates a new I, sets K according to its load and trust of the initiator, and places these values in the cookie in the pre-computed R1. It then concatenates the initiator's HIT, and the I, and K values from the cookie, and creates a MAC using this data and the secret as the key. The MAC and K are placed in the cookie's opaque field. When the responder receives an I2, it first ensures that the opaque field is large enough to contain the K and the MAC, dropping the packet if not. The responder then recreates the MAC by combining the initiator's HIT, the I, and the K from the opaque data, using the same secret as above. If the MAC matches, the responder proceeds with verification of the puzzle solution. A HIP implementation should periodically change its secret. When doing so, it should store the previous value of the secret for a short time in case the secret change occured in between sending an R1 and receiving an I2. If the MAC verification fails with the current secret, the responder should retry the verification with the previous secret. From pekka.nikander@nomadiclab.com Tue Apr 6 07:45:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 6 06:45:01 2004 Subject: [Hipsec] Update race condition In-Reply-To: <4070FA19.9050805@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> Message-ID: <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> >>> In the original KEYMAT generation, the HITs are put into the KEYMAT >>> "generator" in a certain order. The key retrieval is done depending >>> on >>> the Initiator / Responder status. >> Nope. See the draft in more detail :) > > Now you have to point out this for me, because I read from section 9: > > --8<-- > > The initial keys are drawn sequentially in the following order: > HIP-IR encryption key for Initiator's outgoing HIP packets > HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets > (... and so on) > > The IR and RI denotes the direction of the traffic where the key is > applied. The IR describes "from the Initiator to the Responder" > -direction and the RI the other direction. > > --8<-- Oops. We are apparently comparing apples and oranges. The HITs are *put* into the KEYMAT in sorting order, still in Section 9: > The KEYMAT is derived by feeding Kij and the HITs into the following > operation; the | operation denotes concatenation. > > KEYMAT = K1 | K2 | K3 | ... > where > > K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) Note the *sort* operation. The keys are *drawn* from the KEYMAT in role depending order. I've had so many interruptions during this discussion that I don't remember any more which matters. --Pekka From petri.jokela@nomadiclab.com Tue Apr 6 09:14:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Apr 6 08:14:00 2004 Subject: [Hipsec] Update race condition In-Reply-To: <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> Message-ID: <4072A9DB.2050205@nomadiclab.com> Pekka Nikander wrote: > > Note the *sort* operation. > > The keys are *drawn* from the KEYMAT in role depending order. > I've had so many interruptions during this discussion that I > don't remember any more which matters. Yes, the discussion was about drawing the keys from the keymat during UPDATE that will depend on the HIT comparison, and will be different from the original key drawing during base exchange. Generation will be done during the base exchange or in a similar way during UPDATE. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Tue Apr 6 14:41:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 6 13:41:01 2004 Subject: [Hipsec] The order in which keys are drawn (was: Re: Update race condition) In-Reply-To: <4072A9DB.2050205@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> Message-ID: <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> > Yes, the discussion was about drawing the keys from the keymat during > UPDATE that will depend on the HIT comparison, and will be different > from the original key drawing during base exchange. Generation will be > done during the base exchange or in a similar way during UPDATE. Just to simplify code: Should we change the case even in the base exchange case, so that we use the HIT order instead of the roles? In other words, should we define the key order to _always_ depend on the order of HITs, regardless of the roles of the parties? Any opinions? --Pekka From pekka.nikander@nomadiclab.com Tue Apr 6 14:44:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 6 13:44:03 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <9B5EB80E-851E-11D8-9FAD-0003930D291E@speakeasy.net> References: <7B64AC42-84B5-11D8-83AA-000393CE1E8C@nomadiclab.com> <67D7B880-8508-11D8-9FAD-0003930D291E@speakeasy.net> <9B5EB80E-851E-11D8-9FAD-0003930D291E@speakeasy.net> Message-ID: Jon, (Please subscribe with the address you want to post with, or let me know your alternate posting addresses so that I can add them explicitly to the list filters. Makes posting faster.) > There are two changes proposed. Each is somewhat independant of the > other. > > 1. Make the birthday cookie TLV variable-length. All other fields are > identical. Sounds good to me, on first reading. > 2. For the cookie included in an R1, the signature field does not cover > the I or K values. I'm not convinced, but I'll consider this more. I'll just need some flow time, and can't foresee when I'll have it. Anyone else, a security analysis/comparison, even a straw man one? --Pekka From pekka.nikander@nomadiclab.com Tue Apr 6 15:04:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 6 14:04:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200403301101.48448.julien.laganier@sun.com> References: <200403300840.48337.Jan.Melen@nomadiclab.com> <200403300940.03439.julien.laganier@sun.com> <40693912.5060400@iki.fi> <200403301101.48448.julien.laganier@sun.com> Message-ID: <7E32C73E-87FB-11D8-9B06-00306571BE62@nomadiclab.com> I like the idea of just forwarding the I1, i.e. rewriting the IP header, with a new optional parameter saying who (apparently) was the originator. There COULD also be an (optional) HMAC, added by the RSV if it does have an active HIP association with the responder. There is one potential attack I see here: Someone impersonates as the RSV for many nodes, sends them I1s with the FORWARDED_FROM TLV (and without HMAC), and makes them to send R1s in a concerted fashion to a victim. As R1s are bigger than I1s, this is both amplification and reflection, in the sense discussed during MIPv6 RO security design. To block the attack from anywhere else but RSV addresses, the responder should obviously check that the I1 source address matches with an RSV one before responding to FORWARDED_FROM address. To block the attack when the responder does have an active HIP assoc with the RSV, the responder should check that if there is no HMAC but there is an active HIP association, the packet is dropped, maybe sending a NOTIFY to the RSV. But, some things to consider and discuss further before making any final decision... >> If the new TLV is optional then all hosts might not process it. In >> this case they will send an R1 to the RvS. The RvS will not reply >> with I2 as the destination HIT in the R1 will be unknown. > Right, they'll drop it (or forward it to the initiator if the RVS have > kept some state in between.... not a very good idea though) Well, I think that it might even be a _good_ idea to briefly keep state after forwarding an I1. You can make a hard limit to the state, and just drop old entries if you get an I1 storm. > But, if a HIP node register with a RVS and published its address > (e.g., in the DNS), then we can legitimately suppose that this node > needs RVS functionnalities. IMHO, such a HIP node MUST support the > FORWARDED_FROM TLV, while we can keep it optionnal for other HIP > nodes. Sounds good. >> Also I don't think extending the I1 will bloat the base protocol. I'm pretty sure that we will see also other extensions to I1. --Pekka From shep@alum.mit.edu Tue Apr 6 15:36:04 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Tue Apr 6 14:36:04 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: Your message of Tue, 06 Apr 2004 21:52:03 +0300. <7E32C73E-87FB-11D8-9B06-00306571BE62@nomadiclab.com> Message-ID: > I like the idea of just forwarding the I1, i.e. rewriting the IP > header, with a new optional parameter saying who (apparently) was > the originator. There COULD also be an (optional) HMAC, added > by the RSV if it does have an active HIP association with the > responder. > > There is one potential attack I see here: Someone impersonates > as the RSV for many nodes, sends them I1s with the FORWARDED_FROM > TLV (and without HMAC), and makes them to send R1s in a concerted > fashion to a victim. As R1s are bigger than I1s, this is both > amplification and reflection, in the sense discussed during MIPv6 > RO security design. > > To block the attack from anywhere else but RSV addresses, the > responder should obviously check that the I1 source address matches > with an RSV one before responding to FORWARDED_FROM address. I like the idea of RSV keeping an active HIP associations open with those for whom it is doing forwarding of I1s. In that case, you can just forward the I1 over ESP. And since the only purpose of your locators which are served by RSV is to get I1s sent to you, I think it reasonable to allow (encourage) RSVs to rate-limit how many such things get forwarded your way (perhaps with a token-bucket sort of mechanism) and just quietly drop other stuff. Hmm, I think we'll have to keep thinking about all of the DOS possibilities. Every time I think I've figured out how to defend against one type of DOS attack, another one seems to pop up. -Tim Shepard shep@alum.mit.edu From jeffrey.m.ahrenholz@boeing.com Tue Apr 6 16:27:00 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Tue Apr 6 15:27:00 2004 Subject: [Hipsec] The order in which keys are drawn (was: Re: Update race condition) Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361E39@xch-nw-09.nw.nos.boeing.com> This sounds good to me, so drawing keys will always be the same procedure, and this helps to diminish the distinction between initiator and responder. -Jeff > Just to simplify code: Should we change the case even in the=20 > base exchange case, so that we use the HIT order instead of=20 > the roles? In other words, should we define the key order to=20 > _always_ depend on the order of HITs, regardless of the roles=20 > of the parties? From jonwood@speakeasy.net Tue Apr 6 17:31:04 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Tue Apr 6 16:31:04 2004 Subject: [Hipsec] The order in which keys are drawn (was: Re: Update race condition) In-Reply-To: <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> Message-ID: <0D0DB036-8810-11D8-B7EB-0003930D291E@speakeasy.net> Sounds like a good idea. On Apr 6, 2004, at 11:29 AM, Pekka Nikander wrote: > > Just to simplify code: Should we change the case even in the base > exchange case, so that we use the HIT order instead of the roles? > In other words, should we define the key order to _always_ depend > on the order of HITs, regardless of the roles of the parties? > > Any opinions? > > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Tue Apr 6 17:47:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 6 16:47:00 2004 Subject: [Hipsec] Cookie Proposal Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406055A@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: JW [mailto:jwnospam@speakeasy.net]=20 > Sent: Friday, April 02, 2004 7:26 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Cookie Proposal >=20 >=20 > 2. For the cookie included in an R1, the signature field does=20 > not cover > the I or K values. If there is any additional data in the cookie's > opaque field, the signature also does not cover that data. When > computing the signature, these fields MUST be set to zero. Before > verifying the signature, these fields must be saved, set to zero, > and then restored after verifying the signature. For the cookie > included in an I2, the signature covers the entire cookie (this > should simplify processing). >=20 > The idea here is that if an implementation has a cheap source of > random numbers, the responder can hand out a new puzzle to each > I1 without needing to recompute a signature. The K is also left > outside the signature since if a responder is experiencing heavy > load and wishes to slow down initiators by increasing K, the last > thing it wants to do is to undertake an expensive signing=20 > operation. > I can't see any security problems with this right now, but if > there are any, this suggestion is weakened. >=20 >=20 Jon, Somewhere your proposal morphed from excluding I from signature to=20 both I and K. If K is outside, it puts the initiator at risk to=20 grind away on a really hard problem if the K value is rewritten by a man-in-the-middle. Further, this mischief, if it is not too blatant, might go undetected by the end hosts, since a solution for larger K is also solution for smaller K. It seems to me that, upon changes in loading, the responder can=20 undertake the operation of generating a new R1 once, or precompute a=20 few with larger K "just in case," if that is a concern. Tom =20 From jonwood@speakeasy.net Tue Apr 6 18:37:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Tue Apr 6 17:37:01 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406055A@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055A@xch-nw-27.nw.nos.boeing.com> Message-ID: <4166C9E2-8819-11D8-B7EB-0003930D291E@speakeasy.net> Hello Tom, Yes, I did change the proposal so that the signature would not include K. My rational was that a man-in-the-middle attack would not be able to cause significant trouble, since initiators must guard against overly- hard K values anyway (i.e. don't accept any over 20). Otherwise, any responder could attack initiators that way. If a man-in-the-middle wants to engage in a DOS attack, there are much simpler ways to go about it (for example, just change 1 bit in the R1 and cause the checksum to fail). Also, if the K value is changed, it is detectable at the responder - for the hashing scheme outlined in the appendix, if the K is part of the hash, a changed K will be detected (by hashing to the wrong cookie). For my opaque cookie proposal, you can just make K part of the MAC computation. If my reasoning is correct, then it is simpler to just assign a K according to load conditions than to precalculate lots of R1s or create a new R1 and signature. Having said that, however, whether or not the K is protected by the signature is not all that important to me. I just included it since I thought it might make things a bit simpler for implementations. The alternatives you suggest below are certainly reasonable. I am more interested in seeing the I fall outside the signature. Regarding both the I and K values in the R1, I think having the signature not cover them is OK since they are protected by other mechanisms, such as the hashing scheme in the appendix. If they are changed, the worst that can happen is DOS, and the severity of the DOS exposure is no worse than if they are covered by the signature. Jon On Apr 6, 2004, at 2:32 PM, Henderson, Thomas R wrote: > > Jon, > Somewhere your proposal morphed from excluding I from signature to > both I and K. If K is outside, it puts the initiator at risk to > grind away on a really hard problem if the K value is rewritten by > a man-in-the-middle. Further, this mischief, if it is not too blatant, > might go undetected by the end hosts, since a solution for larger K is > also solution for smaller K. > > It seems to me that, upon changes in loading, the responder can > undertake the operation of generating a new R1 once, or precompute a > few with larger K "just in case," if that is a concern. > > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Tue Apr 6 19:01:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 6 18:01:01 2004 Subject: [Hipsec] Cookie Proposal Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Tuesday, April 06, 2004 3:25 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Cookie Proposal >=20 >=20 >=20 > Hello Tom, >=20 > Yes, I did change the proposal so that the signature would not include > K. My rational was that a man-in-the-middle attack would not be able > to cause significant trouble, since initiators must guard against=20 > overly- > hard K values anyway (i.e. don't accept any over 20). Otherwise, any > responder could attack initiators that way. If a=20 > man-in-the-middle wants > to engage in a DOS attack, there are much simpler ways to go about it > (for example, just change 1 bit in the R1 and cause the checksum > to fail). >=20 > Also, if the K value is changed, it is detectable at the=20 > responder - for > the hashing scheme outlined in the appendix, if the K is part of > the hash, a changed K will be detected (by hashing to the=20 > wrong cookie). > For my opaque cookie proposal, you can just make K part of the MAC > computation. >=20 > If my reasoning is correct, then it is simpler to just assign a K=20 > according > to load conditions than to precalculate lots of R1s or create a new R1 > and signature. OK, I will buy that argument. >=20 > Having said that, however, whether or not the K is protected by the > signature is not all that important to me. I just included it since I=20 > thought > it might make things a bit simpler for implementations. The=20 > alternatives > you suggest below are certainly reasonable. I am more interested in > seeing the I fall outside the signature. >=20 > Regarding both the I and K values in the R1, I think having the > signature not cover them is OK since they are protected by other > mechanisms, such as the hashing scheme in the appendix. If they > are changed, the worst that can happen is DOS, and the severity > of the DOS exposure is no worse than if they are covered by the > signature. I agree that the I is more important than the K, I was just trying to rise to your challenge of finding security problems in leaving K = outside. =20 If K is checked or folded into the hashing scheme, then I think it is = fine either way. If there is MITM, there are probably other worse attacks to subtly degrade but not block communications. Tom From andrew@indranet.co.nz Wed Apr 7 00:23:00 2004 From: andrew@indranet.co.nz (Andrew McGregor) Date: Tue Apr 6 23:23:00 2004 Subject: [Hipsec] The order in which keys are drawn (was: Re: Update race condition) In-Reply-To: <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> Message-ID: <612369691.1081354202@[192.168.2.241]> Consistency is preferable, in my opinion. Therefore, yes, we should adopt the same method in each case, whatever it is. Andrew --On Tuesday, 6 April 2004 9:29 p.m. +0300 Pekka Nikander wrote: >> Yes, the discussion was about drawing the keys from the keymat during >> UPDATE that will depend on the HIT comparison, and will be different >> from the original key drawing during base exchange. Generation will be >> done during the base exchange or in a similar way during UPDATE. > > Just to simplify code: Should we change the case even in the base > exchange case, so that we use the HIT order instead of the roles? > In other words, should we define the key order to _always_ depend > on the order of HITs, regardless of the roles of the parties? > > Any opinions? > > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From pekka.nikander@nomadiclab.com Wed Apr 7 01:10:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Apr 7 00:10:02 2004 Subject: [Hipsec] The order in which keys are drawn (was: Re: Update race condition) In-Reply-To: <612369691.1081354202@[192.168.2.241]> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> <612369691.1081354202@[192.168.2.241]> Message-ID: <0B44413A-8850-11D8-9B06-00306571BE62@nomadiclab.com> > Consistency is preferable, in my opinion. Therefore, yes, we should > adopt the same method in each case, whatever it is. I guess I'm seeing consensus for this change (though I'm not a chair and therefore can't really announce one... :) Petri, I guess you can create an issue, edit in the change, and either close the issue or leave it still tentative for a while... (if I was still editor I would close the case, but the idea was mine, anyway...) --Pekka From petri.jokela@nomadiclab.com Wed Apr 7 01:35:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Apr 7 00:35:01 2004 Subject: [Hipsec] The order in which keys are drawn In-Reply-To: <0B44413A-8850-11D8-9B06-00306571BE62@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> <612369691.1081354202@[192.168.2.241]> <0B44413A-8850-11D8-9B06-00306571BE62@nomadiclab.com> Message-ID: <40738F9B.8020604@nomadiclab.com> Pekka Nikander wrote: > I guess I'm seeing consensus for this change (though I'm > not a chair and therefore can't really announce one... :) > > Petri, I guess you can create an issue, edit in the change, > and either close the issue or leave it still tentative for a while... > (if I was still editor I would close the case, but the idea > was mine, anyway...) Yes, this simplifies the key drawing. I'll put it in the next version, if there are no arguments (soon) against it. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Wed Apr 7 02:59:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Apr 7 01:59:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: References: Message-ID: <8B7120F3-885F-11D8-BF97-000393CE1E8C@nomadiclab.com> >> I like the idea of just forwarding the I1, i.e. rewriting the IP >> header, with a new optional parameter saying who (apparently) was >> the originator. ... > > I like the idea of RSV keeping an active HIP associations open with > those for whom it is doing forwarding of I1s. I certainly agree that when you are mobile, you probably want to keep an active HIP association. However, is that really reasonable for an RSV that servers millions of semi-static hosts? Maybe not. I think that we should still design for some flexibility. > In that case, you can just forward the I1 over ESP. Well, you could, but I don't like the idea for two specific reasons. One reason is middle boxes. The current HIP protocol is very carefully designed to be middle box friendly. For example, we have signatures even in UPDATEs (even if HMACs would be enough), and the SPIs are readable in all messages. Passing I1s would violate this design goal. The second reason is architecture. Personally, I like to think HIP as a "control plane" for an "IPsec based overlay". That is, I think that we should allow for the case where HIP protocol messages take a different path (slow path) than the actual ESP traffic (fast path). That might be the case, for example, in high capacity firewalls. But it could also be more general. Hence, I think that passing I1s over ESP might be a MAY, for such cases where it is useful, but definitely not a MUST nor even a SHOULD. In my opinion, in order to keep the design simple and beautiful enough, the MUST implement and SHOULD use case should be passing I1s by rewriting the IP header. To secure that against amplification and reflection, we need to add the FROM and HMAC parameters. > And since the only purpose of your locators which are served by RSV is > to get I1s sent to you, I think it reasonable to allow (encourage) > RSVs to rate-limit how many such things get forwarded your way > (perhaps with a token-bucket sort of mechanism) and just quietly drop > other stuff. Sounds good. But the responder should be in control, i.e. a high capacity responder should be able to make the limit very high. Remember, mobility is not the only reason for RSVs. RSVs could also be used for other purposes, e.g., for robustness or traffic engineering / load balancing. Returning to the passing I1s by rewriting the IP header, I think that the case is trivial if there is an active HIP association. Then the FROM and HMAC parameters would give adequate protection. One thing still needs to be added: An VIARSV parameter to the *end* of R1 (outside of the signed area), informing the initiator that the I1 was received via (one or more) RSVs. However, to give even more flexibility (cascading RSVs) and to support the case when there aren't an active HIP association between the RSV and the responder, I would suggest the following mechanism: 0. The RSV periodically generates a nonce whose lifetime is a few days or longer. 1. As a part of the RSV protocol, the RSV generates a per-served-host key by taking key_host = hash(nonce, HIT_host) This key is communicated (in encrypted form) to the host, and will be valid almost as long as the nonce is valid, i.e. at least a few days. 2. Even when the active HIP association, used for the RSV protocol, is dropped, the host remembers the key_host, and its lifetime. The RSV does not need to remember this key, but it can. (As it stores the IP addresses based on the HIT, storing the key is not that big deal either.) 3. When the RSV receives an I1 destined to the host, it adds a new FROM parameter to the I1. The FROM parameter contains BOTH the original source IP address in the I1, and a HMAC generated using the above mentioned key_host as the key. Note that if there are several cascaded RSVs, each of them can add an independent FROM parameter. When the responder processes a received I1, it does the following: 1. If the source address does not belong to an RSV, process just as before. If there is a FROM parameter, simply ignore it, and respond to the source address in the I1. 2. If the source address does belong to an RSV, check if there is a FROM parameter. If there is one, check the HMAC in the FROM parameter. If the check fails, drop the packet (and optionally send a NOTIFY to the RSV). 3. If there are multiple FROMs, process all of them sequentially, up to a configurable limit. I would suggest default value of 2. 4. For each FROM, add a VIARSV to the end of the R1 that will be sent out. The VIARSV does not need to have any protection. In the worst case, this adds one failing HMAC computation in the case somebody is spoofed IP packets with the source address belonging to an RSV. That seems to be acceptable to me, but still needs to be documented in the security considerations section. Now, my only problem with this is that this is somewhat complicated. Fairly lot of stuff for making it possible to send the R1 directly to the initiator. An alternative would be to add an unprotected FROM to the I1, let the responder answer back to the RSV, and let the R1 carry a TO parameter, letting the RSV to pass the R1 back to the original initiator. No triangular routing, no worries about amplification or reflection. --Pekka From kristian.slavov@iki.fi Wed Apr 7 08:31:00 2004 From: kristian.slavov@iki.fi (Kristian Slavov) Date: Wed Apr 7 07:31:00 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <8B7120F3-885F-11D8-BF97-000393CE1E8C@nomadiclab.com> References: <8B7120F3-885F-11D8-BF97-000393CE1E8C@nomadiclab.com> Message-ID: <4073F19F.1000203@iki.fi> Pekka Nikander wrote: > > Returning to the passing I1s by rewriting the IP header, I think > that the case is trivial if there is an active HIP association. > Then the FROM and HMAC parameters would give adequate protection. > One thing still needs to be added: An VIARSV parameter to the > *end* of R1 (outside of the signed area), informing the initiator > that the I1 was received via (one or more) RSVs. I didn't understand the need for VIARSV parameter, so I had a short discussion with Pekka. He enlightened me that the VIARSV parameter is targeted for network/HIP diagnostics. > Note that if there are several cascaded RSVs, each of > them can add an independent FROM parameter. > > When the responder processes a received I1, it does the > following: > > 1. If the source address does not belong to an RSV, > process just as before. If there is a FROM > parameter, simply ignore it, and respond to the > source address in the I1. > > 2. If the source address does belong to an RSV, > check if there is a FROM parameter. If there > is one, check the HMAC in the FROM parameter. > If the check fails, drop the packet (and optionally > send a NOTIFY to the RSV). > > 3. If there are multiple FROMs, process all of > them sequentially, up to a configurable limit. > I would suggest default value of 2. > > 4. For each FROM, add a VIARSV to the end of the > R1 that will be sent out. The VIARSV does not > need to have any protection. If we have a cascading situation like this: INIT -> RSV1 -> RSV2 -> RESP The I1 would look like: IP (HIP ( FROM, FROM )) The FROM parameters would carry the same IP-address (initiators IP address). The only difference being HMACs created by the RSVs. The responder cannot check the HMAC in first FROM, as it probably does not know anything about the RSV1, only about the RSV2. One advantage in this situation is that we can create those VIARSVs so that the initiator knows I1's route. However, if this is not that important we could have a slightly different aproach: Since RSV1 is providing RSV services to RSV2, once RSV2 receives an I1 with FROM parameter, it processes it. If HMAC is valid, then calculate new HMAC and place it in the FROM parameter (over the HMAC of the RVS1). Now the responder receives only one FROM parameter (initiator's IP address and HMAC created by RSV2), and it can verify the HMAC. > An alternative would be to add an unprotected FROM to the > I1, let the responder answer back to the RSV, and let the > R1 carry a TO parameter, letting the RSV to pass the R1 > back to the original initiator. No triangular routing, > no worries about amplification or reflection. In this case, the HIP implementation in RSV would then have to be able to process R1s received in UNASSOCIATED state. Or perhaps the RSV forwards I1 and transitions to I1-FORWARDED state. Waits for a while and returns to UNASSOCIATED state. While in the I1-FORWARDED state, forwards the R1 and returns to UNASSOCIATED. Naturally the I1-FORWARDED state would not have to exist in implementations that do not support RSV functionality. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 From shep@alum.mit.edu Wed Apr 7 10:29:01 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Apr 7 09:29:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: Your message of Wed, 07 Apr 2004 09:48:15 +0300. <8B7120F3-885F-11D8-BF97-000393CE1E8C@nomadiclab.com> Message-ID: > > In that case, you can just forward the I1 over ESP. > > Well, you could, but I don't like the idea for two specific reasons. > > One reason is middle boxes. The current HIP protocol is very > carefully designed to be middle box friendly. For example, we > have signatures even in UPDATEs (even if HMACs would be enough), > and the SPIs are readable in all messages. Passing I1s would > violate this design goal. Do the middle boxes really need to see the I1? It's not clear to me that they should do anything with I1s. It's the I2s and R2s that imply that state has been established and that carry SPIs that the middlebox might want to know about. I'm assuming that the R1 in response to an I1 would be returned directly, not by way of the forwarder. (Hmm... have to make sure that the initiator can figure out what attempted association the R1 corresponds to. That should be OK, as I don't think we'd be using a rendezvous server in opportunistic mode, so we do have HIT's for both ends.) The I2s and R2s would be much more normal, following normal paths (no forwarding involved). -Tim Shepard shep@alum.mit.edu From pekka.nikander@nomadiclab.com Thu Apr 8 03:18:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 8 02:18:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: References: Message-ID: <75875BA2-892B-11D8-8F08-000393CE1E8C@nomadiclab.com> >>> In that case, you can just forward the I1 over ESP. >> >> Well, you could, but I don't like the idea for two specific reasons. >> >> One reason is middle boxes. The current HIP protocol is very >> carefully designed to be middle box friendly. For example, we >> have signatures even in UPDATEs (even if HMACs would be enough), >> and the SPIs are readable in all messages. Passing I1s would >> violate this design goal. > > Do the middle boxes really need to see the I1? It's not clear to me > that they should do anything with I1s. It's the I2s and R2s that > imply that state has been established and that carry SPIs that the > middlebox might want to know about. Depends. If we have a middle box that just sits there in one IP domain, getting packets from that single domain and passing back, then it doesn't need to inspect current I1s. However, there are (at least) two cases when the situation is not so easy: 1. Consider a middle box between two IP domains, i.e. a NAT device. It may need to see the initial I1 to learn the Initiator-HIT -> Initiator IP address mapping so that it can route back the R1. If RSVs are used, it needs to see the FROM parameter in I1. Note that this is actually pretty similar to the RSV situation. If we wanted the RSV to route back the R1, it needs to store a temporary Initiator HIT -> IP address mapping, i.e., create a temporary piece of state. 2. Remember that the HIP spec is now open to extensions. It may turn that there will be important I1 extensions that middle boxes need to inspect. Hence, as I wrote before, I1 over ESP is OK as a MAY, as it may be appropriate in some situations, but not as the default or recommended case. --Pekka From pekka.nikander@nomadiclab.com Thu Apr 8 03:25:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 8 02:25:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <4073F19F.1000203@iki.fi> References: <8B7120F3-885F-11D8-BF97-000393CE1E8C@nomadiclab.com> <4073F19F.1000203@iki.fi> Message-ID: <636651F5-892C-11D8-8F08-000393CE1E8C@nomadiclab.com> > If we have a cascading situation like this: > > INIT -> RSV1 -> RSV2 -> RESP > > The I1 would look like: IP (HIP ( FROM, FROM )) Yes. > > The FROM parameters would carry the same IP-address (initiators > IP address). No. The first FROM would carry the INIT's IP address, the second one would carry RSV1's IP address. > The only difference being HMACs created by the RSVs. > The responder cannot check the HMAC in first FROM, as it probably > does not know anything about the RSV1, only about the RSV2. Hmmm... I think it should by default know about both. There may be situations where it don't know, but in that case RSV2 should know about RSV1. > One advantage in this situation is that we can create those > VIARSVs so that the initiator knows I1's route. Yes. > However, if this is not that important we could have a slightly > different aproach: > Since RSV1 is providing RSV services to RSV2, once RSV2 receives > an I1 with FROM parameter, it processes it. If HMAC is valid, then > calculate new HMAC and place it in the FROM parameter (over the HMAC > of the RVS1). Now the responder receives only one FROM parameter > (initiator's IP address and HMAC created by RSV2), and it can verify > the HMAC. Otherwise good, but that would make RSV1 invisible, which would be bad from a diagnostics point of view. But yes, RSV2 could verify the HMAC, and create a new FROM that has two addresses: INIT's address and RSV1's address. A kind of reversed routing header. >> An alternative would be to add an unprotected FROM to the >> I1, let the responder answer back to the RSV, and let the >> R1 carry a TO parameter, letting the RSV to pass the R1 >> back to the original initiator. No triangular routing, >> no worries about amplification or reflection. > > In this case, the HIP implementation in RSV would then have to be able > to process R1s received in UNASSOCIATED state. Or perhaps the RSV > forwards I1 > and transitions to I1-FORWARDED state. Waits for a while and returns to > UNASSOCIATED state. While in the I1-FORWARDED state, forwards the R1 > and returns to UNASSOCIATED. Whichever way, we have to notice that the state create DOES NOT involve the RSV's HIT, it only involves the HITs of INIT and RESP. Hence, different from a non-RSV HIP node. I would say that the state machine is completely unrelated to the normal HIP state machine, and should NOT be merged in any way. --Pekka From pekka.nikander@nomadiclab.com Thu Apr 8 05:30:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 8 04:30:01 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> Message-ID: After having thought a little bit about this, I haven't found any reasons why we couldn't leave I outside of the signature. However, I would not necessarily change the SIG2 signature algorithm but just move the puzzle payload before or after the signature. But I am open here as SIG2 is R1 specific anyway. (Maybe it should be renamed as SIG-R1?) However, there are two considerations that we have to keep in mind, *especially* if we move resynchronization out of the base spec. 1. Middle boxes In general, an R1 may traverse a number of middle boxes, either because it is explicitly routed so (the "control plane" case) or just because it happens to traverse different IP domains and must pass NATs. In this case, it would be desirable that the initiator is able to gain *some* assurance that the R1 was actually generated by the responder. Hence, I still think it desirable to have the signature, and I still call for careful thinking about what to cover with the signature and what not. But more about that later. 2. Replay attacks Even though we were not so worried about MitM attacks (since a MitM may launch worse attacks, as Jon reasoned), we still have to worry about replay attacks. Consider a case where Alice sends an I1 to Bob, and Bob replies with a fresh R1. However at the same time Mallory replays an old R1. Which R1 should Alice process? In the worst case she would receive the replayed old R1 several hundred milliseconds before the fresh one. In such a case she should be able to detect that the latter is more recent than the former and abort processing of the former one. So far we have determined that it is OK and actually necessary to leave the initiator HIT outside of the signature. It also looks OK to leave #I outside of the signature, since a wrong #I only makes the initiator to produce a wrong answer, it does not change the magnitude of work. Even if we kept #I still under the signature, there would be cases where a replay attack would work, making the initiator to produce a wrong answer. For example, if the responder is currently unreachable, a replay attack could trick the initiator to produce an old answer that is not valid any more. On the other hand, if the responder is reachable, the initiator will receive also the right R1 and not only the old one, and it will (also) produce the right answer. I don't see any big difference here. The only difference is in the case of middle boxes, and there it apparently doesn't matter. [I have to admit that I haven't quite thought through some of the "control plane" cases, and that I am still a little bit worried, but not that much.] What comes to #K, I would keep it still protected. While a false #K alone does not necessarily make the initiator to produce a wrong answer, it may trick the initiator to unnecessarily burn CPU. Pretty bad for some portable devices which may run out of battery. Having #K signed has the *potential* effect of partially protecting some devices against replay attacks. Finally, due to the desire to make it possible for Alice to make a difference between a replayed and fresh R1s, I think that we need to retain the birthday parameter even if we remove resynchronization out of the base spec, and even make it stronger. Basically, it seems to me best to increment birthday count whenever old R1s are not accepted any more. This is apparently a change to the current draft, and therefore probably requires opening a new issue. [Petri, please.] --Pekka From petri.jokela@nomadiclab.com Thu Apr 8 06:40:04 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 8 05:40:04 2004 Subject: [Hipsec] max retry counters In-Reply-To: <20040329163859.GC4846@irg.cs.ohiou.edu> References: <20040329163859.GC4846@irg.cs.ohiou.edu> Message-ID: <4075289D.3040709@nomadiclab.com> Wesley Eddy wrote: > The current HIP draft refers to three constants (I1_RETRIES_MAX, > I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but I don't see them > defined anywhere in the draft, nor do I see any guidance on what > their values should be set to in an implementation in the draft. > Their purpose is clear, but whether their values should be 3 or > 1000 doesn't seem to be discussed. What have implementers gone > by? I think there should be some guideline at least. Folks, should we have some kind of rough guideline for the counter values in the base draft (some limits or other text that gives some hints what values implementors could select)? Any opinions? /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 petri.jokela@nomadiclab.com Thu Apr 8 07:34:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 8 06:34:01 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> Message-ID: <40753544.80502@nomadiclab.com> Pekka Nikander wrote: > This is apparently a change to the > current draft, and therefore probably requires opening > a new issue. So, shortly: - I will be left out from the signature - K will be included in the signature - Birthday will remain in COOKIE TLVs in any case - Opaque field will be added to the COOKIE TLVs In addition to the TLV changes, some text has to be edited (I will return to this next week). In Issue 26, it was already defined that the BIRTHDAY_COOKIE will be separated into two TLVs: COOKIE_REQUEST and COOKIE_RESPONSE. I haven't yet edited it into the base draft (10-pre1), as the existence of the birthday field was (at that time) dependent on the resync-issue. The following COOKIE TLVs were already earlier in issue 26. So, the addition to the previous discussion is that we include the Birthday again in the TLV. (I'll close issue 26 and continue with the new issue number). In the future the COOKIE TLVs would look something like: 6.2.4 COOKIE_REQUEST 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 28 K K is the number of verified bits Random # I random number Opaque opaque bytes (possible zero), set by responder. Birthday, Random #I and K are represented as 64-bit integers, in network byte order. 6.2.5 COOKIE_RESPONSE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length 28 Random # I random number Random # J random number Opaque opaque bytes (possible zero), sent by Responder in COOKIE_REQUEST TLV and returned unchanged by initiator. Birthday, Random #I and Random #J are represented as 64-bit integers, in network byte order. -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Thu Apr 8 07:37:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 8 06:37:01 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <40753544.80502@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> <40753544.80502@nomadiclab.com> Message-ID: <9355B751-894F-11D8-9A39-000393CE1E8C@nomadiclab.com> > - I will be left out from the signature I think so, yes. > - K will be included in the signature Yes. > - Birthday will remain in COOKIE TLVs in any case I think it was earlier decided to split the COOKIE parameter into a BIRTHDAY parameter and PUZZLE/SOLUTION parameters. But maybe I misunderstood some of the issue 26 discussion. > - Opaque field will be added to the COOKIE TLVs I think so, yes. --Pekka From petri.jokela@nomadiclab.com Thu Apr 8 07:50:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 8 06:50:02 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <9355B751-894F-11D8-9A39-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> <40753544.80502@nomadiclab.com> <9355B751-894F-11D8-9A39-000393CE1E8C@nomadiclab.com> Message-ID: <40753920.1080308@nomadiclab.com> Pekka Nikander wrote: >> - Birthday will remain in COOKIE TLVs in any case > > I think it was earlier decided to split the COOKIE parameter > into a BIRTHDAY parameter and PUZZLE/SOLUTION parameters. > But maybe I misunderstood some of the issue 26 discussion. The removal of birthday was requested by Thomas earlier (related to resync removal from the base draft). It is discussed more under issue 15. /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 Apr 8 11:12:04 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 8 10:12:04 2004 Subject: [Hipsec] max retry counters Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060568@xch-nw-27.nw.nos.boeing.com> Here is what IKEv2 has to say on this issue: Numbers of retries and lengths of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. Tom > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Thursday, April 08, 2004 3:26 AM > To: weddy@masaka.cs.ohiou.edu > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] max retry counters >=20 >=20 > Wesley Eddy wrote: > > The current HIP draft refers to three constants (I1_RETRIES_MAX, > > I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but I don't see them > > defined anywhere in the draft, nor do I see any guidance on what > > their values should be set to in an implementation in the draft. > > Their purpose is clear, but whether their values should be 3 or > > 1000 doesn't seem to be discussed. What have implementers gone > > by? I think there should be some guideline at least. >=20 > Folks, should we have some kind of rough guideline for the counter=20 > values in the base draft (some limits or other text that gives some=20 > hints what values implementors could select)? Any opinions? >=20 > /petri >=20 > --=20 > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From pekka.nikander@nomadiclab.com Thu Apr 8 11:30:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 8 10:30:01 2004 Subject: [Hipsec] max retry counters In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060568@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060568@xch-nw-27.nw.nos.boeing.com> Message-ID: <39709E58-8970-11D8-B6D5-000393CE1E8C@nomadiclab.com> >>> The current HIP draft refers to three constants (I1_RETRIES_MAX, >>> I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but I don't see them >>> defined anywhere in the draft, nor do I see any guidance ... >> >> Folks, should we have some kind of rough guideline for the counter >> values in the base draft ... > > Here is what IKEv2 has to say on this issue: > > Numbers of retries and lengths of timeouts are not covered in this > specification because they do not affect interoperability. It is > suggested that messages be retransmitted at least a dozen times over > a period of at least several minutes before giving up on an SA, but > different environments may require different rules. I would agree that the same applies to the base specification. Opportunistic HIP would probably have fairly aggressive timeouts and just a couple of retries (or maybe just one or zero), while in an environment where communication fails if one fails to create an HIP association it would probably make sense to continue even after reporting a problem to the upper layers. --Pekka From thomas.r.henderson@boeing.com Thu Apr 8 12:52:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 8 11:52:01 2004 Subject: [Hipsec] responding to unknown SPIs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060569@xch-nw-27.nw.nos.boeing.com> About a month ago, I queried the ipsec group about whether we should handle unknown SPIs. Below are a subset of the various responses, for=20 the benefit of those not on the ipsec list. =20 In summary, since we adopted a NOTIFY mechanism similar to IKEv2, I=20 think that it is appropriate to carry the INVALID_SPI notification=20 as a "MAY", like IKEv2 does. Petri, please see proposed modified text for the base spec, and I suggest that we can close this issue. INVALID_SPI 11 MAY be sent in a NOTIFY packet when a node receives an ESP packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. The NOTIFY may in this case be helpful for faster recovery, and possibly for debugging. Note, however, that sending ESP packets with invalid SPIs to=20 a node may constitute an attack, so an implementation sending INVALID_SPI should adopt measures such as rate limiting the=20 notifications or other filters. =20 Tom (responses from ipsec list below) > - in practice, if a reboot has occurred, won't applications have lost=20 > their context anyway in this case? What is the scenario for which a=20 > response is useful? when communications patterns are such that one side primarily initiates one-way exchanges, and the responder reboots, the initiator will keep sending with a bad SA until it times out. on the other hand, if you can get an authenticated = IPsec-level-equivalent of a TCP RST, initiator and responder can resynchronize much more = quickly. - Bill Sommerfeld I think what you do with invalid SPIs and/or resultant notifications=20 depends on a number of factors, and must be left to implementers. Since=20 such packets may represent a DoS attempt, there should be controls on=20 the receiver to prevent naive handling of packets containing invalid=20 SPIs. And in an ideal world, legitimate senders of such packets would=20 detect black holes and adapt accordingly, but this frequently does not=20 occur. I work on a wireless gateway which must support numerous vendors' IPsec=20 clients. I've seen connectivity losses that are not always detected by=20 the client, and sometimes these clients keep sending blindly. Since I=20 can detect under some circumstances whether the client is "okay" or not, = I can initiate an IKE SA to this client if appropriate. - Scott Kelly IKEv2 tests liveness with keep alive messages (which can be skipped if there is other traffic on the SA). This mechanism is reliable without INVALID_SPI notifications. There are two reasons INVALID_SPI might be useful. One is to trigger a liveness check and hence speed up recognition that a node has rebooted. The other is as a debugging aid trying to figure out what's going on if the network and/or one of the endpoints is flakey. I would expect most implementations to not bother with them. --Charlie Kaufman The INVALID_SPI message is used when your host is just rebooted, and you receive ESP packet which has unknown SPI. You could simply ignore it, and after couple of minutes or tens of minutes (depending on the configuration) the other end will notice that you are not responding to its IKE keepalives, and tear down the IKE and IPsec SAs. If instead of that you send unprotected INVALID_SPI notification, then the other end will immediately know that there might be problem, thus it can immediately send keepalive, and when you do not reply that within say 60 seconds (after 3-10 retransmits or so), then it can tear down the IKE SA and IPsec SA. After that the next packet will trigger the creation of the new IKE and IPsec SA and the connection is up and running again. - Tero Kivinen > -----Original Message----- > From: Henderson, Thomas R=20 > Sent: Wednesday, March 10, 2004 3:05 PM > To: ipsec@lists.tislabs.com; hipsec@honor.trusecure.com > Subject: [Hipsec] responding to unknown SPIs >=20 >=20 > (cross-posted for now to IPsec and HIP mailing lists). >=20 > This is a request from the HIP WG for some information from IPsec WG=20 > participants. >=20 > At last week's HIP meeting, there was some discussion on whether HIP > (which functions similar to an IPsec key management protocol) should=20 > respond to ESP packets received with an unknown SPI. =20 >=20 > Some issues raised included: > - don't IPsec key management protocols ignore these? (It was pointed > out by a participant that the latest draft of IKEv2 has support for > responding to them) > - what if multiple keying daemons (HIP, IPsec) are running on the > same box-- do both respond? > - what is the appropriate response, if there is one? (inside/outside > SA context, rate limited, request to reestablish the SA?) > - is a response dependent on whether the localhost determines that > it has rebooted recently? > - in practice, if a reboot has occurred, won't applications have lost=20 > their context anyway in this case? What is the scenario for which a=20 > response is useful? >=20 > In looking at the latest draft (below), it seems that IKEv2 MAY > respond, either within the SA context or outside, to these=20 > unknown SPIs, but there is not much further guidance given. >=20 > In summary, at the HIP WG it was not clear if this was a useful > mechanism, so we decided to defer to IPsec WG for guidance. Has > it been found to be useful? >=20 > Thanks, > Tom >=20 >=20 > From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt >=20 > INVALID_SPI 11 >=20 > MAY be sent in an IKE INFORMATIONAL Exchange when a node > receives an ESP or AH packet with an invalid SPI. The > Notification Data contains the SPI of the invalid packet. > This usually indicates a node has rebooted and=20 > forgotten an > SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the > recipient as a "hint" that something might be=20 > wrong (because > it could easily be forged). >=20 From thomas.r.henderson@boeing.com Thu Apr 8 13:14:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 8 12:14:01 2004 Subject: [Hipsec] API and LSI resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406056C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, March 28, 2004 8:22 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] API and LSI resolution >=20 >=20 > Nits below: >=20 > > The LSIs MUST be allocated from the 1.0.0.0/8 subnet. =20 > That makes it > > easier to differentiate between LSIs and IPv4 addresses=20 > at the API > > level. The low order 24 bits of an LSI MUST be equal to the low > > order 24 bits of the corresponding HIT. >=20 > I think that we want to say either: >=20 > a) The default low order 24 bits of an LSI MUST be equal..., or > b) The low order 24 bits of an LSI SHOULD be equal.... >=20 > Otherwise we seem to be painting ourselves into a corner. I agree, suggest "By default, the low order 24 bits of an LSA are equal to the low order 24 bits of the corresponding HIT." (this would need to be changed in -10 draft). The IANA issue on the first sentence remains an open issue. Tom From shep@alum.mit.edu Thu Apr 8 14:37:00 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Thu Apr 8 13:37:00 2004 Subject: [Hipsec] responding to unknown SPIs In-Reply-To: Your message of Thu, 08 Apr 2004 09:37:03 -0700. <6938661A6EDA8A4EA8D1419BCE46F24C04060569@xch-nw-27.nw.nos.boeing.com> Message-ID: It seems to me that the question of what to do when a host has both an IKE or IKEv2 implementation running on it, and also a HIP implementation, should both the HIP and IKE{,v2} implementations each send their own kind of invalid SPI notifications? It also seems that if IKE and HIP are to coexist on the same computer, then there will need to be some mechanism to coordinate the assignment of SPIs. Maybe IKE{,v2} and HIP should be implemented in the same daemon. Maybe we should just extend IKEv2 to do what we need for HIP that IKEv2 does not already do, and then call it IKEv2+HIP or IKEv3.. I'm just thinking out loud here. -Tim Shepard shep@alum.mit.edu From jonwood@speakeasy.net Thu Apr 8 21:38:00 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Apr 8 20:38:00 2004 Subject: [Hipsec] Cookie Proposal In-Reply-To: <40753544.80502@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406055B@xch-nw-27.nw.nos.boeing.com> <40753544.80502@nomadiclab.com> Message-ID: Looks good to me - I'm OK with the K being included in the signature. One comment inline: On Apr 8, 2004, at 4:19 AM, Petri Jokela wrote: > Pekka Nikander wrote: > > > So, shortly: > > - I will be left out from the signature > - K will be included in the signature > - Birthday will remain in COOKIE TLVs in any case > - Opaque field will be added to the COOKIE TLVs > The Opaque field is left out out the signature in the COOKIE_REQUEST. Pekka and Tom - thanks for spending some cycles thinking about this. Jon From thomas.r.henderson@boeing.com Fri Apr 9 22:32:28 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Apr 9 21:32:28 2004 Subject: [Hipsec] Rendezvous server Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060577@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Tuesday, April 06, 2004 11:48 PM > To: Tim Shepard > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Rendezvous server=20 >=20 >=20 >=20 > An alternative would be to add an unprotected FROM to the > I1, let the responder answer back to the RSV, and let the > R1 carry a TO parameter, letting the RSV to pass the R1 > back to the original initiator. No triangular routing, > no worries about amplification or reflection. >=20 I wonder whether, generally, this will be needed anyway for middlebox traversal-- consider rendezvous server in domain C for a mobile host in domain B which a corresponding host in domain A wants to talk to-- the boxes traversed from A-C-B may be different than the boxes from B-A. Then, as Tim alluded to, the I2/R2 exchange sets up the state between B and A middleboxes, while the R1 uses the binding established by I1 (or as Tim suggested, if there is already an IPsec association between Rendezvous Server and mobile host, then that could be used for R1 as well). But does this then degenerate to loose source record route at the HIP layer I1/R1 for the case of cascading RSVs? Tom From thomas.r.henderson@boeing.com Sat Apr 10 15:33:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Apr 10 14:33:00 2004 Subject: [Hipsec] Cookie Proposal Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060579@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Thursday, April 08, 2004 2:20 AM > To: > Cc: Henderson, Thomas R; Jonathan Wood > Subject: Re: [Hipsec] Cookie Proposal >=20 >=20 > Finally, due to the desire to make it possible for Alice > to make a difference between a replayed and fresh R1s, > I think that we need to retain the birthday parameter > even if we remove resynchronization out of the base spec, > and even make it stronger. Basically, it seems to me best > to increment birthday count whenever old R1s are not > accepted any more. This is apparently a change to the > current draft, and therefore probably requires opening > a new issue. [Petri, please.] >=20 What are the rules for processing multiple R1s? If we include a counter in the R1s, should a responder then accept a new R1 and start over again, when it receives an R1 while in state I2-sent and the R1 counter is higher? Once a host does not have any association anymore with=20 another host, should it be required to flush all state=20 associated with its peer's birthday count? A general=20 problem that I foresee that we want to make sure we don't=20 fall prey to is when, for some reason, a host's (supposedly=20 non-volatile) birthday counter is wiped clean (e.g., OS=20 reinstallation?), we want to make sure that we don't block=20 that host from connecting to other hosts because of its=20 restarted birthday count. An alternative for now would be to not worry about the R1 replay vulnerability, which doesn't look that severe=20 (we could add it later as a new non-critical R1 parameter). Tom From pekka.nikander@nomadiclab.com Sun Apr 11 02:17:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Apr 11 01:17:01 2004 Subject: [Hipsec] Birthday/R1 counter (was Re: Cookie Proposal) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060579@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060579@xch-nw-27.nw.nos.boeing.com> Message-ID: <6F0A883A-8B7E-11D8-B6D5-000393CE1E8C@nomadiclab.com> >> Finally, due to the desire to make it possible for Alice >> to make a difference between a replayed and fresh R1s, >> I think that we need to retain the birthday parameter >> even if we remove resynchronization out of the base spec, >> and even make it stronger. Basically, it seems to me best >> to increment birthday count whenever old R1s are not >> accepted any more. This is apparently a change to the >> current draft, and therefore probably requires opening >> a new issue. [Petri, please.] > > What are the rules for processing multiple R1s? If we > include a counter in the R1s, should a responder then > accept a new R1 and start over again, when it receives > an R1 while in state I2-sent and the R1 counter is higher? If you were speaking about I1-sent, or the (unnamed) sub-state when the initiator is still solving the puzzle, and if the new-counter > (old-counter+1), then I would say yes. What comes to I2-sent, I don't know. If the new-counter is clearly higher than the old-counter, i.e. new-counter > (old-counter + 2..3), then starting over might be a good optimisation. The details need to be worked out, and care must be taken with various border conditions like packets crossing in the network, both initiating at the same time, etc. Things depend also on whether you verify the responder's signature in R1 before you start solving the puzzle or whether you defer signature verification only to those cases where #K is high or you encounter a failure or otherwise ambiguous condition. As an initial approximation, I would probably implement it as follows: 1. Upon receiving R1, check #K. If not too high, just start solving the puzzle, without bothering with the signature. 2. If #K is high, check signature, then start solving the puzzle. 3. Upon receiving a new R1 while solving the puzzle, check the signature in that R1 which has a larger R1-counter (birthday counter) value. If the signature verifies OK, check the difference in R1 counters. If that indicates that the one of the R1s is probably too old, throw the old R1 away and act accordingly. 4. Upon receiving a new R1 after solving the puzzle (i.e. while in I2-sent), do roughly the same as in case #3. > Once a host does not have any association anymore with > another host, should it be required to flush all state > associated with its peer's birthday count? Well, I think it SHOULD forget about the birthday counter, but that it MAY also store it. A policy issue. You probably do want to store the birthday counter of your very-important-server, but not the birthday counter of the zillions of web sites you visit. > A general > problem that I foresee that we want to make sure we don't > fall prey to is when, for some reason, a host's (supposedly > non-volatile) birthday counter is wiped clean (e.g., OS > reinstallation?), If a host looses its birthday count, it probably looses its private key, too. If someone reinstalls the private key, they can probably also reset the birthday counter into some sensible value. (Of course, this does not apply to some very small devices that have ROM but not NVRAM etc.; see below.) This apparently needs to be documented under operational considerations. Should we have a separate section about operational considerations? Or even a separate draft? > we want to make sure that we don't block > that host from connecting to other hosts because of its > restarted birthday count. Right. That's the reason for the aforementioned "SHOULD forget". > An alternative for now would be to not worry about the R1 > replay vulnerability, which doesn't look that severe > (we could add it later as a new non-critical R1 parameter). I think the birthday count parameter could be non-critical from the very beginning, allowing implementations to ignore it. Anyway, its purpose is to protect the initiator from some replay attacks, and if the initiator does not want to have that protection, it is not exactly a protocol concern. Of course, for the sake of devices that have only ROM but not NVRAM, we could define that including the birthday count in R1 is RECOMMENDED but not MANDATORY. --Pekka From pekka.nikander@nomadiclab.com Sun Apr 11 02:49:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Apr 11 01:49:00 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060577@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060577@xch-nw-27.nw.nos.boeing.com> Message-ID: >> An alternative would be to add an unprotected FROM to the >> I1, let the responder answer back to the RSV, and let the >> R1 carry a TO parameter, letting the RSV to pass the R1 >> back to the original initiator. No triangular routing, >> no worries about amplification or reflection. > > I wonder whether, generally, this will be needed anyway > for middlebox traversal-- consider rendezvous server in domain > C for a mobile host in domain B which a corresponding host > in domain A wants to talk to-- the boxes traversed from > A-C-B may be different than the boxes from B-A. Then, > as Tim alluded to, the I2/R2 exchange sets up the state > between B and A middleboxes, while the R1 uses the > binding established by I1. Maybe so. Depends on network configuration. In general, I think that on the protocol level we should aim towards not unnecessarily blocking some configurations, and leaving the details for operational considerations. That is, aiming simultaneously towards simplicity and flexibility. Thinking more about this, what if the FROM parameter includes an opaque blob that the RSV can use to route back the R1 to the sender of I1? Consider the following: 1. Init, at A_I, sends an I1 to the RSV, at A_RSV. In I1, src=A_I and dst=A_RSV 2. The RSV processes the packet, and determines A_R. It adds FROM to I1, and forwards it. In I1, src=A_SRV and dst=A_R. In FROM, from=A_I, hmac=HMAC(K_R,RSV; A_I, I1), and blob=HMAC(K_RSV; A_I, HIT_I, HIT_R) 3. If the Responder policy is to answer back via the RSV, it sends an R1 to the RSV: In R1, src=A_R and dst=A_RSV In TO, to=A_I, hmac=HMAC(K_R,RSV, A_I, R1), and blob=copied from I1 4. If the Responder policy is to answer directly to the Initiator, it sends an R1 to the Initiator: In R1, src=A_R and dst=A_I In VIA, via=A_RSV, and blob=copied from I1 where K_R,RSV is a shared secret between the Responder and the RSV, K_RSV is a symmetric key known only to the RSV FROM, TO, VIA are new parameters to be defined. Would that be a good approximation that would support both scenarios (R->RSV->I and R->I) while still having enough information for operational diagnosis? On the other hand, it might also be a good idea to consider some ideas from SOS (Secure Overlay Service by Keromytis et al) or Secure-I3 (by Atkins, Stoica et al.). In other words, in some cases it might be a good idea to _prevent_ the initiator from knowing the responders IP address until R2. > (or as Tim suggested, if there > is already an IPsec association between Rendezvous Server > and mobile host, then that could be used for R1 as well). As I already said, I think passing both I1 and R! over existing ESP SAs is a good MAY, but not good as the default behaviour. Further, passing *both* I1 and R1 is better than just passing I1. > But does this then degenerate to loose source record route > at the HIP layer I1/R1 for the case of cascading RSVs? Yes it does. It also may be engineered to make HIP RSVs to behave more like I3. In either case, the security issues seem to be tricky, and depend on the goals. Finding the right balance between simplicity and flexibility seems to get, hmm, difficult... Combine this with the desire of supporting LHIP, and we get an interesting problem... --Pekka From Julien.Laganier@Sun.COM Tue Apr 13 04:51:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Apr 13 03:51:00 2004 Subject: [Hipsec] responding to unknown SPIs In-Reply-To: References: Message-ID: <200404131038.48366.julien.laganier@sun.com> On Thursday 08 April 2004 20:18, Tim Shepard wrote: > It seems to me that the question of what to do when a host has both > an IKE or IKEv2 implementation running on it, and also a HIP > implementation, should both the HIP and IKE{,v2} implementations > each send their own kind of invalid SPI notifications? In case they do, it doesn't cause that much harm... For example, one side reboot, then it receives a ESP packet with unknown SPI. Both HIP and IKEv2 implementations send an "invalid SPI" notification, and both HIP and IKEv2 running on the receiver get them: o If this was a HIP-related ESP packet, the IKEv2 implementation wouldn't know anything about this SPI, hence should discard the notification, while the HIP implementation would have an associated state and answer conveniently. o If this was a IKEv2-related ESP packet, the reverse apply as well. > It also seems that if IKE and HIP are to coexist on the same > computer, then there will need to be some mechanism to coordinate > the assignment of SPIs. The mechanisms is already implemented in all the IPsec stacks I know about (*BSD/KAME, Linux and Solaris), through the use of the PFKEY_V2 API. A key management daemon should first send to the IPsec stack an SADB_GETSPI, in order to allocate an SA and a free SPI, and then use SADB_UPDATE to fill-in others SA parameters (peers, alg, keys). > Maybe IKE{,v2} and HIP should be implemented in the same daemon. > > Maybe we should just extend IKEv2 to do what we need for HIP that > IKEv2 does not already do, and then call it IKEv2+HIP or IKEv3.. Indeed, this can be an interesting option... IKEv2 is 2 round trips long for ESP/AH SA creation so it compares quite well with HIP. But anyway, HIP over IKEv2 need some extensions (at least for Rendez-Vous Server) that we do need to speficy to really know if this is possible. Also, this sounds like a bit of regression because it means that we need to throw away some of the specification and implementation work that already happened. BTW I dunno if there's running implemenation of IKEv2... anybody? --julien From petri.jokela@nomadiclab.com Tue Apr 13 07:52:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Apr 13 06:52:01 2004 Subject: [Hipsec] responding to unknown SPIs In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060569@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060569@xch-nw-27.nw.nos.boeing.com> Message-ID: <407BD128.4060403@nomadiclab.com> Henderson, Thomas R wrote: > In summary, since we adopted a NOTIFY mechanism similar to IKEv2, I > think that it is appropriate to carry the INVALID_SPI notification > as a "MAY", like IKEv2 does. > > Petri, please see proposed modified text for the base spec, and I > suggest that we can close this issue. > > INVALID_SPI 11 > > MAY be sent in a NOTIFY packet when a node receives an ESP > packet with an invalid SPI. The Notification Data contains > the SPI of the invalid packet. This usually indicates a node > has rebooted and forgotten an SA. The NOTIFY may in this case > be helpful for faster recovery, and possibly for debugging. > Note, however, that sending ESP packets with invalid SPIs to > a node may constitute an attack, so an implementation sending > INVALID_SPI should adopt measures such as rate limiting the > notifications or other filters. Thanks Tom! So, we shall remove all current definitions and mechanisms how to respond to unknown SPIs and define that the response MAY be a NOTIFY packet with an INVALID_SPI. How to react to an incoming INVALID_SPI would depend fully on the implementation and no rules shall be defined for it. There were some issues bundled together, namely issues 12, 15, 19, 20 and 22. The issue 12, birthday check badly defined, was subject of removal if the resync would have been removed from the draft. Now, the new COOKIE (issue 33) would contain the birthday in any case, so this issue is now related to this issue 33 and not yet closed. The issue 15, the possible removal of birthday count, is not valid after the introduction of the new COOKIE with birthday. Thus I suggest that this issue will be closed. The issue 19, RESYNC bit in I1, is now resolved by introducing the UNKNOWN_SPI in the NOTIFY packet. So, this issue could be closed. The issue 20, I1 and R1 packet definition bug, can be closed if we remove all the defined actions for responding to unknown SPIs with I1/R1 packets. The issue 22, Remove RESYNC mechanism from the draft, would be closed as proposed by Tom. /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 miika@iki.fi Tue Apr 13 07:55:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Apr 13 06:55:01 2004 Subject: [Hipsec] responding to unknown SPIs In-Reply-To: References: Message-ID: On Thu, 8 Apr 2004, Tim Shepard wrote: > It also seems that if IKE and HIP are to coexist on the same computer, > then there will need to be some mechanism to coordinate the assignment > of SPIs. > > Maybe IKE{,v2} and HIP should be implemented in the same daemon. This would be quite interesting because our HIP implementation does not have any userspace daemon ;) It runs entirely in the kernelspace. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From thomas.r.henderson@boeing.com Tue Apr 13 12:20:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 13 11:20:01 2004 Subject: [Hipsec] responding to unknown SPIs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Tuesday, April 13, 2004 4:38 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] responding to unknown SPIs >=20 >=20 > Now, the new COOKIE=20 > (issue 33) would contain the birthday in any case, so this=20 > issue is now=20 > related to this issue 33 and not yet closed. >=20 I recall that there was originally discussion about separating the birthday and cookie parameters. However, it seems that now, in either case that birthday is needed (resync or R1 replay avoidance), it is needed in R1, so it seems reasonable to=20 bind these (separate birthday TLV could be created if needed in the future). So I am fine with the new cookie format=20 (issue 33). one small typo-- in 6.2.4, K is not a 64-bit integer also, I suggest defining in COOKIE_REQUEST Opaque optional field, set by responder and padded to 32-bit boundary and in COOKIE_RESPONSE Opaque echoed to responder if Opaque field was included in the R1 COOKIE_REQUEST (since I don't think we need to explicitly show a padding field if we force Opaque to be 32-bit aligned). Finally, it is not clear in the proposed text in issue 33, but Opaque and I are both left out of the signature. From petri.jokela@nomadiclab.com Wed Apr 14 06:26:03 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Apr 14 05:26:03 2004 Subject: [Hipsec] responding to unknown SPIs In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing.com> Message-ID: <407D0E8B.6080704@nomadiclab.com> Henderson, Thomas R wrote: > also, I suggest defining in COOKIE_REQUEST > > Opaque optional field, set by responder and padded to 32-bit > boundary > > and in COOKIE_RESPONSE > > Opaque echoed to responder if Opaque field was included in > the R1 COOKIE_REQUEST > > (since I don't think we need to explicitly show a padding field > if we force Opaque to be 32-bit aligned). In REQUEST, this would go nicely. The RESPONSE requires 4-byte padding to meet the 8-byte alignment requirement when the Opaque field is copied from the REQUEST. It might be better in that case to define a 4-byte reserved field in the RESPONSE, instead of adding 4-byte padding each time: COOKIE_RESPONSE: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > Finally, it is not clear in the proposed text in issue 33, but > Opaque and I are both left out of the signature. There will be text modifications in sections 7 and 8 that will cover also these. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Thu Apr 15 04:38:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 03:38:03 2004 Subject: [Hipsec] A separate ECHO_REQUEST / ECHO_RESPONSE parameter? (was Re: responding to unknown SPIs In-Reply-To: <407D0E8B.6080704@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing.com> <407D0E8B.6080704@nomadiclab.com> Message-ID: Petri and others, The ability to send opaque data and get it back seems to be useful for more than one purposes. So far we have at least two distinct purposes: - For cookies, to include some state in R1 so that it gets echoed back in I2 - For RSV, to include some state in I1 so that it gets echoed back in R1. Hence, I would suggest making this opaque data echo back service a separate parameter, and put it after the SIG. For the TLV table: ECHO_REQUEST 65281 variable Opaque data to be echoed back ECHO_RESPONSE 65283 variable Opaque data echoed back For the actual text: The ECHO_REQUEST parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet. The ECHO_RESPONSE parameter contains the echoed back data. The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. Note that ECHO_REQUEST and ECHO_RESPONSE parameters are not covered by the HMAC or SIGNATURE. It is currently defined how to use the ECHO parameters for extended COOKIES, see Section XXX. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque data (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65281 or 65283 Length variable Opaque data Opaque data, supposed to be meaningful only to the node that sends ECHO_REQUEST and receives a corresponding ECHO_RESPONSE. --Pekka From pekka.nikander@nomadiclab.com Thu Apr 15 04:52:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 03:52:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters Message-ID: To make the protocol more modular and simpler in some sense, I would suggest splitting the COOKIE parameters into separate BIRTHDAY, PUZZLE and SOLUTION parameters. Here is the proposed text: BIRTHDAY The BIRTHDAY parameter contains an 96-bit unsigned integer, indicating the current generation of valid puzzles. The sender is supposed to increment the Birthday value periodically. It is RECOMMENDED that the Birthday value is incremented at least as often as old PUZZLE values are deprecated so that SOLUTIONs to them are no more accepted. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 12 bytes | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A question: Should we have separately a sender BIRTHDAY and receiver BIRTHDAY parameters? I don't remember any more how the semantics were defined in the current draft, but to me it makes more sense to send the sender's birthday. However, for the puzzle solution processing it MAY be useful to include the responder's birthday in I2. However, now that we have the Opaque field/parameter, the birthday's role is more reverted to replay protection for the receiver of the birthday than for information for the (stateless) responder when receiving I2. Opinions? PUZZLE The PUZZLE parameter contains the puzzle difficulty K and an 64-bit puzzle random integer #I. A puzzle MAY be augmented by including an ECHO_REQUEST parameter to an R1. The contents of the ECHO_REQUEST are then echoed back in ECHO_RESPONSE, allowing the Responder to use the included information as a part of puzzle processing. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SOLUTION The SOLUTION parameter contains a solution to a puzzle. It also echoes back the random difficulty K and the puzzle integer #I. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Question: Do we need to echo back K and #I now that we have the Opaque field/parameter? The required information could as easily be stored there? --Pekka From pekka.nikander@nomadiclab.com Thu Apr 15 04:56:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 03:56:00 2004 Subject: [Hipsec] A separate ECHO_REQUEST / ECHO_RESPONSE parameter? (was Re: responding to unknown SPIs In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing.com> <407D0E8B.6080704@nomadiclab.com> Message-ID: <614E0196-8EB9-11D8-B6D5-000393CE1E8C@nomadiclab.com> > For the TLV table: > > ECHO_REQUEST 65281 variable Opaque data to be echoed back > ECHO_RESPONSE 65283 variable Opaque data echoed back Silly for me to reply to myself, but apparently it would make more sense to have the ECHO_REQUEST always after the signature, but allow the ECHO_RESPONSE to be included also before the signature. Hence, we would have something like: ECHO_RESPONSE 1024 variable Opaque data echoed back; under signature ECHO_REQUEST 65281 variable Opaque data to be echoed back ECHO_RESPONSE 65283 variable Opaque data echoed back; after signature More specifically, for the I2 processing it might be better to have the ECHO_RESPONSE signed by the Initiator. (That doesn't help early in the process since the Responder can't check the Initiator's signature but much later, but it gives some more assurance once everything has been completed. Hence, even though the I2 ECHO_RESPONSE would be protected by the Initiator's signature, it should still be protected by the Responder using a symmetric key.) Maybe we should allow the same for ECHO_REQUEST, too, just for the sake of symmetry? --Pekka From Gonzalo.Camarillo@ericsson.com Thu Apr 15 06:22:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Apr 15 05:22:01 2004 Subject: [Hipsec] Milestone status Message-ID: <407E5FA9.8020702@ericsson.com> Folks, we are missing some of our milestones, and we do not want this to happen. In any event, being one month behind is not a big deal, as long as we are aware of it and take the necessary actions. I expect the needed commitment from the persons responsible for each of the documents so that we can go back to our planned schedule. These are the milestones we should be looking at: 1) Mar 04 WG LC on the base protocol specification 2) Mar 04 First version of the HIP basic mobility and multi-homing mechanism specification. 3) Mar 04 First version of the HIP DNS resource record(s) specification. 4) Apr 04 Complete the base protocol specification and submit it to the IESG for Experimental 5) Apr 04 First version of the HIP basic rendezvous mechanism specification. 1) there are still a number of open issues in the base spec: removing the resync stuff, the R2-lost problem, and rewriting of the ESP section. We need to focus on them to be able to have a stable enough spec so that it can be WGLCed. 2) We already have Pekka's MM draft. Does anybody object to taking this draft as a WG item for the MM milestone? 3) Julien has agreed to release an initial version of the DNS draft at the beginning of May. 4) We need to finish the base spec and WGLC it before being able to send it for consideration to the IESG. 5) Julien has agreed to release an initial version of the rendezvous draft at the end of April or the beginning of May. Regards, Gonzalo HIP co-chair From pekka.nikander@ericsson.com Thu Apr 15 07:04:03 2004 From: pekka.nikander@ericsson.com (Pekka Nikander) Date: Thu Apr 15 06:04:03 2004 Subject: [Hipsec] Re: Milestone status In-Reply-To: <407E5FA9.8020702@ericsson.com> References: <407E5FA9.8020702@ericsson.com> Message-ID: > 2) Mar 04 First version of the HIP basic mobility and multi-homing > mechanism specification. > > 2) We already have Pekka's MM draft. Does anybody object to taking > this draft as a WG item for the MM milestone? Tom H. has promised to produce a next version. I would suggest that we wait for that version and adopt that draft. Tom, have you got any idea of when you would have the version available? --Pekka From hannes.tschofenig@siemens.com Thu Apr 15 07:07:04 2004 From: hannes.tschofenig@siemens.com (Tschofenig Hannes) Date: Thu Apr 15 06:07:04 2004 Subject: [Hipsec] Milestone status Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> hi all, you mention the hip rendezvous mechanism. what about the draft recently published by lars? ciao hannes > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Thursday, April 15, 2004 12:11 PM > To: hipsec@honor.trusecure.com > Cc: David Ward; Pekka Nikander (JO/LMF); Lars Eggert; Julien Laganier; > Petri Jokela (JO/LMF) > Subject: [Hipsec] Milestone status > > > Folks, > > we are missing some of our milestones, and we do not want this to > happen. In any event, being one month behind is not a big > deal, as long > as we are aware of it and take the necessary actions. I expect the > needed commitment from the persons responsible for each of > the documents > so that we can go back to our planned schedule. > > These are the milestones we should be looking at: > > 1) Mar 04 WG LC on the base protocol specification > 2) Mar 04 First version of the HIP basic mobility and multi-homing > mechanism specification. > 3) Mar 04 First version of the HIP DNS resource record(s) > specification. > 4) Apr 04 Complete the base protocol specification and > submit it to the > IESG for Experimental > 5) Apr 04 First version of the HIP basic rendezvous mechanism > specification. > > > > 1) there are still a number of open issues in the base spec: removing > the resync stuff, the R2-lost problem, and rewriting of the > ESP section. > We need to focus on them to be able to have a stable enough > spec so that > it can be WGLCed. > > 2) We already have Pekka's MM draft. Does anybody object to > taking this > draft as a WG item for the MM milestone? > > 3) Julien has agreed to release an initial version of the DNS > draft at > the beginning of May. > > 4) We need to finish the base spec and WGLC it before being > able to send > it for consideration to the IESG. > > 5) Julien has agreed to release an initial version of the rendezvous > draft at the end of April or the beginning of May. > > Regards, > > Gonzalo > HIP co-chair > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From Julien.Laganier@Sun.COM Thu Apr 15 07:20:02 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Apr 15 06:20:02 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060577@xch-nw-27.nw.nos.boeing.com> Message-ID: <200404151346.07875.julien.laganier@sun.com> Hi Pekka, Please find more thoughts below: On Sunday 11 April 2004 08:38, Pekka Nikander wrote: > >> An alternative would be to add an unprotected FROM to the > >> I1, let the responder answer back to the RSV, and let the > >> R1 carry a TO parameter, letting the RSV to pass the R1 > >> back to the original initiator. No triangular routing, > >> no worries about amplification or reflection. > > > > I wonder whether, generally, this will be needed anyway > > for middlebox traversal-- consider rendezvous server in domain > > C for a mobile host in domain B which a corresponding host > > in domain A wants to talk to-- the boxes traversed from > > A-C-B may be different than the boxes from B-A. Then, > > as Tim alluded to, the I2/R2 exchange sets up the state > > between B and A middleboxes, while the R1 uses the > > binding established by I1. > > Maybe so. Depends on network configuration. In general, > I think that on the protocol level we should aim towards > not unnecessarily blocking some configurations, and leaving > the details for operational considerations. That is, aiming > simultaneously towards simplicity and flexibility. > > Thinking more about this, what if the FROM parameter includes > an opaque blob that the RSV can use to route back the R1 > to the sender of I1? Consider the following: > > 1. Init, at A_I, sends an I1 to the RSV, at A_RSV. > In I1, src=A_I and dst=A_RSV > > 2. The RSV processes the packet, and determines A_R. > It adds FROM to I1, and forwards it. > In I1, src=A_SRV and dst=A_R. > In FROM, from=A_I, hmac=HMAC(K_R,RSV; A_I, I1), and > blob=HMAC(K_RSV; A_I, HIT_I, HIT_R) > > 3. If the Responder policy is to answer back via the > RSV, it sends an R1 to the RSV: > In R1, src=A_R and dst=A_RSV > In TO, to=A_I, hmac=HMAC(K_R,RSV, A_I, R1), and > blob=copied from I1 > > 4. If the Responder policy is to answer directly to > the Initiator, it sends an R1 to the Initiator: > In R1, src=A_R and dst=A_I > In VIA, via=A_RSV, and blob=copied from I1 > > where > > K_R,RSV is a shared secret between the Responder and the > RSV, > > K_RSV is a symmetric key known only to the RSV > > FROM, TO, VIA are new parameters to be defined. > > Would that be a good approximation that would support both > scenarios (R->RSV->I and R->I) while still having enough > information for operational diagnosis? I like this proposal. > On the other hand, it might also be a good idea to consider > some ideas from SOS (Secure Overlay Service by Keromytis et al) > or Secure-I3 (by Atkins, Stoica et al.). In other words, in > some cases it might be a good idea to _prevent_ the initiator > from knowing the responders IP address until R2. If both I1 and R1 are passing through the RVS, it's straightforward to hide to the Initiator the Responder's IP address until R2: The Initiator will get an R1 coming from the RVS's IP address in answer to an I1 sent to the RVS's IP address. I RVS R ------(I1)------> --(I1:From I)--> <-----(I1)------- <--(R1:To I)---- ------(I2)------> --(I2:From I)--> <----------(R2:Via RVS)----------- Furthermore, if there's two (or more) cascaded RVS, the initiator will ignore even the secondth RVS's IP address until it receives R2, and the first RVS will ignore the Responder's IP address: I RVS_1 RVS_2 R ------(I1)------> --(I1:From I)--> -----(I1:From I:From RVS_1)--> <-----(I1)------- <--(R1:To I)---- <----(I1:To I:To RVS_1)------- ------(I2)------> --(I2:From I)--> -----(I2:From I:From RVS_1)--> <-------------------(R2:Via RVS_1: Via RVS_2)-------------------- > > (or as Tim suggested, if there > > is already an IPsec association between Rendezvous Server > > and mobile host, then that could be used for R1 as well). > > As I already said, I think passing both I1 and R! over > existing ESP SAs is a good MAY, but not good as the default > behaviour. Further, passing *both* I1 and R1 is better > than just passing I1. Wether only I1 or both I1 and R1 should be passed through an existing ESP SA between the RVS and the Responder should be a policy choice. If a responder want to hide its IP address until it gets I2, then both should passed over the SA. If a responder doesn't want to hide its IP address, then it is ok to pass just the I1. > > But does this then degenerate to loose source record route > > at the HIP layer I1/R1 for the case of cascading RSVs? > > Yes it does. It also may be engineered to make HIP RSVs > to behave more like I3. In either case, the security > issues seem to be tricky, and depend on the goals. Finding > the right balance between simplicity and flexibility seems > to get, hmm, difficult... Combine this with the desire of > supporting LHIP, and we get an interesting problem... Talking about I3, the triggers (i.e., in HIP terminology, an association between a Responder and a RVS, or Rendez-Vous Association == RVA) are tuple or . In HIP, a RVA is a tuple (i.e., ). So I am not sure to really understand what you mean; Do you just mean that we should be able to cascade RVS, or do you mean that we should be able to handle RVA of the form (i.e., )? BTW, Below is a strawman proposal for FROM, TO and VIA parameters, based on your proposal of having opaque blobs: _________________________________________________________________ FROM: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | HMAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | BLOB | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65400 Length 56 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. HMAC 160 low order bits of the HMAC keyed with a symetric key shared between the Responder and the Rendez-Vous Server, computed over the HIP packet, including the Type, Length and Address fields of the FROM parameter, and excluding the HMAC and BLOB fields. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. BLOB 160 low order bits of the a HMAC keyed with a symetric key chosen by the Rendez-Vous Server, computed over the Address field, and the Initiator and Responder HITs of the HIP packet. TO: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | HMAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | BLOB | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65402 Length 56 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. HMAC 160 low order bits of the HMAC keyed with a symetric key shared between the Responder and the Rendez-Vous Server, computed over the HIP packet, including the Type, Length and Address fields of the TO parameter, and excluding the HMAC and BLOB fields. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. BLOB 160 low order bits of the a HMAC keyed with a symetric key chosen by the Rendez-Vous Server, computed over the Address field, and the Initiator and Responder HITs of the HIP packet. VIA: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 70 Length 16 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. _________________________________________________________________ Any thoughts whelcomed; Tnx. --julien From Julien.Laganier@Sun.COM Thu Apr 15 07:28:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Apr 15 06:28:01 2004 Subject: [Hipsec] Milestone status In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> Message-ID: <200404151353.21587.julien.laganier@sun.com> On Thursday 15 April 2004 12:55, Tschofenig Hannes wrote: > hi all, > > you mention the hip rendezvous mechanism. what about the draft > recently published by lars? > I believe the plan is to produce a "I1-forwarding only rendez-vous mechanism" draft for the HIP WG, while the "HIP to non-HIP rendez-vous mechanism" draft will be targeted at the RG. Both drafts will use the original "HIP rendez-vous mechanism" recently published by Lars as a starting point. Thanks, --julien > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: Thursday, April 15, 2004 12:11 PM > > To: hipsec@honor.trusecure.com > > Cc: David Ward; Pekka Nikander (JO/LMF); Lars Eggert; Julien > > Laganier; Petri Jokela (JO/LMF) > > Subject: [Hipsec] Milestone status > > > > > > Folks, > > > > we are missing some of our milestones, and we do not want this to > > happen. In any event, being one month behind is not a big > > deal, as long > > as we are aware of it and take the necessary actions. I expect > > the needed commitment from the persons responsible for each of > > the documents > > so that we can go back to our planned schedule. > > > > These are the milestones we should be looking at: > > > > 1) Mar 04 WG LC on the base protocol specification > > 2) Mar 04 First version of the HIP basic mobility and > > multi-homing mechanism specification. > > 3) Mar 04 First version of the HIP DNS resource record(s) > > specification. > > 4) Apr 04 Complete the base protocol specification and > > submit it to the > > IESG for Experimental > > 5) Apr 04 First version of the HIP basic rendezvous mechanism > > specification. > > > > > > > > 1) there are still a number of open issues in the base spec: > > removing the resync stuff, the R2-lost problem, and rewriting of > > the ESP section. > > We need to focus on them to be able to have a stable enough > > spec so that > > it can be WGLCed. > > > > 2) We already have Pekka's MM draft. Does anybody object to > > taking this > > draft as a WG item for the MM milestone? > > > > 3) Julien has agreed to release an initial version of the DNS > > draft at > > the beginning of May. > > > > 4) We need to finish the base spec and WGLC it before being > > able to send > > it for consideration to the IESG. > > > > 5) Julien has agreed to release an initial version of the > > rendezvous draft at the end of April or the beginning of May. > > > > Regards, > > > > Gonzalo > > HIP co-chair From lars.eggert@netlab.nec.de Thu Apr 15 07:35:05 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Apr 15 06:35:05 2004 Subject: [Hipsec] Milestone status In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> Message-ID: <407E70D2.6030404@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms080905010609090706070601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hannes, Tschofenig Hannes wrote: > > you mention the hip rendezvous mechanism. what about the draft recently > published by lars? Julien Laganier and me will turn part of that into an I1-only draft, and I plan to turn the remaining pieces into a more general rendezvous document targetted at the RG. Lars PS: Tom, you mentioned that someone from Boeing may be interested in collaborating on that RG draft? Is this still the case? -- Lars Eggert NEC Network Laboratories --------------ms080905010609090706070601 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDE1MTEyNDAyWjAjBgkqhkiG 9w0BCQQxFgQUyPchZNUYCS/hpd3Oz2XeuE4k/sAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA g5pnky7s1BKLWUKF04Yy5dCVold5j/JFaG138wZ3MrjW36snNCUC2L+XAT+cyGuQ7UsoHOkz ektYvCbrXkQmJsI6j4rgA2zKhQO139i/CuwALdpAVpRfw8leod/UJZmQ3AVaggyO9h0ASWbl W9I00tLVbHkm6rugGGV2vWWw27PxiKBtK1ZqWKjygpMD0hXoZMzXGdgUR62QnmMkJ6xy1rYh aMeolPFuUcgAhUlj6wbn90mXYTBV8G65YpqB7td084lct5qX8Fv87j+2a1GHmPxP+LsHFNFa fJJMfXBm6aog2uA+B8u7h2Tjz7eA+acJWQhcJaRylxIhLvQJQwwcHAAAAAAAAA== --------------ms080905010609090706070601-- From Gonzalo.Camarillo@ericsson.com Thu Apr 15 07:39:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Apr 15 06:39:01 2004 Subject: [Hipsec] Milestone status In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F04685FFB@mchp905a.mch.sbs.de> Message-ID: <407E718B.6040705@ericsson.com> Hi, the scope of that draft is wider than what we need in the WG. Julien will be releasing a simpler draft shortly. Gonzalo Tschofenig Hannes wrote: > hi all, > > you mention the hip rendezvous mechanism. what about the draft recently > published by lars? > > > ciao > hannes > > From petri.jokela@nomadiclab.com Thu Apr 15 07:46:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 15 06:46:00 2004 Subject: [Hipsec] The order in which keys are drawn In-Reply-To: <40738F9B.8020604@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> <612369691.1081354202@[192.168.2.241]> <0B44413A-8850-11D8-9B06-00306571BE62@nomadiclab.com> <40738F9B.8020604@nomadiclab.com> Message-ID: <407E72A6.80504@nomadiclab.com> As agreed earlier, the key retrieval will be based on HIT comparison. Here is some initial new text that describes the key retrieval order for the base exchange and for rekeying. First, the key retrieval order described in 8.10 for UPDATE: --8<-- 8.10 Processing UPDATE packets When a system receives an UPDATE packet, its processing depends on whether the packet is a reply to a previously sent UPDATE packet or the UPDATE is a new packet. The order of the keys retrieved from the KEYMAT during rekeying process is similar to that described in Section 9. Note, that only IPsec ESP keys are retrieved during rekeying process, not the HIP keys. The following steps define the conceptual processing rules for handling a received UPDATE packet: --8<-- And in section 9, the new order for drawing keys, based on HIT comparison: --8<-- Sort(HIT-I | HIT-R) is defined as the network byte order concatenation of the two HITs, with the smaller HIT preceding the larger HIT, resulting from the numeric comparison of the two HITs interpreted as positive (unsigned) 128-bit integers in network byte order. The initial keys are drawn sequentially in the order that is determined by the numeric comparison of the two HITs, with comparison method described in the previous paragraph. HOST_g denotes the host with the greater HIT value, and HOST_l the host with the lower HIT value. The drawing order for initial keys: HIP-gl encryption key for HOST_g's outgoing HIP packets HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP packets HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets SA-gl ESP encryption key for HOST_g's outgoing traffic SA-gl ESP authentication key for HOST_g's outgoing traffic SA-lg ESP encryption key for HOST_l's outgoing traffic SA-lg ESP authentication key for HOST_l's outgoing traffic --8<-- /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From Julien.Laganier@Sun.COM Thu Apr 15 08:05:02 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Apr 15 07:05:02 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: References: Message-ID: <200404151353.42146.julien.laganier@sun.com> Pekka, More thoughts below, On Thursday 15 April 2004 10:42, Pekka Nikander wrote: > To make the protocol more modular and simpler in some > sense, I would suggest splitting the COOKIE parameters > into separate BIRTHDAY, PUZZLE and SOLUTION parameters. > > Here is the proposed text: > > BIRTHDAY > > The BIRTHDAY parameter contains an 96-bit unsigned integer, > indicating the current generation of valid puzzles. The > sender is supposed to increment the Birthday value periodically. > It is RECOMMENDED that the Birthday value is incremented at > least as often as old PUZZLE values are deprecated so that > SOLUTIONs to them are no more accepted. > > > > A question: Should we have separately a sender BIRTHDAY and > receiver BIRTHDAY parameters? I don't remember any more how the > semantics were defined in the current draft, but to me it makes > more sense to send the sender's birthday. However, for the puzzle > solution processing it MAY be useful to include the responder's > birthday in I2. However, now > that we have the Opaque field/parameter, the birthday's role is > more reverted to replay protection for the receiver of the birthday > than for information for the (stateless) responder when receiving > I2. > > Opinions? IMHO, this "receiver birthday" looks very similar to a "Transaction ID ", i.e., the initiator sending a "receiver birthday" in I2 is really just echoing back the "sender birthday" he just received in the R1 from the responder. So, I dunno. Perhaps we could define a "Transaction ID" (either in the base header or in a new parameter) and keep only a "sender birthday". > PUZZLE > > The PUZZLE parameter contains the puzzle difficulty K and an > 64-bit puzzle random integer #I. A puzzle MAY be augmented by > including an ECHO_REQUEST parameter to an R1. The contents > of the ECHO_REQUEST are then echoed back in ECHO_RESPONSE, > allowing the Responder to use the included information as a part of > puzzle processing. > > > > > > SOLUTION > > The SOLUTION parameter contains a solution to a puzzle. It also > echoes back the random difficulty K and the puzzle integer #I. > > > > > > > Question: Do we need to echo back K and #I now that we have the > Opaque field/parameter? The required information could as easily > be stored there? I agree that sending back K and I would be redundant information. As PUZZLE and SOLUTION are now two different parameters, I would prefer simplicity and no ambiguity, i.e., drop K and I in the SOLUTION. Thanks, --julien From pekka.nikander@nomadiclab.com Thu Apr 15 08:17:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 07:17:02 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: <200404151353.42146.julien.laganier@sun.com> References: <200404151353.42146.julien.laganier@sun.com> Message-ID: <860CD350-8ED5-11D8-AC5A-000393CE1E8C@nomadiclab.com> >> Question: Do we need to echo back K and #I now that we have the >> Opaque field/parameter? The required information could as easily >> be stored there? > > I agree that sending back K and I would be redundant information. As > PUZZLE and SOLUTION are now two different parameters, I would prefer > simplicity and no ambiguity, i.e., drop K and I in the SOLUTION. The case is not that clear cut. Using the opaque info requires you to verify its integrity first, i.e., compute at least one hash. And only after that you know if the I2 is related to any R1 that you have sent recently. On the other hand, using #I (and K) directly as an index to the right puzzle may be made very cheaply. Indeed, if you have a (too) simple implementation, you can use them just directly. (Which is, of course, unsecure.) [Afterthought: Of course, you could store just an index and a once in the opaque field, and check that the index points to the same nonce in your own data structures, but you can do that almost as easily with #I.] Hence, I would not *necessarily* be dropping #I and K from SOLUTION (if we adopt it). I think that a SOLUTION without #I and K is more aesthetic, but OTOH it is only 8 bytes more (you still need padding for #J) and leaves the implementations the possibility of not using the opaque field/parameter at all. --Pekka From pekka.nikander@nomadiclab.com Thu Apr 15 08:28:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 07:28:00 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200404151346.07875.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060577@xch-nw-27.nw.nos.boeing.com> <200404151346.07875.julien.laganier@sun.com> Message-ID: >> On the other hand, it might also be a good idea to consider >> some ideas from SOS (Secure Overlay Service by Keromytis et al) >> or Secure-I3 (by Atkins, Stoica et al.). In other words, in >> some cases it might be a good idea to _prevent_ the initiator >> from knowing the responders IP address until R2. > > If both I1 and R1 are passing through the RVS, it's straightforward to > hide to the Initiator the Responder's IP address until R2: The > Initiator will get an R1 coming from the RVS's IP address in answer > to an I1 sent to the RVS's IP address. Right. However, we can do better here. Instead of using FROM and TO, the RSV can just use ECHO_REQUEST and ECHO_RESPONSE and hide even the Initiator's address. In that case the Responder doesn't even have an option of answering directly to the Initiator. >> As I already said, I think passing both I1 and R! over >> existing ESP SAs is a good MAY, but not good as the default >> behaviour. Further, passing *both* I1 and R1 is better >> than just passing I1. > > Wether only I1 or both I1 and R1 should be passed through an existing > ESP SA between the RVS and the Responder should be a policy choice. Yes, but the draft should also be very pragmatic about the consequences of such policy choices, especially wrt. middle boxes. > Talking about I3, the triggers (i.e., in HIP terminology, an > association between a Responder and a RVS, or Rendez-Vous Association > == RVA) are tuple or . > > In HIP, a RVA is a tuple (i.e., ). > > So I am not sure to really understand what you mean; Do you just mean > that we should be able to cascade RVS, or do you mean that we should > be able to handle RVA of the form (i.e., )? I don't know. I'm still struggling in trying to understand the similarities and differences between I3 and HIP. > BLOB A point is that the blob is opaque, just like in the ECHO_REQUEST and ECHO_RESPONSE. Any BLOB in FROM is just echoed back in TO. An important issue is that any packet containing a TO _MUST_NOT_ be forwarded unless there is a BLOB that authenticates properly. A better name for the BLOB would be Authenticator. > VIA Maybe the VIA should not be named VIA but VIA-RSV or something that makes it clear that it does not refer to the route of the original packet, not this one? I think VIA should be variable length, allowing one VIA to have multiple addresses. --Pekka From pekka.nikander@nomadiclab.com Thu Apr 15 08:29:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 15 07:29:01 2004 Subject: [Hipsec] The order in which keys are drawn In-Reply-To: <407E72A6.80504@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> <406807A9.4040800@nomadiclab.com> <2B82F324-84B3-11D8-83AA-000393CE1E8C@nomadiclab.com> <4070FA19.9050805@nomadiclab.com> <13A34E19-87BE-11D8-961F-00306571BE62@nomadiclab.com> <4072A9DB.2050205@nomadiclab.com> <49404159-87F8-11D8-9B06-00306571BE62@nomadiclab.com> <612369691.1081354202@[192.168.2.241]> <0B44413A-8850-11D8-9B06-00306571BE62@nomadiclab.com> <40738F9B.8020604@nomadiclab.com> <407E72A6.80504@nomadiclab.com> Message-ID: <2586E4F6-8ED7-11D8-AC5A-000393CE1E8C@nomadiclab.com> > As agreed earlier, the key retrieval will be based on HIT > comparison. Here is some initial new text that describes > the key retrieval order for the base exchange and for rekeying. Both looked good to me, but I may have missed something. --Pekka From andrew@indranet.co.nz Thu Apr 15 17:36:01 2004 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Apr 15 16:36:01 2004 Subject: [Hipsec] A separate ECHO_REQUEST / ECHO_RESPONSE parameter? (was Re: responding to unknown SPIs In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406057E@xch-nw-27.nw.nos.boeing .com> <407D0E8B.6080704@nomadiclab.com> Message-ID: <83915464.1082107464@[192.168.1.249]> I was tasked with figuring out how to do RTT estimation in AC/ACR... this seems to me to be part of the solution, but it can clearly be used for lots of other purposes. Great idea, Andrew --On Thursday, 15 April 2004 11:28 a.m. +0300 Pekka Nikander wrote: > Petri and others, > > The ability to send opaque data and get it back seems to be > useful for more than one purposes. So far we have at least > two distinct purposes: > > - For cookies, to include some state in R1 so that it > gets echoed back in I2 > > - For RSV, to include some state in I1 so that it gets > echoed back in R1. > > Hence, I would suggest making this opaque data echo back > service a separate parameter, and put it after the SIG. > > For the TLV table: > > ECHO_REQUEST 65281 variable Opaque data to be echoed back > ECHO_RESPONSE 65283 variable Opaque data echoed back > > For the actual text: > > The ECHO_REQUEST parameter contains an opaque blob of data that > the sender wants to get echoed back in the corresponding reply packet. > The ECHO_RESPONSE parameter contains the echoed back data. > > The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any > purpose where a node wants to carry some state in a request packet > and get it back in a response packet. Note that ECHO_REQUEST and > ECHO_RESPONSE parameters are not covered by the HMAC or SIGNATURE. > > It is currently defined how to use the ECHO parameters for extended > COOKIES, see Section XXX. > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opaque data (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type 65281 or 65283 > Length variable > Opaque data Opaque data, supposed to be meaningful only to the > node that sends ECHO_REQUEST and receives a > corresponding ECHO_RESPONSE. > > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > --------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet-technologies.com/ From jonwood@speakeasy.net Fri Apr 16 13:57:19 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Apr 16 12:57:19 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: <860CD350-8ED5-11D8-AC5A-000393CE1E8C@nomadiclab.com> References: <200404151353.42146.julien.laganier@sun.com> <860CD350-8ED5-11D8-AC5A-000393CE1E8C@nomadiclab.com> Message-ID: <766CD962-8FCD-11D8-B545-0003930D291E@speakeasy.net> On Apr 15, 2004, at 5:07 AM, Pekka Nikander wrote: > > Hence, I would not *necessarily* be dropping #I and K from SOLUTION > (if we adopt it). I think that a SOLUTION without #I and K is > more aesthetic, but OTOH it is only 8 bytes more (you still need > padding for #J) and leaves the implementations the possibility of > not using the opaque field/parameter at all. > Yes, I think that it would be good to keep the #I and K in the SOLUTION to allow implementations more flexibility in verifying puzzles. Jon From jonwood@speakeasy.net Fri Apr 16 18:28:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Apr 16 17:28:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: I have some comments about the current design for the mm draft (draft-nikander-hip-mm-0*). These comments are mostly high-level and apply to both version 00 and 01. Use of SAs in MM ---------------- I'm not very comfortable with the use of new/multiple SAs to handle new addresses. It is a pretty heavy weight and complex way to add a new address, and getting IPSec policy management to select the right SA based on the ultimate IP address selected would be pretty tricky (and require lots of hacking :). From reading back over the archives, it appears that the primary motivation for this approach is to handle the case of packets sent on different links with different latencies falling outside the ESP replay window. However, if you have a decent RTT estimate for each path to the peer, it should be possible to adjust the replay window according to your link conditions. (More on RTT estimation later). If this is the case, is there still a need to create a new SA for each new address put in use? Address States -------------- Currently the drafts specify that a host maintain address state on each peer address (active, unverified, deprecated), and one of the addresses is preferred. I think that there are some problems with this approach. A host really only cares about active addresses - if it wants to switch to a new address in the case of path failure, it wants the backup to already be active so there is no delay in failing over. If it wants to send some packets on one path and other packets on another path, it also wants both paths to be active and verified. Keeping track of unverified and deprecated addresses seems to be a waste of resources. So perhaps dropping the unverified and deprecated states might be a better approach. All addresses are verified for return routability (if policy dictates) upon receipt. The other mechanism that probably needs to be in place for this to work is some sort of periodic probe to verify that the path is still alive. This probe can also be used to estimate RTTs for each path, which can then be used to set the ESP replay window. The path RTTs can also be fed to transport protocols. For a mature example on how to do this sort of thing, see SCTP (rfc2960) and its heartbeat mechanism. 3-Way Exchange Reliability -------------------------- Adding a new address involves a protocol exchange conceptually like this (RR = return routability check): Initator Responder REA --------------> RR Request/Ack <-------------- RR Reply ---------------> Currently the RR request doubles as an ack for the REA. Presumably the REA will be retransmitted if no RR request is received after some time (via the UPDATE protocol in draft version 01). However, there is no such mechanism in place to ensure the the RR reply gets best effort delivery (whether it be data or a HIP TLV). If it gets lost, the address verification is left in limbo. I think we need something more reliable. Two (not terribly attractive) possibilities are having the responder retransmit the RR request, or going with a 4-way exchange with the initiator retransmitting the RR reply if necessary. [ Does this also apply to the UPDATE exchange in the base protocol? ] A Security Consideration ------------------------ Currently the drafts with allow a peer to add an unlimited number of addresses to an assocation. This could open a window to an attack where a host attempts to exhaust its peer's memory resources by adding lots of addresses. HIP implementations should allow administrators to place limits on the number of peer addresses added. However, when the limit is reached, will we need some protocol mechanism to inform the peer that the address addition has been rejected? CGA Addresses? -------------- Just curious: If a peer's address is a CGA and can be verified against the peer's public key, can we skip RR? From thomas.r.henderson@boeing.com Fri Apr 16 21:15:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Apr 16 20:15:02 2004 Subject: [Hipsec] hip-mm proposed revisions Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04521B2E@xch-nw-27.nw.nos.boeing.com> All, I made another pass at the mm draft. It is posted at: http://hip.piuha.net/drafts/draft-nikander-hip-mm-02-pre1.txt In addition, I propose some changes to the base draft to align it with the mm draft (and some cleanup involving NES). =20 These changes are at the end of this message. =20 Here is a brief summary of the changes I am proposing: Base draft changes (against 10-pre1.txt): i) move UPDATE ID out of the NES parameter and put it as a separate parameter (logically, this is part of the UPDATE packet header, but since we have fixed header, this becomes the first parameter in the UPDATE packet). ii) rewrote UPDATE packet definition. UPDATEs basically work the same way that we had them before-- a host sends an UPDATE with the R bit unset, and the peer replys with a matching UPDATE_ID but with the R bit set iii) updated Section 8.10 on UPDATE/NES actions accordingly. =20 Mobility management changes (against 02-pre-Jan22.txt): i) biggest change is the substitution of "SPI" for "address group". I felt that this was a more straightforward way to represent the situation, since there seems to be a 1-1 correspondence with what was calling an address group, and the SA (SPI). Section 5=20 describes this in more detail. ii) consistently made the statement that a host may opt out of explicit RR-check for REA if desired iii) used the UPDATE-request/UPDATE-reply as the basis for the=20 REA RR check (the practice of looking for data on the new SPI is also a valid sign) iv) decoupled REA from NES (NES is optional addition to REA). This is because the replay windows may be loose enough that they do not necessitate a new SPI upon readdressing. v) REA may also be included in NOTIFY packet, if it is informational. The biggest distinction between NOTIFY and UPDATE is that NOTIFY does not solicit a response from the peer. vi) various minor nits to align with the current base. Tom 6.2.13 NES (New SPI) During the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one (to prevent wrapping) and rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on use of a key. Rekeying ends the current SAs and starts new ones on both peers. The NES parameter is carried in the HIP UPDATE packet. It is used to reset Security Associations. It introduces a new SPI to be used=20 when sending data to the sender of the UPDATE packet. The keys=20 for the new Security Association will be drawn from KEYMAT. If=20 the packet contains a Diffie-Hellman parameter, the KEYMAT is first=20 recomputed before drawing the new keys. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Keymat Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 Length 12 Keymat Index Index, in bytes, where to continue to draw ESP keys from KEYMAT. If the packet includes a new Diffie-Hellman key, the field MUST be zero. Note that the length of this field limits the amount of keying material that can be drawn from KEYMAT. If that amount is exceeded, the NES packet MUST = contain a new Diffie-Hellman key. Old SPI Old SPI for data sent to the source address of this packet New SPI New SPI for data sent to the source address of this packet A host that receives an NES must reply shortly thereafter with an=20 NES. Any middleboxes between the communicating hosts will learn=20 the mappings from the pair of UPDATE messages. 6.2.XXX UPDATE_ID 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |R| Update ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 4 (length in octets, excluding Type and Length) Reserved zero when sent, ignored when received R Response bit. Conveys semantics to the Update ID field. If set to 0, the Update ID corresponds to = the host's update sequence number. If set to 1, the=20 Update ID corresponds to the echo of the Update ID to which this UPDATE is in response. Update ID 24-bit sequence number=20 The Update ID is an unsigned quantity, initialized by a host to zero, = and is incremented by one before each new UPDATE that is sent by the host (i.e., the first UPDATE packet originated by a host has an Update ID of 1). If the UPDATE packet is in response to=20 a peer's UPDATE packet, the R bit is set to 1, and the Update ID is the echoed value of the Update ID in the received UPDATE packet that triggered the response. 7.5 UPDATE - the HIP Update packet The UPDATE packet is MANDATORY. The UPDATE packet provides a mechanism for a host to send HIP parameters and receive an acknowledgment from its peer. The UPDATE can be used to carry parameters such as NES and DIFFIE_HELLMAN, and parameters to be defined in the future, such as for readdressing. The UPDATE also contains mandatory HMAC and HIP_SIGNATURE parameters, since processing UPDATE signatures is a potential DoS attack against intermediate systems. The UPDATE packet carries one UPDATE_ID parameter, and one or more other optional parameters. A host that originates an UPDATE packet=20 that is not in response to a peer's UPDATE includes an UPDATE_ID=20 with the R bit set to zero. If a host receives an UPDATE parameter=20 with an UPDATE_ID that has the R bit set to zero, it MUST reply with=20 an UPDATE packet including an UPDATE_ID with the R bit set to one. =20 UPDATE packets are always used in pairs, one in both directions, with identical UPDATE IDs. In the case both parties decide to UPDATE at the same time, the result is four UPDATE packets, two in both directions. Intermediate systems that use the SPI will have to inspect HIP packets for a UPDATE packet. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents of this packet cannot be encrypted. The HIP header values for the UPDATE packet: Header: Packet Type =3D 5 SRC HIT =3D Sender's HIT DST HIT =3D Recipient's HIT IP ( HIP ( UPDATE_ID, [NES, DIFFIE_HELLMAN] HMAC, HIP_SIGNATURE ) = ) Valid control bits: None /* Note: Could move the "R" bit into the controls, and then allow */ /* the UPDATE_ID sequence number to be 32 bits. */ =20 8.9 Initiating rekeying A system may initiate the rekey procedure at any time. It MUST initiate a rekey if its incoming ESP sequence counter is about to overflow. The following steps define the conceptual processing rules for initiating a rekey: 1. The system SHOULD generate a new Diffie-Hellman public key. 2. The system increments the Update ID by one. 3. The system creates a UPDATE packet, which contains an UPDATE_ID parameter (with the current value of Update ID), NES parameter and an optional DIFFIE_HELLMAN parameter. If the=20 UPDATE packet contains the DIFFIE_HELLMAN parameter, the=20 Keymat Index in the NES parameter MUST be zero. =20 4. The system sends the UPDATE packet and transitions to state=20 REKEYING. 5. The system SHOULD start a timer whose timeout value should be larger than the worst-case anticipated RTT, and MUST increment a timeout counter associated with UPDATE. The sender SHOULD retransmit the UPDATE upon a timeout and restart the timer, up to a maximum of UPDATE_RETRIES_MAX tries. 6. The system MUST NOT delete its existing SAs, but continue using them if its policy still allows. The UPDATE procedure SHOULD be initiated prior enough in order to make sure that the SA replay counters do not overflow. =20 8.10 Processing UPDATE packets When a system receives a UPDATE packet, its processing depends on whether the packet is a reply to a previously sent UPDATE packet or the UPDATE is a new packet. =20 The order of the keys retrieved from the KEYMAT during rekeying process depends on the HIT value comparison. We denote the host with lower HIT value with HITl and, respectively, the host with greater HIT with HITg. The HITs are compared in network byte order. The keys are retrieved from the KEYMAT in the following order: SA-gl ESP encryption key for HITg's outgoing traffic SA-gl ESP authentication key for HITg's outgoing traffic SA-lg ESP encryption key for HITl's outgoing traffic SA-lg ESP authentication key for HITl's outgoing traffic The following steps define the conceptual processing rules for handling a received UPDATE packet: 1. If the system is in state ESTABLISHED and the UPDATE has the R-bit set in the UPDATE_ID parameter, the packet is silently=20 dropped. =20 2. If the R-bit is cleared, and if the Update ID in the received=20 UPDATE_ID parameter is smaller than the stored Update ID for the host, the packet MUST BE dropped. Note that if the Update=20 ID is equal to the stored value, the packet can be expected to=20 be a retransmission, and acted upon accordingly. However, the=20 HMAC verification (next step) MUST NOT be skipped. (A=20 byte-by-byte comparison of the received and a stored packet=20 would be OK, though.) 3. The system MUST verify the HMAC in the UPDATE packet. If the verification fails, the packet MUST be dropped. 4. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the received Keymat Index MUST be zero. If this test fails, the packet SHOULD be dropped and the system SHOULD log an error message. 5. If the received UPDATE does not contain a DIFFIE_HELLMAN parameter, the received Keymat Index MUST be larger or equal to the index of the next byte to be drawn from the current KEYMAT. If the host is in REKEYING state, a smaller Keymat Index value MAY be accepted. If the host is in ESTABLISHED state and this test fails, the packet SHOULD be dropped and the system SHOULD log an error message. 6. The system MAY verify the SIGNATURE in the UPDATE packet. If the verification fails, the packet SHOULD be dropped and an error message logged. 7. The system MUST record the Update ID in the received packet, for replay protection. 8. If the system is in state ESTABLISHED, and the UPDATE does not have the R-bit set in the UPDATE_ID parameter, the packet is=20 processed as specified in Section 8.10.1. 9. If the system is in state REKEYING, and the UPDATE has the R-bit set in the UPDATE_ID parameter, the packet is further processed=20 as specified in Section 8.10.2. 10. If the system is in state REKEYING, and the UPDATE doesn't have the R-bit set in the UPDATE_ID parameter, there are apparently=20 two UPDATE packets crossing each other in the network.=20 Consequently, the R-bit-less packet is handled as specified in=20 Section 8.10.1. However, in order not to unnecessarily spend=20 cycles in Diffie-Hellman computations, there are minor = differences=20 with respect to receiving such a packet in state ESTABLISHED. 8.10.1 Processing an initial UPDATE packet When a system receives an initial UPDATE packet, i.e. one that does not have the R-bit set, it prepares new incoming and outgoing SAs, but does not change the outgoing SA yet. Once it has the new SAs in place, it sends a reply UPDATE. The contents of the reply UPDATE depend on whether the system was in state ESTABLISHED or REKEYING upon receiving the initial UPDATE packet. The following steps define the conceptual processing rules responding handling a received initial UPDATE packet: 1. If the system is in state ESTABLISHED, it consults its policy to see if it needs to generate a new Diffie-Hellman key, and generates a new key if needed. If the system is in state REKEYING, it may already have generated a new Diffie-Hellman key, and SHOULD use it. 2. If either the received UPDATE contains a new Diffie-Hellman key, the system has a new Diffie-Hellman key from the previous step, or both, the system generates new KEYMAT. If there is only one new Diffie-Hellman key, the other old key is used. 3. If the system generated new KEYMAT in the previous step, it sets Keymat Index to zero, independent on whether the received UPDATE included a Diffie-Hellman key or not. 4. If the host is in REKEYING state, and neither the incoming UPDATE packet nor the sent UPDATE packet required new KEYMAT generation, the bigger Keymat Index number of those two UPDATE packets shall be used. 5. The system draws keys for new incoming and outgoing ESP SAs, starting from the Keymat Index, and prepares new incoming and outgoing ESP SAs. The SPI for the outgoing SA is the new SPI value from the received UPDATE. The SPI for the incoming SA is locally generated, and SHOULD be random. The system MUST NOT start using the new outgoing SA before it receives traffic on the new incoming SA. 6. The system prepares a reply UPDATE packet, with the R-bit one in the UPDATE_ID parameter, Keymat Index being the one used above,=20 Update ID being equal to the one in the received UPDATE, old SPI=20 being the current incoming SPI, and new SPI being the newly=20 generated incoming SPI. If the system generated a new=20 Diffie-Hellman key above, the new key is included in the packet=20 in the Diffie-Hellman payload. Note that if the system is=20 in state REKEYING, the new Diffie-Hellman key was probably=20 generated and sent already earlier, in which case it MUST NOT=20 be included into the reply packet. 8.10.2 Processing a reply UPDATE packet When a system receives a reply UPDATE packet, i.e. one that has the R-bit set in the UPDATE_ID parameter, it starts to use the new=20 outgoing SA. It must also complete its new incoming SA. The following steps define the conceptual processing rules responding handling a received reply UPDATE packet: 1. If either the received UPDATE contains a new Diffie-Hellman key, the system has a new Diffie-Hellman key from initiating rekey, or both, the system generates new KEYMAT. If there is only one new Diffie-Hellman key, the old key is used as the other key. 2. If the system generated new KEYMAT in the previous step, it sets Keymat Index to zero, independent on whether the received UPDATE included a Diffie-Hellman key or not. 3. The system draws keys for new incoming and outgoing ESP SAs, starting from the Keymat Index, and prepares new incoming and outgoing ESP SAs. The SPI for the outgoing SA is the new SPI value from the UPDATE. The SPI for the incoming SA was generated when rekey was initiated. 4. The system starts to send to the new outgoing SA. It should start receiving data on the new incoming SA as soon as the peer receives data on the new SA. From thomas.r.henderson@boeing.com Fri Apr 16 21:45:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Apr 16 20:45:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406059F@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net] > Sent: Friday, April 16, 2004 3:17 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Comments on draft-nikander-hip-mm >=20 >=20 >=20 > I have some comments about the current design for the > mm draft (draft-nikander-hip-mm-0*). These comments are > mostly high-level and apply to both version 00 and 01. >=20 > Use of SAs in MM > ---------------- > I'm not very comfortable with the use of new/multiple SAs > to handle new addresses. It is a pretty heavy weight and > complex way to add a new address, and getting IPSec policy > management to select the right SA based on the ultimate IP > address selected would be pretty tricky (and require lots > of hacking :). >=20 > From reading back over the archives, it appears that > the primary motivation for this approach is to handle > the case of packets sent on different links with > different latencies falling outside the ESP replay > window. >=20 > However, if you have a decent RTT estimate for each > path to the peer, it should be possible to adjust the > replay window according to your link conditions. (More > on RTT estimation later). If this is the case, is there > still a need to create a new SA for each new address > put in use? In the new draft I just sent around, it is explicitly=20 stated that the main reason a host may want new SAs is due to replay window. However, it also says that it is up to the host whether to generate new SAs upon a readdress event-- i.e., REA is decoupled from NES in the proposed draft. >=20 > Address States > -------------- > Currently the drafts specify that a host maintain > address state on each peer address (active, unverified, > deprecated), and one of the addresses is preferred. >=20 > I think that there are some problems with this approach. > A host really only cares about active addresses - > if it wants to switch to a new address in the case of > path failure, it wants the backup to already be active > so there is no delay in failing over. If it wants to > send some packets on one path and other packets on > another path, it also wants both paths to be active and > verified. Keeping track of unverified and deprecated > addresses seems to be a waste of resources. >=20 > So perhaps dropping the unverified and deprecated states > might be a better approach. All addresses are verified > for return routability (if policy dictates) upon receipt. It seems like you are really only arguing for dispensing with DEPRECATED. DEPRECATED state seems implicitly to me to be an implementation option-- maybe it should be an explict MAY? I think Pekka introduced this address=20 state- he may have more to say about it. =20 >=20 > The other mechanism that probably needs to be in place > for this to work is some sort of periodic probe to verify > that the path is still alive. This probe can also be used > to estimate RTTs for each path, which can then be used to > set the ESP replay window. The path RTTs can also be fed > to transport protocols. >=20 > For a mature example on how to do this sort of thing, see > SCTP (rfc2960) and its heartbeat mechanism. This could perhaps be accomplished via existing mechanisms, using a naked UPDATE packet. =20 "A host MAY periodically probe the reachability of an=20 address using an UPDATE packet. A host MAY use packet exchanges on a particular address to estimate the path RTT, which could be used to set the ESP replay window or fed to transport protocols." ?? >=20 > 3-Way Exchange Reliability > -------------------------- > Adding a new address involves a protocol exchange > conceptually like this (RR =3D return routability check): >=20 >=20 > Initator Responder > REA > --------------> > RR Request/Ack > <-------------- > RR Reply > ---------------> >=20 > Currently the RR request doubles as an ack for the REA. > Presumably the REA will be retransmitted if no RR > request is received after some time (via the UPDATE > protocol in draft version 01). However, there is no such > mechanism in place to ensure the the RR reply gets > best effort delivery (whether it be data or a HIP TLV). > If it gets lost, the address verification is left in limbo. > I think we need something more reliable. Two (not terribly > attractive) possibilities are having the responder retransmit > the RR request, or going with a 4-way exchange with the > initiator retransmitting the RR reply if necessary. > [ Does this also apply to the UPDATE exchange in the base > protocol? ] See the new draft. I think there are a couple of ways that REA could occur, depending on the circumstances: 1.=20 REA in NOTIFY -----------------> (recipient does nothing-- trusted host) 2. REA in UPDATE -----------------> UPDATE (reply) <---------------- (recipient does nothing but reply (ack) the REA 3. =20 REA in NOTIFY ----------------> UPDATE =20 <--------------- (recipient wants a RR check on the address) UPDATE (reply) ----------------> 4. REA in NOTIFY ----------------> UPDATE (NES) <--------------- (recipient wants a RR check and a new SA) UPDATE (reply) ----------------> 5. REA in UPDATE -----------------> UPDATE (reply) <----------------- (recipient must ack first UPDATE before sending own = RR check/NES) UPDATE (NES) <----------------- UPDATE (reply) -----------------> (at least, that is what I was hoping for in the proposed new draft-- to have this flexibility). =20 >=20 > A Security Consideration > ------------------------ > Currently the drafts with allow a peer to add an > unlimited number of addresses to an assocation. This could > open a window to an attack where a host attempts to > exhaust its peer's memory resources by adding lots of > addresses. HIP implementations should allow administrators > to place limits on the number of peer addresses added. > However, when the limit is reached, will we need some > protocol mechanism to inform the peer that the address > addition has been rejected? >=20 This could be in the new NOTIFY mechanism. > CGA Addresses? > -------------- > Just curious: > If a peer's address is a CGA and can be verified against > the peer's public key, can we skip RR? >=20 I'm not following-- any REA can be verified against the peer's public key via the signature? =20 Tom From pekka.nikander@nomadiclab.com Sun Apr 18 14:32:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Apr 18 13:32:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: References: Message-ID: <6D8DF625-9165-11D8-AC5A-000393CE1E8C@nomadiclab.com> Jon, > I'm not very comfortable with the use of new/multiple SAs > to handle new addresses. As have been discussed earlier on the list, it is fairly necessary for multi-homing due to replay protection, and it seems to beneficial for mobility since it exposes the SPIs in UPDATE packets, allowing middle boxes to learn them and create appropriate mappings. I guess we need to add more text to Section 4 of the draft where we discuss the scenarios, though Tom apparently already added some text about replay protection. [I haven't had time to read -02-pre1 yet.] The middle box thinking is not explained anywhere, though, IIRC. It needs to be added. > It is a pretty heavy weight and > complex way to add a new address, and getting IPSec policy > management to select the right SA based on the ultimate IP > address selected would be pretty tricky (and require lots > of hacking :). Well, I don't quite follow your thoughts. Right now in our implementation we first select the SA, and the ultimate IP address is stored in the SA. Before the upper protocols get an ability to perform congestion control and flow management simultaneously on multiple paths, we can't use more than one path on a single TCP connection anyway. Hence, setting up the policies is pretty simple: You select the SA based on the destination HIT, protocol, and ports. No hacking at all. The SA determines the destination address. Now, if we fast forward to the future where we can envision an application being able to have better control on the addresses, the baseline case is still easy. You just use socket options to select the SA and thereby the destination address on your socket. Only when we want applications to have more complex policies or the upper layer protocols to really utilise multi-path, the situation gets tricky. But then you have to rewrite much of your stack anyway. > However, if you have a decent RTT estimate for each > path to the peer, it should be possible to adjust the > replay window according to your link conditions. (More > on RTT estimation later). If this is the case, is there > still a need to create a new SA for each new address > put in use? Tom already answered this. Creating new SAs is your own choice. Alternatively, you can just add a new address on an existing SA. In -01 replacing SPI was the only way of performing return routability check. However, the intention of the new text in -02 is to allow using UPDATE as an alternative. The rationale for combining SPI change and RR was actually simplicity. If you have any middle boxes in your route, you have to tell the middle boxes about your SPIs anyway. Furthermore, you may loose quite a lot of traffic while you change your network attachment. Resetting your SPI makes the protocol more robust. Anyway, the intention of the -02 text is to be more flexible, and allow you to continue using the same SA and SPI. But you still need to send the SPIs both ways so that middle boxes can learn them. > Keeping track of unverified and deprecated > addresses seems to be a waste of resources. It is really up to you what you do here. Some people may defer return routability check; hence UNVERIFIED. If UNVERIFIED is just a very transient state for your implementation, it shouldn't harm interoperability. If you don't want to keep track of deprecated addresses, you don't need to. > So perhaps dropping the unverified and deprecated states > might be a better approach. Well, I guess we need to change the language here. The section already starts with "In a _typical_ implementation," Do you have a suggestion on how to make the text more clear that it is really up to you what you implement, as long as the external behaviour *could* be implemented in the way described in the draft? > All addresses are verified > for return routability (if policy dictates) upon receipt. That would be an unnecessary restriction in the spec. Of course, you are free to implement in that way if you wish. > The other mechanism that probably needs to be in place > for this to work is some sort of periodic probe to verify > that the path is still alive. There is nothing that prevents you from doing that, pretty much the same way SCTP has heartbeats. Right now the text just says that unused addresses should be deprecated after some time, without dictating any policy. > This probe can also be used > to estimate RTTs for each path, which can then be used to > set the ESP replay window. The path RTTs can also be fed > to transport protocols. As far as I see, there is nothing in the draft that prevents you from implementing it in this way. Would you like to write an appendix where you describe some of these implementation options? The text Tom provided is fine, but I don't see why we should include it in the protocol proper? Is there some reason? Or could it be in an appendix? > For a mature example on how to do this sort of thing, see > SCTP (rfc2960) and its heartbeat mechanism. I'm pretty familiar with that; see the following paper, aware on my publications page. :-) Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo, "Effects of Mobility and Multihoming on Transport-Layer Security," to appear in Proceedings of IEEE Symposium on Security and Privacy, Berkeley/Oakland, California, May 9-12, 2004, IEEE Computer Society, to appear. > Currently the RR request doubles as an ack for the REA. This was (and still is) an important optimisation, IMHO. Of course, as Tom described, you don't need to initiate RR at the same time, you can just ack REA. Adding to the five scenarios Tom described, I still think that it is OK to implicitly finish RR with new traffic to a new SPI. However, I haven't had time to carefully read -02-pre1 to see what the text says, and if any changes are needed there. Hence, the reply UPDATEs in Tom's scenarions #3, #4 and #5 *MAY* be replaced with implicit traffic. In fact, IMHO in scenario #4 where a new SPI is created the reply update is really unnecessary. But apparently people's opinions differ on this. Furthermore, I think that Tom's scenario #5 where there are two UPDATEs from the recipient to the sender of REA is not likely to happen in real life, though there shouldn't be anything in the spec forbidding it. A piece of history: When I started to think about using ESP traffic as implicit ack, I found it ugly and originally rejected it. (It was present already in some of the early drafts by Bob M.) However, my mind has slowly changed. Especially when I realised that you don't need to have any triggers from ESP. It is sufficient that you poll your ESP to see if there has been any traffic. That can be implemented easily: you get a timeout, you poll, and you process the result of the poll either as an ack (if there had been traffic) or timeout (if there had not been any traffic). > ... there is no such > mechanism in place to ensure the the RR reply gets > best effort delivery (whether it be data or a HIP TLV). > If it gets lost, the address verification is left in limbo. Is this a problem? The address will stay in UNVERIFIED state, and you will need to re-initiate return routability on that if you intend to use the address. I don't see where you have a problem here. But perhaps I'm missing something? > A Security Consideration > ------------------------ > Currently the drafts with allow a peer to add an > unlimited number of addresses to an assocation. This could > open a window to an attack where a host attempts to > exhaust its peer's memory resources by adding lots of > addresses. As far as I can see, there is nothing in the draft that mandates the peer to accept that information. But I admit that adding some text to security considerations section is probably a good idea. > HIP implementations should allow administrators > to place limits on the number of peer addresses added. Yes. > However, when the limit is reached, will we need some > protocol mechanism to inform the peer that the address > addition has been rejected? Hmm. Do we? At Tom wrote, we _could_ use NOTIFY for that. Maybe we could define a notify message that MAY be used for that purpose, but IMHO it should also be perfectly OK for a host not to notify its peer that it is not storing all addresses. > If a peer's address is a CGA and can be verified against > the peer's public key, can we skip RR? In general, no. Flooding is not only about flooding hosts, it is also about flooding subnets. CGA doesn't prevent you from generating CGAs for subnets where you aren't. --Pekka From thomas.r.henderson@boeing.com Mon Apr 19 01:35:03 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Apr 19 00:35:03 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605A3@xch-nw-27.nw.nos.boeing.com> > > Currently the RR request doubles as an ack for the REA. >=20 > This was (and still is) an important optimisation, IMHO. > Of course, as Tom described, you don't need to initiate > RR at the same time, you can just ack REA. >=20 > Adding to the five scenarios Tom described, I still think > that it is OK to implicitly finish RR with new traffic to > a new SPI. However, I haven't had time to carefully > read -02-pre1 to see what the text says, and if any > changes are needed there. Hence, the reply UPDATEs > in Tom's scenarions #3, #4 and #5 *MAY* be replaced > with implicit traffic. In fact, IMHO in scenario #4 > where a new SPI is created the reply update is really > unnecessary. But apparently people's opinions > differ on this. This optimization (skipping UPDATE response by sending data on new SPI) is not contained in the text that I proposed. =20 Currently, UPDATE packet always causes an UPDATE reply. Conceptually, I like to save packets when possible, but I wonder whether we can get by with the implicit ACK if middleboxes are along the way. I think that you are=20 suggesting that we can't in all cases (you don't suggest=20 implicit ack in scenario 2, perhaps for this reason), but in the other cases, we probably need to think more about the packet processing rules as for when a host is allowed to make that optimization. But I'm in favor of trying to make that optimization work as long as it doesn't make the state machine logic too ugly. Overall, the text that I proposed needs an iteration to=20 check for middlebox-friendliness of the potential exchanges. Tom From pekka.nikander@nomadiclab.com Mon Apr 19 04:33:04 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Apr 19 03:33:04 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: <4063FAF2.804@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing .com> <36208314.1079399626@[192.168.1.249]> <4063FAF2.804@nomadiclab.com> Message-ID: [Returning to an old issue.] >> Pekka Nikander wrote: >>> 1. Do we want to preserve the distinction between the >>> initiator and responder once we are in ESTABLISHED? >>> The original goal was NOT to have any distinction. > Andrew McGregor wrote: >> Which is, I think, pretty much essential to retain. That way it is >> always safe for either end to be the initator of any further >> mechanisms, without having to deal with differences to do with who >> was the initiator of the whole session. On Mar 26, 2004, at 11:42, Petri Jokela wrote: > Further developing the idea: store R2 when we as responder send it > out. As an initiator, we do nothing. Define in ESTABLISHED that > respond to an I2 with an R2 if stored, otherwise drop the I2. In this > case, I think, we move in the grey zone (as the term is in sports when > you use something "almost" doping), because we "know" that we are a > responder if we have an R2. I think that is a good way to implement. However, I would be more careful with the spec. What seems to be essential is that a Responder is prepared to reply to a resent I2 with an R2 as long as it does *not* know, for sure, that the Initiator has got the R2 as is therefore in the ESTABLISHED state. IMHO, it MAY reply longer, even if it knows that the Initiator is in ESTABLISHED. That would give pretty much leeway for different implementations. -10-pre1 seems to have adopted my suggestion of the state machine with R2-SENT. If I remember correctly, Tom objected having that as a separate state, or at least having the statement "leave R2-SENT if either some time has expired (allowing for maximal retransmission of I2s), or some data has been received on the SA, or an UPDATE packet has been received (or some other packet that indicates that the peer has moved to ESTABLISHED)." I think this suggestion is good, and I am folding it in below. We still need changes to Section 8.7. and probably a new section handling moving out from R2-SENT. The following changes are against -10-pre1 For Section 8.7, I would suggest the following: Add new steps between current 2 and 3: 2.1 If the system is in the R2-SENT state, it MAY check if the newly received I2 is similar to the one that triggered moving to R2-SENT. If so, it MAY retransmit a previously sent R2, reset the R2-SENT timer, and stay in R2-SENT. 2.2 If the system is in any other state, it SHOULD check that the birthday value in I2 is larger than the currently stored peer birthday value, if there is a stored value. If the newly received I2 has a lower or equal birthday value than the stored one, the I2 is stale (perhaps replayed) and SHOULD be dropped. Remove step 9, as the birthday check is now performed earlier. Change Step 17 to read: 17. Upon successful processing of an I2 in states UNASSOCIATED, I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine transitions to state R2-SENT. In Step 18, replace s/transitions to ESTABLISHED,/transitions to R2-SENT,/ Add a new step after 18: 19. Upon transitioning to R2-SENT, start a timer. Leave R2-SENT if either the timer expires (allowing for maximal retransmission of I2s), some data has been received on the incoming SA, or an UPDATE packet has been received (or some other packet that indicates that the peer has moved to ESTABLISHED). Implementing this step is OPTIONAL. Question: Should #19 be RECOMMENDED instead of OPTIONAL? Are there anything else with this issue (#23), or could we close it? --Pekka From thomas.r.henderson@boeing.com Mon Apr 19 17:40:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Apr 19 16:40:02 2004 Subject: [Hipsec] Text for solving the R2 losses problem Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605A8@xch-nw-27.nw.nos.boeing.com> see inline below > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, April 19, 2004 1:24 AM > To: hipsec@honor.trusecure.com > Cc: Petri Jokela > Subject: Re: [Hipsec] Text for solving the R2 losses problem >=20 >=20 > We still need changes to Section 8.7. and probably a new > section handling moving out from R2-SENT. The following > changes are against -10-pre1 >=20 > For Section 8.7, I would suggest the following: >=20 > Add new steps between current 2 and 3: >=20 > 2.1 If the system is in the R2-SENT state, it MAY check > if the newly received I2 is similar to the one that > triggered moving to R2-SENT. If so, it MAY retransmit > a previously sent R2, reset the R2-SENT timer, and stay > in R2-SENT. >=20 > 2.2 If the system is in any other state, it SHOULD > check that the birthday value in I2 is larger than > the currently stored peer birthday value, if there is > a stored value. If the newly received I2 has a lower > or equal birthday value than the stored one, the I2 is > stale (perhaps replayed) and SHOULD be dropped. >=20 > Remove step 9, as the birthday check is now performed earlier. >=20 > Change Step 17 to read: >=20 > 17. Upon successful processing of an I2 in states UNASSOCIATED, > I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state > machine transitions to state R2-SENT. >=20 > In Step 18, replace >=20 > s/transitions to ESTABLISHED,/transitions to R2-SENT,/ >=20 > Add a new step after 18: >=20 > 19. Upon transitioning to R2-SENT, start a timer. Leave > R2-SENT if either the timer expires (allowing for > maximal retransmission of I2s), some data has been > received on the incoming SA, or an UPDATE packet has > been received (or some other packet that indicates > that the peer has moved to ESTABLISHED). Implementing > this step is OPTIONAL. >=20 > Question: Should #19 be RECOMMENDED instead of OPTIONAL? If step 17 says to move to R2-SENT, but step 19 is optional, won't implementations not implementing step 19 get stuck in state R2-SENT? I think we need to have this state transition described-- how it is implemented is optional. So I would delete the last sentence in 19. (by the way, there is no discussion in the text of what happens when moving from ESTABLISHED to UNASSOCIATED, or what triggers such a transition) >=20 > Are there anything else with this issue (#23), or could we > close it? >=20 Issue #12 seems to cover the birthday check being badly defined, so otherwise we could probably close #23. Birthday check still needs more definition, IMO. Perhaps update issue #12 with the following from Pekka (embedded in issue #33): > Finally, due to the desire to make it possible for Alice > to make a difference between a replayed and fresh R1s, > I think that we need to retain the birthday parameter > even if we remove resynchronization out of the base spec, > and even make it stronger. Basically, it seems to me best > to increment birthday count whenever old R1s are not > accepted any more. This is apparently a change to the > current draft, and therefore probably requires opening > a new issue. [Petri, please.] Tom From thomas.r.henderson@boeing.com Mon Apr 19 21:52:04 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Apr 19 20:52:04 2004 Subject: [Hipsec] Splitting the COOKIE parameters Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605AB@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, April 15, 2004 5:08 AM > To: Julien Laganier > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Splitting the COOKIE parameters >=20 >=20 > >> Question: Do we need to echo back K and #I now that we have the > >> Opaque field/parameter? The required information could as easily > >> be stored there? > > > > I agree that sending back K and I would be redundant information. As > > PUZZLE and SOLUTION are now two different parameters, I would prefer > > simplicity and no ambiguity, i.e., drop K and I in the SOLUTION. >=20 > The case is not that clear cut. Using the opaque info requires > you to verify its integrity first, i.e., compute at least one hash. > And only after that you know if the I2 is related to any R1 that > you have sent recently. On the other hand, using #I (and K) directly > as an index to the right puzzle may be made very cheaply. Indeed, > if you have a (too) simple implementation, you can use them just > directly. (Which is, of course, unsecure.) [Afterthought: Of > course, you could store just an index and a once in the opaque field, > and check that the index points to the same nonce in your own data > structures, but you can do that almost as easily with #I.] >=20 > Hence, I would not *necessarily* be dropping #I and K from SOLUTION > (if we adopt it). I think that a SOLUTION without #I and K is > more aesthetic, but OTOH it is only 8 bytes more (you still need > padding for #J) and leaves the implementations the possibility of > not using the opaque field/parameter at all. >=20 Another option: K does not need to be 4 bytes. Highest order 2-3 bytes could be used as an optional opaque field by responder, to index the = puzzle somehow, if needed. Then, just include K (4 bytes) in solution and do = not=20 send back I or necessarily use separate opaque data TLV. However, could you explain why Birthday is 96 bits? This is likely cumbersome data type to support on the native system. Incrementing once per second, a 32 bit counter takes over 100 years to roll over. Tom p.s. in general I think that the splitting of these parameters, and the opaque TLVs, are nice changes. =20 From pekka.nikander@nomadiclab.com Tue Apr 20 07:16:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 20 06:16:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605AB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605AB@xch-nw-27.nw.nos.boeing.com> Message-ID: <8CEBC043-92BA-11D8-A238-000393CE1E8C@nomadiclab.com> >>>> Question: Do we need to echo back K and #I now that we have the >>>> Opaque field/parameter? The required information could as easily >>>> be stored there? >>> >>> I agree that sending back K and I would be redundant information. As >>> PUZZLE and SOLUTION are now two different parameters, I would prefer >>> simplicity and no ambiguity, i.e., drop K and I in the SOLUTION. >> >> The case is not that clear cut. >> > Another option: K does not need to be 4 bytes. Highest order 2-3 bytes > could be used as an optional opaque field by responder, to index the > puzzle > somehow, if needed. Then, just include K (4 bytes) in solution and do > not > send back I or necessarily use separate opaque data TLV. Sounds like a good idea. However, I would still like to carry #I explicitly in the solution. Its only 8 bytes, I2 will be large anyway, and including #I gives some freedom to the Responder implementation. I would not like if the responder would must remember #I. Something like the following: PUZZLE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Opaque, 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #K is covered by SIGNATURE2 Opaque and #I are NOT covered by SIGNATURE2 but zeroed before computing the message digest. The rationale for the placement of #K, Opaque and #I is that it makes it easier to implement the signature zeroing in some implementations. SOLUTION 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Opaque, 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #K and Opaque copied verbatim from the PUZZLE. All fields covered by SIGNATURE, nothing zeroed. > However, could you explain why Birthday is 96 bits? This is likely > cumbersome data type to support on the native system. Incrementing > once per second, a 32 bit counter takes over 100 years to roll over. Just alignment. 32 bits may not be enough for busy servers and such, otherwise it might be sufficient. If we want to save some bytes, maybe we could combine BIRTHDAY to the DIFFIE_HELLMAN parameter? 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Value / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Birthday would then be present also in (some) UPDATEs, which might be good. On the other hand, birthday would become more like D-H generation number, which may or may not be good, depending on how you cycle your D-H keys vs. how you cycle your puzzles. Yet another possibility would be to place it in PUZZLE but not in SOLUTION, making a new PUZZLE to be as follows. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Opaque, 3 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hence, the Birthday in a PUZZLE is replaced with the #J in a SOLUTION. The different Type values make the intention clear. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 20 07:29:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 20 06:29:00 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605A8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605A8@xch-nw-27.nw.nos.boeing.com> Message-ID: <5875DBC6-92BC-11D8-A238-000393CE1E8C@nomadiclab.com> >> Change Step 17 to read: >> >> 17. Upon successful processing of an I2 in states UNASSOCIATED, >> I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state >> machine transitions to state R2-SENT. >> >> In Step 18, replace >> >> s/transitions to ESTABLISHED,/transitions to R2-SENT,/ >> >> Add a new step after 18: >> >> 19. Upon transitioning to R2-SENT, start a timer. Leave >> R2-SENT if either the timer expires (allowing for >> maximal retransmission of I2s), some data has been >> received on the incoming SA, or an UPDATE packet has >> been received (or some other packet that indicates >> that the peer has moved to ESTABLISHED). Implementing >> this step is OPTIONAL. >> >> Question: Should #19 be RECOMMENDED instead of OPTIONAL? > > If step 17 says to move to R2-SENT, but step 19 is optional, won't > implementations not implementing step 19 get stuck in state R2-SENT? Yes. In practice, that would mean that such implementation makes no difference between ESTABLISHED and R2-SENT in the case it is a Responder. Is that a problem? [I don't know, I am just trying to play open options. But see below.] > I think we need to have this state transition described-- how it > is implemented is optional. So I would delete the last sentence > in 19. I would be happy with that. I think R2-SENT is a useful state, but there was some debate earlier on. I am personally in favour of deleting the last sentence, and thereby clearly making R2-SENT and ESTABLISHED different states. Perhaps just making it clearer that the whole state machine is just a concept, and implementations are free to implement it differently as long as the external behaviour is close enough? > (by the way, there is no discussion in the text of what happens > when moving from ESTABLISHED to UNASSOCIATED, or what triggers > such a transition) I guess a new section is in place. Maybe just after processing R2, before starting to speak about rekeying? 8.9. Dropping HIP associations A HIP implementation is free to drop a HIP association at any time, based on its own policy. If a HIP host decides to drop an HIP association, it deletes the IPsec SAs related to that association and the corresponding HIP state, including the keying material. The implementation MUST also drop the birthday value, unless a local policy explicitly defines that the birthday value of that particular host is stored. An implementation MUST NOT store birthday values by default, but storing birthday values, if done, MUST be configured by explicit HITs. Ok? >> Are there anything else with this issue (#23), or could we >> close it? > > Issue #12 seems to cover the birthday check being badly defined, > so otherwise we could probably close #23. Birthday check still > needs more definition, IMO. Yes, but isn't that covered well enough in issue #12? At least if we augment #12 as you suggest: > Perhaps update issue #12 with the following from Pekka (embedded > in issue #33): >> Finally, due to the desire to make it possible for Alice >> to make a difference between a replayed and fresh R1s, >> I think that we need to retain the birthday parameter >> even if we remove resynchronization out of the base spec, >> and even make it stronger. Basically, it seems to me best >> to increment birthday count whenever old R1s are not >> accepted any more. This is apparently a change to the >> current draft, and therefore probably requires opening >> a new issue. [Petri, please.] --Pekka From thomas.r.henderson@boeing.com Tue Apr 20 13:13:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 20 12:13:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605AE@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, April 20, 2004 4:05 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Splitting the COOKIE parameters >=20 > >=20 > > However, could you explain why Birthday is 96 bits? This is likely > > cumbersome data type to support on the native system. Incrementing > > once per second, a 32 bit counter takes over 100 years to roll over. >=20 > Just alignment. 32 bits may not be enough for busy servers and > such, otherwise it might be sufficient. >=20 > If we want to save some bytes, maybe we could combine BIRTHDAY > to the DIFFIE_HELLMAN parameter? It is fine with me to keep it in a separate TLV-- my main objection was 96 bits, which seemed excessive and more difficult to implement and handle. I still don't see a requirement for larger than 32 bits, but I see that this was originally 64 bits in draft-moskowitz-hip-05. Tom From jonwood@speakeasy.net Tue Apr 20 14:01:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Tue Apr 20 13:01:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <6D8DF625-9165-11D8-AC5A-000393CE1E8C@nomadiclab.com> References: <6D8DF625-9165-11D8-AC5A-000393CE1E8C@nomadiclab.com> Message-ID: <227711A6-92F3-11D8-93E5-0003930D291E@speakeasy.net> On Apr 18, 2004, at 11:23 AM, Pekka Nikander wrote: <...> > > Now, if we fast forward to the future where we > can envision an application being able to have > better control on the addresses, the baseline case > is still easy. You just use socket options to select > the SA and thereby the destination address on your > socket. Only when we want applications to have > more complex policies or the upper layer protocols > to really utilise multi-path, the situation gets > tricky. But then you have to rewrite much of your > stack anyway. OK, this is the hacking I was talking about :) I was having trouble figuring out how we could actually use multiple SAs for multi-homing. There seems to be lots of other work needed before all the pieces are in place for it. I'm not sure that keying multihoming policies by SPIs will be palatable to the rest of the stack, but I guess if HIP takes over the world that will be motivation enough. <...> > >> However, if you have a decent RTT estimate for each >> path to the peer, it should be possible to adjust the >> replay window according to your link conditions. (More >> on RTT estimation later). If this is the case, is there >> still a need to create a new SA for each new address >> put in use? > > Tom already answered this. Creating new SAs is your > own choice. Alternatively, you can just add a new > address on an existing SA. Right - I sent my mail just before Tom sent out notice about his draft. Making it optional is better, I think. However, you didn't address my primary concern, regarding handling the replay window issue by managing it intelligently (and if this was addressed in the archives, I apologize, I must have missed it). If you don't need to address the issue by using multiple SAs, I think a great deal of complexity will fall out of the protocol. Just one SA at a time between two peers, no need to sort out the semantics of sending REAs with updates with or without NESs or in notifies, etc. Also, fewer SAs means less load on a hosts kernel memory usage and fewer cycles spent managing the SAD. > > In -01 replacing SPI was the only way of performing > return routability check. However, the intention of > the new text in -02 is to allow using UPDATE as an > alternative. > > The rationale for combining SPI change and RR > was actually simplicity. If you have any middle boxes > in your route, you have to tell the middle boxes about > your SPIs anyway. Furthermore, you may loose quite > a lot of traffic while you change your network attachment. > Resetting your SPI makes the protocol more robust. I'm not following you here - how does it make the protocol more robust? > > Anyway, the intention of the -02 text is to be more > flexible, and allow you to continue using the same > SA and SPI. But you still need to send the SPIs both > ways so that middle boxes can learn them. I understand. How does this work in the 02-pre1 draft when the REA does not accompany a NES? <...> >> So perhaps dropping the unverified and deprecated states >> might be a better approach. > > Well, I guess we need to change the language here. The > section already starts with "In a _typical_ implementation," > > Do you have a suggestion on how to make the text > more clear that it is really up to you what you > implement, as long as the external behaviour *could* > be implemented in the way described in the draft? I think Tom's suggestion of just making the deprecated state an implementation option would be better. <...> > >> This probe can also be used >> to estimate RTTs for each path, which can then be used to >> set the ESP replay window. The path RTTs can also be fed >> to transport protocols. > > As far as I see, there is nothing in the draft that > prevents you from implementing it in this way. > > Would you like to write an appendix where you describe > some of these implementation options? The text Tom > provided is fine, but I don't see why we should > include it in the protocol proper? Is there some reason? > Or could it be in an appendix? Well, the issue of whether it should be in the protocol proper or in an appendix depends on whether you use multiple SAs or an RTT estimate to manage the replay window. If the latter, it should be in the protocol, IMHO. I am also concerned about overloading messages too much. We have 255 message types to play with, so adding a heartbeat message for clarity might not hurt too much (and shouldn't necessitate too much extra code). But I think we need to resolve the primary focus of this thread first - if I am convinced that using multiple SAs is necessary and good, then I don't think heartbeats will be necessary (but maybe optional? Need to think about that more...) <...> > > A piece of history: When I started to think about using > ESP traffic as implicit ack, I found it ugly and originally > rejected it. (It was present already in some of the early > drafts by Bob M.) However, my mind has slowly changed. > Especially when I realised that you don't need to have > any triggers from ESP. It is sufficient that you poll > your ESP to see if there has been any traffic. That > can be implemented easily: you get a timeout, you poll, > and you process the result of the poll either as an > ack (if there had been traffic) or timeout (if there > had not been any traffic). Yes, this is the way I have implemented it. I still find it ugly, though... <...> > >> ... there is no such >> mechanism in place to ensure the the RR reply gets >> best effort delivery (whether it be data or a HIP TLV). >> If it gets lost, the address verification is left in limbo. > > Is this a problem? The address will stay in UNVERIFIED > state, and you will need to re-initiate return routability > on that if you intend to use the address. > > I don't see where you have a problem here. But perhaps I'm > missing something? What about the case where a MN moves and gets a new CoA. It sends its peer an REA with the new CoA as the new preferred address. The RR fails due to a dropped packet. Now the peer host cannot communicate with the MN since the only verified address it has is the MN's old CoA. Detecting that the old address is unreachable could take some time, during which all packets to the MN are lost. <...> > > >> If a peer's address is a CGA and can be verified against >> the peer's public key, can we skip RR? > > In general, no. Flooding is not only about flooding > hosts, it is also about flooding subnets. CGA doesn't > prevent you from generating CGAs for subnets where you > aren't. > How would subnet flooding work? If a host isn't on the subnet, ndisc or arp will fail and the router won't put the packets on the subnet, right? From jonwood@speakeasy.net Tue Apr 20 14:05:06 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Tue Apr 20 13:05:06 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406059F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406059F@xch-nw-27.nw.nos.boeing.com> Message-ID: On Apr 16, 2004, at 6:33 PM, Henderson, Thomas R wrote: <...> > In the new draft I just sent around, it is explicitly > stated that the main reason a host may want new SAs is > due to replay window. However, it also says that it is > up to the host whether to generate new SAs upon a readdress > event-- i.e., REA is decoupled from NES in the proposed > draft. > OK, I think this is better. <...> >> So perhaps dropping the unverified and deprecated states >> might be a better approach. All addresses are verified >> for return routability (if policy dictates) upon receipt. > > It seems like you are really only arguing for dispensing > with DEPRECATED. DEPRECATED state seems implicitly to > me to be an implementation option-- maybe it should be > an explict MAY? This sounds like a better way to handle it. <...> > > See the new draft. I think there are a couple of ways that > REA could occur, depending on the circumstances: > > 1. > REA in NOTIFY > -----------------> > (recipient does nothing-- trusted host) What happens if the NOTIFY packet is lost? > > 2. > REA in UPDATE > -----------------> > UPDATE (reply) > <---------------- (recipient does nothing but reply (ack) the REA OK. > > 3. > REA in NOTIFY > ----------------> > UPDATE > <--------------- (recipient wants a RR check on the address) > UPDATE (reply) > ----------------> OK - the UPDATE will be retransmitted if no reply comes back, right? > > 4. REA in NOTIFY > ----------------> > UPDATE (NES) > <--------------- (recipient wants a RR check and a new SA) > UPDATE (reply) > ----------------> Same as 3. > > 5. REA in UPDATE > -----------------> > UPDATE (reply) > <----------------- (recipient must ack first UPDATE before sending own > RR check/NES) > UPDATE (NES) > <----------------- > UPDATE (reply) > -----------------> > > (at least, that is what I was hoping for in the proposed > new draft-- to have this flexibility). > >> >> A Security Consideration >> ------------------------ >> Currently the drafts with allow a peer to add an >> unlimited number of addresses to an assocation. This could >> open a window to an attack where a host attempts to >> exhaust its peer's memory resources by adding lots of >> addresses. HIP implementations should allow administrators >> to place limits on the number of peer addresses added. >> However, when the limit is reached, will we need some >> protocol mechanism to inform the peer that the address >> addition has been rejected? >> > > This could be in the new NOTIFY mechanism. Yes, I need to review the upcoming NOTIFY text. From thomas.r.henderson@boeing.com Tue Apr 20 19:55:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 20 18:55:00 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605B3@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Tuesday, April 20, 2004 10:50 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Comments on draft-nikander-hip-mm > > > Anyway, the intention of the -02 text is to be more > > flexible, and allow you to continue using the same > > SA and SPI. But you still need to send the SPIs both > > ways so that middle boxes can learn them. >=20 > I understand. How does this work in the 02-pre1 draft > when the REA does not accompany a NES? >=20 > <...> This is indeed a problem-- the 02-pre1 draft needs to be fixed to accommodate middleboxes in the most general scenario. Basically, one-way REAs won't work unless REA=20 were to have additional info on the reverse direction--=20 which is probably not the best idea. > > > >> This probe can also be used > >> to estimate RTTs for each path, which can then be used to > >> set the ESP replay window. The path RTTs can also be fed > >> to transport protocols. > > > > As far as I see, there is nothing in the draft that > > prevents you from implementing it in this way. > > > > Would you like to write an appendix where you describe > > some of these implementation options? The text Tom > > provided is fine, but I don't see why we should > > include it in the protocol proper? Is there some reason? > > Or could it be in an appendix? >=20 > Well, the issue of whether it should be in the protocol proper > or in an appendix depends on whether you use multiple SAs > or an RTT estimate to manage the replay window. If the latter, > it should be in the protocol, IMHO. I am also concerned about > overloading messages too much. We have 255 message types > to play with, so adding a heartbeat message for clarity might > not hurt too much (and shouldn't necessitate too much extra > code). But I think we need to resolve the primary focus of this > thread first - if I am convinced that using multiple SAs is necessary > and good, then I don't think heartbeats will be necessary (but maybe > optional? Need to think about that more...) >=20 How to use RTT estimates seems to me to be an issue that, if covered in=20 detail, does not affect interoperability (similar to cookie generation)=20 and may be best handled in an appendix or separate informational draft. = I think that feeding RTT estimates and other info to transport protocols is beyond our scope right now. In general, I am hoping that a loose enough replay window will suffice for most mobility situations, but being able to use multiple SAs seems to be necessary and good. UPDATE + ECHO_REQUEST/RESPONSE (both within signature) could be used to implement the heartbeat-- or another message (I agree that the bits in the type field are there).=20 > > > >> ... there is no such > >> mechanism in place to ensure the the RR reply gets > >> best effort delivery (whether it be data or a HIP TLV). > >> If it gets lost, the address verification is left in limbo. > > > > Is this a problem? The address will stay in UNVERIFIED > > state, and you will need to re-initiate return routability > > on that if you intend to use the address. > > > > I don't see where you have a problem here. But perhaps I'm > > missing something? >=20 > What about the case where a MN moves and gets a new CoA. > It sends its peer an REA with the new CoA as the new preferred > address. The RR fails due to a dropped packet. Now the peer > host cannot communicate with the MN since the only verified > address it has is the MN's old CoA. Detecting that the old address > is unreachable could take some time, during which all packets > to the MN are lost. So in a mobility situation, send the REA in an UPDATE, which is timer protected. REA + NOTIFY would only be useful in cases for which you don't care as much about reliability (e.g., backup addresses in multihoming), but in light of the middlebox problems, maybe REA + NOTIFY should be deprecated. From thomas.r.henderson@boeing.com Tue Apr 20 19:55:05 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Apr 20 18:55:05 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605B4@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Tuesday, April 20, 2004 10:55 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Comments on draft-nikander-hip-mm >=20 > > > > See the new draft. I think there are a couple of ways that > > REA could occur, depending on the circumstances: > > > > 1. > > REA in NOTIFY > > -----------------> > > (recipient does nothing-- trusted host) >=20 > What happens if the NOTIFY packet is lost? NOTIFY is a one-way, best-effort packet. >=20 > > > > 2. > > REA in UPDATE > > -----------------> > > UPDATE (reply) > > <---------------- (recipient does nothing but reply (ack) the REA >=20 > OK. >=20 > > > > 3. > > REA in NOTIFY > > ----------------> > > UPDATE > > <--------------- (recipient wants a RR check on the address) > > UPDATE (reply) > > ----------------> >=20 > OK - the UPDATE will be retransmitted if no reply comes back, right? >=20 Yes. From pekka.nikander@nomadiclab.com Wed Apr 21 01:33:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Apr 21 00:33:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605AE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605AE@xch-nw-27.nw.nos.boeing.com> Message-ID: >>> However, could you explain why Birthday is 96 bits? .. >> >> Just alignment. 32 bits may not be enough for busy servers .. >> >> If we want to save some bytes, maybe we could combine BIRTHDAY >> to the DIFFIE_HELLMAN parameter? > > It is fine with me to keep it in a separate TLV-- my main objection > was 96 bits, which seemed excessive and more difficult to implement > and handle. I still don't see a requirement for larger than 32 bits, > but I see that this was originally 64 bits in draft-moskowitz-hip-05. I'm fine with reducing birthday back to 64 bits, making the 32 bits reserved: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved, 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Pekka From petri.jokela@nomadiclab.com Wed Apr 21 03:07:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Apr 21 02:07:00 2004 Subject: [Hipsec] ICMP vs. NOTIFY Message-ID: <40861A76.6000505@nomadiclab.com> In base HIP, 5.2 Refusing a HIP exchange, it is defined that in case of policy not permitting HIP negotiation, the host responds to an I1 with ICMP "Destination Unreachable, Administrateively Prohibited" message. Now, we have defined a NOTIFY packet, giving the possibility to respond in the similar case with "BLOCKED_BY_POLICY" error. Still, it would be simpler (and safer) just to respond with an ICMP. Should the text be changed somehow, e.g.: " If the host's policy does not permit it to enter into a HIP exchange with the Initiator, it should send an ICMP 'Destination Unreachable, Administratively Prohibited' message or a NOTIFY packet with "BLOCKED_BY_POLICY" error type. One must note that a HIP packet may open more potential DoS attacks than a simple ICMP message. " -- 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 mkousa@cc.hut.fi Wed Apr 21 05:01:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Apr 21 04:01:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605AE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605AE@xch-nw-27.nw.nos.boeing.com> Message-ID: On Tue, 20 Apr 2004, Henderson, Thomas R wrote: -> > -----Original Message----- -> > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] -> > Sent: Tuesday, April 20, 2004 4:05 AM -> > To: Henderson, Thomas R -> > Cc: hipsec@honor.trusecure.com -> > Subject: Re: [Hipsec] Splitting the COOKIE parameters -> > -> > > -> > > However, could you explain why Birthday is 96 bits? This is likely -> > > cumbersome data type to support on the native system. Incrementing -> > > once per second, a 32 bit counter takes over 100 years to roll over. -> > -> > Just alignment. 32 bits may not be enough for busy servers and -> > such, otherwise it might be sufficient. -> > -> > If we want to save some bytes, maybe we could combine BIRTHDAY -> > to the DIFFIE_HELLMAN parameter? -> -> It is fine with me to keep it in a separate TLV-- my main objection -> was 96 bits, which seemed excessive and more difficult to implement -> and handle. I still don't see a requirement for larger than 32 bits, -> but I see that this was originally 64 bits in draft-moskowitz-hip-05. I would also like if it would be some more common type than a 96 bit number, eg. a 64 bit number. By the way, why is Update ID now a 24 bit number as you proposed in your mail "hip-mm proposed revisions" a couple of days ago ? Why it should be changed from 16 bit to 24 bit ? This has the same issue as previous 96 bit vs. 64 bit. I wouldn't be so surprised if different handling of 24 bit number would cause some problems during the interops. Do you really see that there will be 2^96 UPDATEs in a short period of time or what was the reasoning behind moving to 24 bits ? From thomas.r.henderson@boeing.com Wed Apr 21 13:08:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Apr 21 12:08:00 2004 Subject: [Hipsec] Splitting the COOKIE parameters Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605B7@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Wednesday, April 21, 2004 1:50 AM > To: hipsec@honor.trusecure.com > Subject: RE: [Hipsec] Splitting the COOKIE parameters >=20 >=20 >=20 > By the way, why is Update ID now a 24 bit number as you=20 > proposed in your > mail "hip-mm proposed revisions" a couple of days ago ? Why=20 > it should be > changed from 16 bit to 24 bit ? This has the same issue as=20 > previous 96 bit > vs. 64 bit. I wouldn't be so surprised if different handling of 24 bit > number would cause some problems during the interops. Do you=20 > really see > that there will be 2^96 UPDATEs in a short period of time or=20 > what was the > reasoning behind moving to 24 bits ? There is no particular reason-- just that the bits were available. =20 It could be 16 bits (or fewer). But it shouldn't be an=20 interoperability issue whichever is decided-- it is easy to implement. Tom From jonwood@speakeasy.net Wed Apr 21 20:50:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Wed Apr 21 19:50:01 2004 Subject: [Hipsec] DH 384-bit group Message-ID: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> Is there a reference for the Diffie-Hellman 384-bit group (section 6.2.5 in 10-pre1)? I couldn't find any mention of it in the likely sources (OAKLEY and "More MODP DH groups"). Thanks From mkousa@cc.hut.fi Thu Apr 22 05:09:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Apr 22 04:09:01 2004 Subject: [Hipsec] DH 384-bit group In-Reply-To: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> References: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> Message-ID: On Wed, 21 Apr 2004, Jonathan Wood wrote: -> Is there a reference for the Diffie-Hellman 384-bit group -> (section 6.2.5 in 10-pre1)? I couldn't find any mention of -> it in the likely sources (OAKLEY and "More MODP DH groups"). See http://honor.trusecure.com/pipermail/hipsec/2003-December/000341.html From jonwood@speakeasy.net Thu Apr 22 15:48:03 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Apr 22 14:48:03 2004 Subject: [Hipsec] NOTIFY in response to I1 Message-ID: <8497FA23-9494-11D8-865C-0003930D291E@speakeasy.net> There are a few situations where a NOTIFY might be sent in response to an I1 (i.e. BLOCKED_BY_POLICY, INVALID_MAJOR_VERSION, CHECKSUM_FAILED). At this stage, the initiator probably won't have the responders public key, just its HIT. So the initiator will not be able to verify the signature in the NOTIFY. To handle this, do we need a HOST_ID in the NOTIFY as well? From jonwood@speakeasy.net Thu Apr 22 15:49:00 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Apr 22 14:49:00 2004 Subject: [Hipsec] DH 384-bit group In-Reply-To: References: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> Message-ID: On Apr 22, 2004, at 1:58 AM, Mika Kousa wrote: > On Wed, 21 Apr 2004, Jonathan Wood wrote: > > -> Is there a reference for the Diffie-Hellman 384-bit group > -> (section 6.2.5 in 10-pre1)? I couldn't find any mention of > -> it in the likely sources (OAKLEY and "More MODP DH groups"). > > See > http://honor.trusecure.com/pipermail/hipsec/2003-December/000341.html > OK, thanks. Do we need to add an issue for this in the issue tracker? From petri.jokela@nomadiclab.com Thu Apr 22 16:04:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 22 15:04:01 2004 Subject: [Hipsec] DH 384-bit group In-Reply-To: References: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> Message-ID: <408822CA.3060407@nomadiclab.com> Jonathan Wood wrote: > > On Apr 22, 2004, at 1:58 AM, Mika Kousa wrote: > >> On Wed, 21 Apr 2004, Jonathan Wood wrote: >> >> -> Is there a reference for the Diffie-Hellman 384-bit group >> -> (section 6.2.5 in 10-pre1)? I couldn't find any mention of >> -> it in the likely sources (OAKLEY and "More MODP DH groups"). >> >> See http://honor.trusecure.com/pipermail/hipsec/2003-December/000341.html >> > > OK, thanks. Do we need to add an issue for this in the issue tracker? Might be a good idea :-) /petri From petri.jokela@nomadiclab.com Thu Apr 22 16:14:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 22 15:14:02 2004 Subject: [Hipsec] DH 384-bit group In-Reply-To: <408822CA.3060407@nomadiclab.com> References: <8A1A94E0-93F5-11D8-AD45-0003930D291E@speakeasy.net> <408822CA.3060407@nomadiclab.com> Message-ID: <40882504.2090004@nomadiclab.com> Petri Jokela wrote: >>> See >>> http://honor.trusecure.com/pipermail/hipsec/2003-December/000341.html >>> >> >> OK, thanks. Do we need to add an issue for this in the issue tracker? > > > Might be a good idea :-) (I was too fast with my mouse, sorry) Issue added to the tracker. What we now need is the actual generation of the 384-bit DH group. How shall we proceed with this issue? /petri From petri.jokela@nomadiclab.com Fri Apr 23 08:14:05 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Apr 23 07:14:05 2004 Subject: [Hipsec] Base HIP: 10-pre2 available Message-ID: <4089061C.90102@nomadiclab.com> I uploaded 10-pre2 version to our server: http://hip4inter.net/drafts.php There are text and html versions as well as diffs from 09 and 10-pre1. Some notes and questions: REJECT mechanism (NOTIFY): We should probably define more detailed the data that should be included in the Notification data field with each of the error types. New parameters in 6.2, HIP parameters, we have now allocated all values up to 13. Should there be left more space or not? And is the current order of TLVs ok? RESYNC mechanism changed. Birthday changed. Cookie mechanism changed. We have now opaque data in two locations: PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have it in two places? /petri From thomas.r.henderson@boeing.com Sat Apr 24 14:16:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Apr 24 13:16:01 2004 Subject: [Hipsec] NOTIFY in response to I1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605C3@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net] > Sent: Thursday, April 22, 2004 12:38 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] NOTIFY in response to I1 >=20 >=20 >=20 > There are a few situations where a NOTIFY might be > sent in response to an I1 (i.e. BLOCKED_BY_POLICY, > INVALID_MAJOR_VERSION, CHECKSUM_FAILED). >=20 > At this stage, the initiator probably won't have the > responders public key, just its HIT. So the initiator > will not be able to verify the signature in the NOTIFY. >=20 > To handle this, do we need a HOST_ID in the NOTIFY > as well? > It seems reasonable to allow HOST_ID to be a parameter in a NOTIFY. We will need at some point to work out the issues regarding how these various NOTIFYs should be crafted. =20 Tom=20 From thomas.r.henderson@boeing.com Sat Apr 24 14:34:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Apr 24 13:34:01 2004 Subject: [Hipsec] ICMP vs. NOTIFY Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04521B9E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Tuesday, April 20, 2004 11:54 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] ICMP vs. NOTIFY >=20 >=20 > " > If the host's policy does not permit it to enter into a HIP > exchange with the Initiator, it should send an ICMP > 'Destination Unreachable, Administratively Prohibited' > message or a NOTIFY packet with "BLOCKED_BY_POLICY" error type. > One must note that a HIP packet may open more potential DoS > attacks than a simple ICMP message. > " >=20 > I think that is a good suggestion. It may be that the HIP NOTIFY is most useful in less critical situations but that ICMP might be=20 favored in a more hardened system. Tom=20 From Julien.Laganier@Sun.COM Mon Apr 26 13:57:03 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Apr 26 12:57:03 2004 Subject: [Hipsec] ECHO_* and HMAC for FROM and TO authentication (Was: Base HIP: 10-pre2 available) In-Reply-To: <4089061C.90102@nomadiclab.com> References: <4089061C.90102@nomadiclab.com> Message-ID: <200404261852.09778.julien.laganier@sun.com> On Friday 23 April 2004 14:03, Petri Jokela wrote: > I uploaded 10-pre2 version to our server: > > Cookie mechanism changed. We have now opaque data in two locations: > PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have it in > two places? Related to Petri's question, I was wondering if an opaque data field should be present in the FROM/TO parameters used while a RVS is involved in a HIP exchange, or should we re-use ECHO_REQ/REP instead? Also, the HMAC field included in FROM/TO parameters might be replaced by a stand-alone HMAC parameter added after FROM/TO. What do you think? Thanks, --julein From pekka.nikander@nomadiclab.com Tue Apr 27 04:06:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 03:06:00 2004 Subject: [Hipsec] ECHO_* and HMAC for FROM and TO authentication In-Reply-To: <200404261852.09778.julien.laganier@sun.com> References: <4089061C.90102@nomadiclab.com> <200404261852.09778.julien.laganier@sun.com> Message-ID: <5AE51FA8-9820-11D8-9A63-000393CE1E8C@nomadiclab.com> >> Cookie mechanism changed. We have now opaque data in two locations: >> PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have it in >> two places? > > Related to Petri's question, I was wondering if an opaque data field > should be present in the FROM/TO parameters used while a RVS is > involved in a HIP exchange, or should we re-use ECHO_REQ/REP instead? That is a matter of taste. But see below. > Also, the HMAC field included in FROM/TO parameters might be replaced > by a stand-alone HMAC parameter added after FROM/TO. What do you > think? The intended semantics of HMAC are different. Additionally, the current HMAC is designed to be located before the signatures, while TO and FROM are designed to be placed after the signature. Yes, we could add a new HMAC type that comes after the signatures. However, for the time being I would like to have the HMAC field explicitly in FROM/TO. Besides, their design has not been finalised. More generally, this seems to be yet another occasion where we have to find the balance between simplicity and flexibility. Parameters that serve one purpose are easier to process, in general, than cases where one must first process multiple parameters and is only then able to act. On the other hand, if the same data type is clearly needed for multiple purposes, then it makes sense to generalise it, even on the cost of some added complexity. Considering this, the case of having an opaque data blob in the TO/FROM depends heavily on how the blob is being planned to be used, and how much complexity it would add to separate it to the ECHO_* parameters. My current feeling is that it would probably be easier to have the separate opaque blob there. Doing so most probably makes it easier to handle received TO parameters. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 04:26:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 03:26:01 2004 Subject: [Hipsec] ICMP vs. NOTIFY In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04521B9E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04521B9E@xch-nw-27.nw.nos.boeing.com> Message-ID: <1B106E60-9823-11D8-9A63-000393CE1E8C@nomadiclab.com> >> If the host's policy does not permit it to enter into a HIP >> exchange with the Initiator, it should send an ICMP >> 'Destination Unreachable, Administratively Prohibited' >> message or a NOTIFY packet with "BLOCKED_BY_POLICY" error type. >> One must note that a HIP packet may open more potential DoS >> attacks than a simple ICMP message. > I think that is a good suggestion. It may be that the HIP NOTIFY > is most useful in less critical situations but that ICMP might be > favored in a more hardened system. I agree. However, I am somewhat worried about replying to I1 packets with anything else but with R1 or ICMP. For reasons that I can't really spell out (and hence don't really count), I don't like the NOTIFY much. I think it may be fine when you reply to an I2 that has already been partially verified, but responding to an I1 seems risky. Personally, I would like to remove some of the error types, and make same kind of functionality in ICMP level. The ones that I would like to weed are the following: INVALID_MAJOR_VERSION INVALID_COOKIE_SOLUTION What comes to the rest, I would specify that a Responder sends a NOTIFY only if it has successfully validated the puzzle solution. In response to I1 or to an I2 with an invalid puzzle solution, the Responder would reply with an ICMP. In some early version of the draft (or the architecture draft) there was lengthy discussion why NOTIFY is not very usable, and why it is better to send ICMP or just let the Initiator retry after timeout. While that discussion may still appear somewhere (I didn't check for this message) and while it is mostly true from a pure security point of view, it definitely makes debugging and some operational matters hard. Hence, NOTIFY after a good puzzle solution seems like a good compromise, to me. If others agree, the next question is then about ICMP error types. In the IPv6 world, we could use Parameter Problem (Type 4), Code 0 (erroneous header field encountered) for INVALID_MAJOR_VERSION, by making the pointer to point to the HIP version number in the HIP header. INVALID_COOKIE_SOLUTION can be handled in the same way. There we just set the pointer to point to the puzzle solution field in the SOLUTION parameter. In the IPv4 world, the situation is harder. Parameter Problem (Type 12) could still be used, but 64 bits (8 bytes) of the original datagram are not sufficient for INVALID_COOKIE_SOLUTION; it does suffice for INVALID_MAJOR_VERSION, though. An idea: What if we define a new control, INVALID_COOKIE_SOLUTION? The Controls field still fits within the 64 bits returned in ICMPv4. In that way the ICMP message could contain the first 8 bytes of the original HIP message (actually more to include the HITs), and the control would indicate that the packet was dropped because the cookie solution didn't verify. Thoughts? --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 04:28:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 03:28:00 2004 Subject: [Hipsec] NOTIFY in response to I1 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605C3@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605C3@xch-nw-27.nw.nos.boeing.com> Message-ID: <749A4BD3-9823-11D8-9A63-000393CE1E8C@nomadiclab.com> >> There are a few situations where a NOTIFY might be >> sent in response to an I1 (i.e. BLOCKED_BY_POLICY, >> INVALID_MAJOR_VERSION, CHECKSUM_FAILED). As I wrote in a separate message, IMHO a Responder SHOULD never respond with a NOTIFY to an I1. There we should use ICMP instead. But then we come to more trusted environments. There constructing a NOTIFY (and even signing it -- gulp) may make sense. So ... > It seems reasonable to allow HOST_ID to be a parameter > in a NOTIFY. We will need at some point to work out > the issues regarding how these various NOTIFYs should > be crafted. ... I agree that it may be good to allow a HOST_ID in a NOTIFY packet, just for the case. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 07:13:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 06:13:00 2004 Subject: [Hipsec] MM#2: Middle box issues In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605B3@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605B3@xch-nw-27.nw.nos.boeing.com> Message-ID: <65489FEE-983A-11D8-9A63-000393CE1E8C@nomadiclab.com> After a long delay, I've now eventually managed to start creating issues on the mobility and multi-homing draft in roundup. See http://hip4inter.net/cgi-bin/roundup.cgi/hip-mm/ >>> Anyway, the intention of the -02 text is to be more >>> flexible, and allow you to continue using the same >>> SA and SPI. But you still need to send the SPIs both >>> ways so that middle boxes can learn them. >> >> I understand. How does this work in the 02-pre1 draft >> when the REA does not accompany a NES? >> >> <...> > > This is indeed a problem-- the 02-pre1 draft needs to be > fixed to accommodate middleboxes in the most general > scenario. Basically, one-way REAs won't work unless REA > were to have additional info on the reverse direction-- > which is probably not the best idea. I've given this middle box issue the tracking number #2. Tom, Jon and I are trying to work this out in private. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 07:15:06 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 06:15:06 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605B3@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605B3@xch-nw-27.nw.nos.boeing.com> Message-ID: > How to use RTT estimates seems to me to be an issue that, if covered in > detail, does not affect interoperability (similar to cookie generation) > and may be best handled in an appendix or separate informational draft. Agreed. > I think that feeding RTT estimates and other info to transport > protocols > is beyond our scope right now. IMHO they are definitely beyond the scope of WG work. However, I'm interested to see some work on this at the RG side. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 07:25:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 06:25:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <227711A6-92F3-11D8-93E5-0003930D291E@speakeasy.net> References: <6D8DF625-9165-11D8-AC5A-000393CE1E8C@nomadiclab.com> <227711A6-92F3-11D8-93E5-0003930D291E@speakeasy.net> Message-ID: <237C0396-983C-11D8-9A63-000393CE1E8C@nomadiclab.com> > However, you didn't address my primary concern, regarding > handling the replay window issue by managing it intelligently > (and if this was addressed in the archives, I apologize, I must > have missed it). If you don't need to address the issue by > using multiple SAs, I think a great deal of complexity will fall > out of the protocol. Just one SA at a time between two peers, > no need to sort out the semantics of sending REAs with updates > with or without NESs or in notifies, etc. Also, fewer SAs means > less load on a hosts kernel memory usage and fewer cycles > spent managing the SAD. I am pretty pessimistic about being able to handle replay window under all imaginable situations. What if you want to use, for some strange reason, GPRS and 50 Mbps WLAN at the same time? During the 900 ms RTT on the GPRS side you can send some 5 Mbytes of data over the WLAN. Is it acceptable, from the security point of view, to have that lax replay window? Don't you easily open vulnerabiliites in some non-idempotent operations in some UDP based application protocols. Implementing multiple SA support right is tricky, I agree. But it still looks about an order of magnitude easier to me than properly getting dynamic replay window management right. >> The rationale for combining SPI change and RR >> was actually simplicity. If you have any middle boxes >> in your route, you have to tell the middle boxes about >> your SPIs anyway. Furthermore, you may loose quite >> a lot of traffic while you change your network attachment. >> Resetting your SPI makes the protocol more robust. > > I'm not following you here - how does it make the protocol > more robust? When you reset your SA, you don't have replay window problems with possibly lost larger amounts of data. Remember, IPsec doesn't resent data, ever. If you run loose of your replay window, you are lost. You have to renegotiate you SA. I agree that running out of replay window is something that should be avoided. However, if you have a fat pipe and get disconnected for a couple of seconds, that may happen, since your replay window may be just a few milliseconds on a fat pipe. We have to deal with a conflict of interest here. The security requirements (and policy) dictate that the replay window should be small. If we need to widen it due to mobility requirements, that may not be acceptable, depending on the security policy. > I think Tom's suggestion of just making the deprecated > state an implementation option would be better. Text/diff against -02-pre1, please? >> In general, no. Flooding is not only about flooding >> hosts, it is also about flooding subnets. CGA doesn't >> prevent you from generating CGAs for subnets where you >> aren't. > > How would subnet flooding work? If a host isn't on the subnet, > ndisc or arp will fail and the router won't put the packets on the > subnet, right? You flood the pipe leading to the router. --Pekka From pekka.nikander@nomadiclab.com Tue Apr 27 07:30:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Apr 27 06:30:03 2004 Subject: [Hipsec] MM#3: Allowing data on new SPI to finish the RR test In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605A3@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605A3@xch-nw-27.nw.nos.boeing.com> Message-ID: >> This was (and still is) an important optimisation, IMHO. >> Of course, as Tom described, you don't need to initiate >> RR at the same time, you can just ack REA. >> >> Adding to the five scenarios Tom described, I still think >> that it is OK to implicitly finish RR with new traffic to >> a new SPI. However, I haven't had time to carefully >> read -02-pre1 to see what the text says, and if any >> changes are needed there. Hence, the reply UPDATEs >> in Tom's scenarions #3, #4 and #5 *MAY* be replaced >> with implicit traffic. In fact, IMHO in scenario #4 >> where a new SPI is created the reply update is really >> unnecessary. But apparently people's opinions >> differ on this. > > This optimization (skipping UPDATE response by sending > data on new SPI) is not contained in the text that I proposed. > Currently, UPDATE packet always causes an UPDATE reply. > > Conceptually, I like to save packets when possible, but > I wonder whether we can get by with the implicit ACK if > middleboxes are along the way. I think that you are > suggesting that we can't in all cases (you don't suggest > implicit ack in scenario 2, perhaps for this reason), but in > the other cases, we probably need to think more about > the packet processing rules as for when a host is allowed > to make that optimization. But I'm in favor of trying > to make that optimization work as long as it doesn't make > the state machine logic too ugly. > > Overall, the text that I proposed needs an iteration to > check for middlebox-friendliness of the potential > exchanges. I've assigned this separately issue #3, as allowing ESP data to ack is an issue separate from middle box friendliness. --Pekka From jonwood@speakeasy.net Wed Apr 28 22:39:00 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Wed Apr 28 21:39:00 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <237C0396-983C-11D8-9A63-000393CE1E8C@nomadiclab.com> References: <6D8DF625-9165-11D8-AC5A-000393CE1E8C@nomadiclab.com> <227711A6-92F3-11D8-93E5-0003930D291E@speakeasy.net> <237C0396-983C-11D8-9A63-000393CE1E8C@nomadiclab.com> Message-ID: On Apr 27, 2004, at 4:15 AM, Pekka Nikander wrote: > > I am pretty pessimistic about being able to handle replay > window under all imaginable situations. What if you want to > use, for some strange reason, GPRS and 50 Mbps WLAN at the > same time? During the 900 ms RTT on the GPRS side you > can send some 5 Mbytes of data over the WLAN. Is it acceptable, > from the security point of view, to have that lax replay window? > Don't you easily open vulnerabiliites in some non-idempotent > operations in some UDP based application protocols. > > Implementing multiple SA support right is tricky, I agree. > But it still looks about an order of magnitude easier to > me than properly getting dynamic replay window management > right. Hmm, OK... you make a good point that in some extreme cases there could be security problems. I'm not sure I agree that replay window management is as hard as you think it is, but this question is probably better addressed in a research context. I am still having some concerns about how I understand the multiple SA scheme to work. Your application selects an SA, in which is stored the destination address (actually, one or more destination addresses). In effect, you are conflating locators with security associations, and naming destinations by the SAs, not the locators. This seems harder for applications to deal with, and furthermore the conflation seems lossy - if you have a group of addresses bound to an SA, there is no guarantee that all addresses in the group represent the same path. It seems much more logical to me for multipathing applications to deal with locators than SAs. Having said that, however, this may just be an issue with the language of the proposal - could not an implementation have an augmented SPD that allows selection of an SA based on the ultimate IP address? > >>> The rationale for combining SPI change and RR >>> was actually simplicity. If you have any middle boxes >>> in your route, you have to tell the middle boxes about >>> your SPIs anyway. Furthermore, you may loose quite >>> a lot of traffic while you change your network attachment. >>> Resetting your SPI makes the protocol more robust. >> >> I'm not following you here - how does it make the protocol >> more robust? > > When you reset your SA, you don't have replay window > problems with possibly lost larger amounts of data. > Remember, IPsec doesn't resent data, ever. If you run > loose of your replay window, you are lost. You have to > renegotiate you SA. My knowledge of this aspect of IPsec is limited to reading the specs, so I'll take your word in it. However, I'm not clear on how you are lost if you run loose of your replay window - the ESP spec says that if a sequence number is to the right of the sliding window, (which is what would happen if you were disconnected briefly), you proceed with processing the packet. Would the subsequent ICV calc or decryption fail? Jon From thomas.r.henderson@boeing.com Thu Apr 29 15:49:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 29 14:49:00 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605E4@xch-nw-27.nw.nos.boeing.com> > Finally, due to the desire to make it possible for Alice > to make a difference between a replayed and fresh R1s, > I think that we need to retain the birthday parameter > even if we remove resynchronization out of the base spec, > and even make it stronger. Basically, it seems to me best > to increment birthday count whenever old R1s are not > accepted any more. This is apparently a change to the > current draft, and therefore probably requires opening > a new issue. [Petri, please.] (note, this also pertains to issue 22 resync) I am trying to reason through the current definition of birthday. =20 Originally, birthday was used in the following context: Initiator Responder (reboot) ------> data on SPI ! unknown SPI (have I rebooted?) <---- (send R1 with birthday count) ** here, initiator checks birthday count-- if larger, then drop existing SA and process R1-- otherwise ignore R1 Birthday was used in this context to protect against=20 R1 replay, since R1 was a packet that could be used to reset an existing SA-- therefore, a mischievous host could replay an R1 and get the two hosts to restart their HIP exchange. Additionally, Birthday was used when restarting state if SAs timed out. Therefore, Birthday was supposed to=20 be incremented upon system reboot and SA time outs. As far as I can tell, the main reason for needing this R1 replay protection was because the system was using=20 "unknown SPIs" as an implicit I1 packet. Now, we do not use unknown SPIs anymore as an implicit I1. So the original case does not apply anymore,=20 because the initiator will be in I1-SENT state if it legitimately receives an R1. If I get an R1 but am=20 not in I1-SENT, then I ignore it. If I think that I=20 have an established SA, I only resync it if I get a=20 new I2 from my peer. I only get an I2 from my peer=20 if it decided it wanted to resync with me-- I can use=20 the cookie rotation to assure that this is a current=20 I2, and signature and other fields to validate. Let's look at three cases when a host has data to send and the two hosts either have no state or=20 inconsistent state (e.g., one side rebooted or hard timeout of its SA) =20 i) neither party has HIP state ii) a system has no HIP state but its peer thinks that it does iii) a system has HIP state but its peer does not Assume also that we are also dealing with someone who can eavesdrop on the packets and potentially replay some of them, but not mangle, drop, or reorder them (in which case, all bets for a successful exchange are off) Case i) (normal HIP exchange) The only mischief that seems possible is that I1s or=20 R1s could be replayed, causing the initiator to get more than one R1, while in state I1-SENT or I2-SENT. Note that right now, as things are defined, a system only processes the first R1 and discards all later ones; this seems to be a problem. Birthday here=20 may be useful as an R1 freshness counter, if we allow hosts in I2-SENT to start over only if they=20 receive an R1 with a higher count-- this would protect against someone who sniffs the I1 and sends a replayed stale R1 to the initiator before the legitimate R1 can arrive. Case ii)=20 The host will send an I1, which will trigger an R1 from the peer, who is already ESTABLISHED. If=20 the resulting I2 passes cookie checks and signature,=20 then it means that the peer must want to reestablish=20 the SAs (resync). I do not see what additional=20 protection that birthday check affords-- seems=20 redundant with cookie rotation. =20 Case iii)=20 Data will be sent on an SPI that will be unknown to the peer. In this case, either the peer will drop it silently or send the HIP NOTIFY-- in either case, the local host will eventually kill off its local HIP state, start over, and we are back to case i). So in summary, it seems to me that birthday is really only useful as an R1 freshness counter so that the Initiator knows when to process an R1 when in state I2-SENT. In essence, this R1 counter is only needed because R1s are precomputed and stateless with respect to the I1. If my thinking is wrong, it would be useful to document the attack scenario clearly. And if people agree with the above, then we need to make some changes to R1 processing, and to the I2 processing perhaps when in state R2-SENT (because a new I2 based on newer R1=20 may be forthcoming). "Birthday" may be the wrong term for this counter. Thoughts? Tom From thomas.r.henderson@boeing.com Thu Apr 29 16:36:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 29 15:36:00 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605E6@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Wednesday, April 28, 2004 7:29 PM > To: Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Comments on draft-nikander-hip-mm >=20 > I am still having some concerns about how I understand > the multiple SA scheme to work. Your application > selects an SA, in which is stored the destination address > (actually, one or more destination addresses). In effect, > you are conflating locators with security associations, > and naming destinations by the SAs, not the locators. > This seems harder for applications to deal with, and > furthermore the conflation seems lossy - if you have a > group of addresses bound to an SA, there is no guarantee > that all addresses in the group represent the same path. > It seems much more logical to me for multipathing > applications to deal with locators than SAs. >=20 > Having said that, however, this may just be an issue > with the language of the proposal - could not an > implementation have an augmented SPD that allows > selection of an SA based on the ultimate IP address? >=20 I guess I don't see the applications selecting SAs, or that multipathing applications are dealing explicitly with either locators or SAs. I still envision transports or some other element of the system picking the locators or paths,=20 and the system finding the right SA envelope based on the=20 SPD entries. Maybe this is a terminology issue-- see if you agree with the below. In the HIP model, conceptually, packets are sent to other=20 hosts (i.e., to other HITs), which are resolved within the system to locators. The system stores a binding between=20 the locators and the HITs. The system also maintains one or more SAs for the host-host communications context. =20 In non-HIP IPsec, the outbound SPD is consulted until there=20 is a match on the selectors. The SPD either points to an SA bundle, or a new SA is dynamically created. The SA indicates the things needed to build the ESP packet, such as SPI. The HIP=20 model maps to RFC2401 IPsec architecture if you consider the HIT to be a "system name"-- then the SPD match can be based on HIT and not the addresses. =20 Without multiple SAs, the SPD matches on HIT. With multiple SAs, the SPD perhaps matches on other fields besides HITs, such as source and destination addresses (i.e., the addresses are no longer wildcarded). Therefore, the steps followed in outbound processing are i) locators are selected=20 (how they are selected if there is some choice is discussed below), and then ii) either the HIT or the combination of HIT and addresses are used to find the right SA. It is the job of the HIP process ("daemon") to manipulate both the locator/HIT bindings and the SPD/SA entries so that a) the system can select valid, current locators for the=20 host-host communications context, b) the packet hits the right=20 SA upon exiting the system, and c) SAs are updated as needed=20 (e.g., new SPI or keymat). REA and NES give the mechanism to do that (unambiguously, I think). It is currently out of the draft-mm scope to deal with=20 a) how a system picks locators in a communications context=20 when it has several from which to choose (assume that it picks the "default" or preferred ones for now), b) how it decides that a new SA is needed or replay window parameters are=20 manipulated, or c) how to deal with issues such as readdressing triggering a congestion window response at transport layer, or adjusting/rediscovering the MTU, etc., when locators change. =20 Tom From jonwood@speakeasy.net Thu Apr 29 18:59:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Apr 29 17:59:01 2004 Subject: [Hipsec] Comments on draft-nikander-hip-mm In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605E6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605E6@xch-nw-27.nw.nos.boeing.com> Message-ID: <829B916C-9A2F-11D8-8F9C-0003930D291E@speakeasy.net> Hi Tom, On Apr 29, 2004, at 1:26 PM, Henderson, Thomas R wrote: > > I guess I don't see the applications selecting SAs, or > that multipathing applications are dealing explicitly with > either locators or SAs. I still envision transports or some > other element of the system picking the locators or paths, > and the system finding the right SA envelope based on the > SPD entries. Maybe this is a terminology issue-- see if > you agree with the below. > > In the HIP model, conceptually, packets are sent to other > hosts (i.e., to other HITs), which are resolved within the > system to locators. The system stores a binding between > the locators and the HITs. The system also maintains one or > more SAs for the host-host communications context. > > In non-HIP IPsec, the outbound SPD is consulted until there > is a match on the selectors. The SPD either points to an > SA bundle, or a new SA is dynamically created. The SA indicates > the things needed to build the ESP packet, such as SPI. The HIP > model maps to RFC2401 IPsec architecture if you consider the > HIT to be a "system name"-- then the SPD match can be based > on HIT and not the addresses. > > Without multiple SAs, the SPD matches on HIT. With multiple > SAs, the SPD perhaps matches on other fields besides HITs, > such as source and destination addresses (i.e., the addresses > are no longer wildcarded). Therefore, the steps followed > in outbound processing are i) locators are selected > (how they are selected if there is some choice is discussed > below), and then ii) either the HIT or the combination of > HIT and addresses are used to find the right SA. > > It is the job of the HIP process ("daemon") to manipulate > both the locator/HIT bindings and the SPD/SA entries so that > a) the system can select valid, current locators for the > host-host communications context, b) the packet hits the right > SA upon exiting the system, and c) SAs are updated as needed > (e.g., new SPI or keymat). REA and NES give the mechanism > to do that (unambiguously, I think). I agree with all this. I am concerned, however, that we are creating a solution before we really understand what the problem is. The portions you leave undefined (i.e. how applications and transport protocols use the mechanism) are, as you say below, indeed out of scope of this draft. However, they are, IMHO, what should be driving the solution. Since we don't understand the problem well, perhaps it (as well as the solution) would be better discussed in a research context... Anyway, there doesn't seem to be support for my point of view in the WG, so I won't push on it further. Jon > > It is currently out of the draft-mm scope to deal with > a) how a system picks locators in a communications context > when it has several from which to choose (assume that it picks > the "default" or preferred ones for now), b) how it decides > that a new SA is needed or replay window parameters are > manipulated, or c) how to deal with issues such as readdressing > triggering a congestion window response at transport layer, > or adjusting/rediscovering the MTU, etc., when locators change. > > Tom From jonwood@speakeasy.net Thu Apr 29 19:12:02 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Apr 29 18:12:02 2004 Subject: [Hipsec] MM: Using UPDATEs for RR Message-ID: <4708A8BE-9A31-11D8-8F9C-0003930D291E@speakeasy.net> Hi, I have a question about using UPDATEs without NES parameters (i.e. containing only the UPDATE-ID parameter) for RR. Is this method open to an attack where the attacker can (easily) guess the update ID and generate a valid UPDATE response? Since the update ID increases by one each time and starts at 1, it is easy to guess. For example: 1. MN sends CN a bogus address REA. 2. Peer sends MN an UPDATE request with the UPDATE_ID parameter (without a NES) to the bogus address. 3. MN waits a bit to give CN time to send the UPDATE request, guesses the update ID, and sends an UPDATE response to the CN. 4. Response looks OK to CN, so it starts using the bogus address. Or am I missing something? Jon From thomas.r.henderson@boeing.com Thu Apr 29 19:44:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Apr 29 18:44:01 2004 Subject: [Hipsec] MM: Using UPDATEs for RR Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605E8@xch-nw-27.nw.nos.boeing.com> Yes, it seems that RR should rely on an unguessable nonce exchange. Even having the NES with REA doesn't seem to fully protect: 1. MN sends CN a bogus address REA + NES in UPDATE request. 2. CN sends MN an UPDATE-response to new bogus address. 3. CN sends MN an UPDATE-request with NES to new bogus address. 4. MN waits a bit to give CN time to send the UPDATE request, guesses the update ID, and sends an UPDATE response to the CN. 5. Response looks OK to CN, so it starts using the bogus address. MN can't use CN's new inbound SPI, but it may not need to if CN is the one spewing data One way to plug this would be to require UPDATE-request NES to be=20 echoed in UPDATE-reply, since SPI has suitable randomness properties. This pretty much forces NES to be used with REA. Or else define some=20 other nonce mechanism for RR. Tom > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Thursday, April 29, 2004 4:02 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] MM: Using UPDATEs for RR >=20 >=20 >=20 > Hi, >=20 > I have a question about using UPDATEs without > NES parameters (i.e. containing only the UPDATE-ID > parameter) for RR. Is this method open to an attack > where the attacker can (easily) guess the update ID > and generate a valid UPDATE response? Since the > update ID increases by one each time and starts at > 1, it is easy to guess. >=20 > For example: >=20 > 1. MN sends CN a bogus address REA. > 2. Peer sends MN an UPDATE request with the > UPDATE_ID parameter (without a NES) to > the bogus address. > 3. MN waits a bit to give CN time to send the UPDATE > request, guesses the update ID, and > sends an UPDATE response to the CN. > 4. Response looks OK to CN, so it starts using the > bogus address. >=20 > Or am I missing something? >=20 > Jon >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From jonwood@speakeasy.net Fri Apr 30 14:16:00 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Apr 30 13:16:00 2004 Subject: [Hipsec] MM: Using UPDATEs for RR In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605E8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605E8@xch-nw-27.nw.nos.boeing.com> Message-ID: <240462C0-9AD1-11D8-8E2C-0003930D291E@speakeasy.net> On Apr 29, 2004, at 4:34 PM, Henderson, Thomas R wrote: > > One way to plug this would be to require UPDATE-request NES to be > echoed in UPDATE-reply, since SPI has suitable randomness properties. > This pretty much forces NES to be used with REA. Or else define some > other nonce mechanism for RR. > How about having the CN send a echo request tlv in the update reply, and having the MN respond with an update reply (to the update reply) containing an echo response? The echo can contain the nonce. This way, you could also compress the update reply and update request(RR) from the CN into one message. The drawback is that it does make the protocol a bit messier... Jon From thomas.r.henderson@boeing.com Fri Apr 30 17:06:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Apr 30 16:06:00 2004 Subject: [Hipsec] Base HIP: 10-pre2 available Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605EE@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, April 23, 2004 5:04 AM > To: hipsec@honor.trusecure.com > Cc: gonzalo.camarillo@ericsson.com; dward@cisco.com > Subject: [Hipsec] Base HIP: 10-pre2 available >=20 >=20 > I uploaded 10-pre2 version to our server: >=20 > http://hip4inter.net/drafts.php >=20 I provided Petri with a long list of comments and an edited version and diffs to his draft above. If anyone would like a copy of what I sent to Petri, please email me directly; otherwise, see the below summary. -Tom Section 1.1 - moved text on LSIs out of this section-- LSIs are not central to the on-the-wire protocol anymore and are handled in Section 3 Section 1.2 - a citation is needed for IKE=20 Section 3 - citation needed for DSA (not added) - added some sentences on HIT properties - move Section 3.4 to Section 4.6-- as it is more a protocol issue = rather=20 than an issue with respect to a Host Identifier Section 3.2 - replaced 1.0.0.0/8 with TBD, pending resolution of IANA issue Section 4.3 - changed reference to Section 8.10 Section 5 - changed title and did some wordsmithing of 5, 5.1, and 5.2 Section 5.2 - *** didn't do anything here, pending Birthday resolution Section 5.4 - *** R1 processing pending Birthday resolution - changed "REKEYING" state to "UPDATING" state Section 5.4.3 - simplified state diagram further Section 6.2 - a number of Length fields are incorrect Section 6.2.1=20 - "Length" field is poorly defined, it should be Length of Contents, not Length of parameter. Wordsmithing Section 6.2.3 - clarified that future revisions may allow multiple SPIs between hosts. Section 6.2.4 - *** pending resolution of Birthday - fixed Length Section 6.2.5 - Added statement that Opaque and I are left out of signature of R1 - fixed Length Section 6.2.6 - Added statement that Opaque is echoed - fixed Length Section 6.2.13 - Clarified which TLVs are covered by signature. Section 6.2.14 - Clarified which fields in PUZZLE are excluded from signature - Clarified which TLVs are covered by signature. Section 6.2.16 - Clarified that Update ID has scope within the HIP associaton only, and not across associations or across hosts Section 6.2.18 - deleted some Notify Message Types per suggestion by Pekka (not to use NOTIFY before puzzle completes) (INVALID_MAJOR_VERSION and INVALID_COOKIE_SOLUTION) Section 7.2 - *** Birthday pending resolution - Clarified that ECHO_REQUEST may fall outside signature Section 7.3 - Clarified that ECHO_REQUEST may fall outside signature Section 7.8 - Added HOST_ID as an optional parameter to NOTIFY Section 8.3.2 - Some wordsmithing of signature calculation rules to account for=20 TLVs that fall outside the signature. Section 8.4.1 - *** Resistance to R1 replay issue still pending issue Section 8.6 - *** Resistance to R1 replay issue still pending Section 8.11 (nothing changed here yet, but needs some major editing) Section 11 - XXX someone needs to add the BEET reference and fix up this first paragraph Section 13 - *** pending Birthday From thomas.r.henderson@boeing.com Fri Apr 30 17:07:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Apr 30 16:07:00 2004 Subject: [Hipsec] open issues for issue tracker Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605ED@xch-nw-27.nw.nos.boeing.com> Catching up on recent mail, it seems like we need a few more issues: [base] ICMP error types for problems that occur before cookie is = verified (message by PN on 4/27) [base] UPDATE message handling (Section 8.11) needs some work [base] Issue12 could be updated by recent messages by PN (4/10) and = myself (yesterday) on the subject. Birthday seems to only be an R1 = counter now, and Pekka suggested on 4/10 that it may be non-critical = parameter. Related to this is processing rules for multiple received = R1s (maybe separate issue?-- multiple R1s could be due to sending = multiple I1s in parallel-- Section 8.4.1) [base] are issues 23 (R2-sent state), 33 (new cookie design), 21 = (Reject/Notify), and 22 (Remove Resync) is closed state? Are people = happy with the new cookie? I know that there was some question about = the size of K being 24 bits vs. some other size. Here are some possible ones from Petri too: > REJECT mechanism (NOTIFY): We should probably define more=20 > detailed the=20 > data that should be included in the Notification data field=20 > with each of=20 > the error types. >=20 > New parameters in 6.2, HIP parameters, we have now allocated=20 > all values=20 > up to 13. Should there be left more space or not? And is the current=20 > order of TLVs ok? >=20 > RESYNC mechanism changed. >=20 > Birthday changed. >=20 > Cookie mechanism changed. We have now opaque data in two locations:=20 > PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have=20 > it in two=20 > places? >=20 [mm] address check RR design (raised by JW yesterday and today) [mm] use of multiple SAs (JW, 4/16 message) (note-- I have not addressed rendezvous server open issues-- maybe = another list?) Tom