From Jan.Melen@nomadiclab.com Sat Apr 2 04:55:03 2005 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Sat Apr 2 04:55:03 2005 Subject: [Hipsec] HIP4BSD source code Message-ID: <200504021254.06354.Jan.Melen@nomadiclab.com> Hi, There is now available new version of the HIP4BSD source code at http://www.hip4inter.net/ We have also a HIP test server running at our lab. The HIT of that server can be resolved from the AAAA record of either woodstock4.hip4inter.net or woodstock6.hip4inter.net. Naturally the woodstock4 resolves also as an IPv4 A record and woodstock6 resolves as an IPv6 AAAA record. On error during the base exchange an NOTIFY message will be sent and approriate error code is set. Both the code at hip4inter.net and the test server are implementing the draft-ietf-base-01 draft. Regards, Jan From julien.IETF@laposte.net Mon Apr 4 06:42:00 2005 From: julien.IETF@laposte.net (Julien Laganier) Date: Mon Apr 4 05:42:00 2005 Subject: [Hipsec] Rendezvous and tunneling In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> Message-ID: <200504041141.43963.julien.IETF@laposte.net> On Wednesday 30 March 2005 21:08, Henderson, Thomas R wrote: > -----Original Message----- > > So I have now three questions before I begin another pass of > > edition: > > > > 1) Should we get rid of I1_TUNNELING mode? > > > > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is > > the usage scenario you have in mind? > > > > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This > > is required to support double-movement in mobility scenarios. > > I am fine with 1 and 2. As for 3, note that the current mobility > draft does not address the double-jump problem from the client > side. Therefore, if UPDATE inclusion gets hairy (i.e., has DoS > issues), then I would not delay the RVS draft on account of that. > On the other hand, if it is a simple extension, then it will > probably be used by future mobility drafts. Ok, then I will proceed with (1) and (2). Regarding (3), I don't think there's is additional DoS issues we should be concerned about. Potentials attacks involving UPDATE relaying are likely to be less severe than those involving I1: The I1 relaying introduces reflexion and amplification (because R1 is larger than I1) attacks. The RVS draft defends against these attacks by HMACing packets relayed by the RVS, hence defending against malicious nodes, but not against malicious RVS. With UPDATEs relaying, the only attacks introduced are reflexion attacks: An UPDATE will trigger another UPDATE, which is about the same size. So I would say that we can specify UPDATE relaying, and that it is somewhat "easier" to secure than I1 relaying. I might be wrong though, and will appreciate if someone can confirm/infirm the above analysis. Thanks. --julien From pekka.nikander@nomadiclab.com Mon Apr 4 09:36:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Apr 4 08:36:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> Message-ID: Tom, >>> That describes the essential bit of what I was trying to get at by >>> proposing we just have a byte with one or two assigned code points. >>> So if we say this: >>> >>> If the prefix is 01000, >>> then the next 3 bits are the HA. >>> >>> If the prefix is something other than 01000, then the syntax and >>> semantics of the following bits (however many there may be) >>> are to be defined by future documents. >>> >>> that makes me happy. >> >> I'm happy with that, too. > > Can we make it 010, with five bits HA? Why that way? Why not five bit prefix and three HA? IMHO three bits for the hash algorithm should be enough at this point of time. What is your rational for this different allocation of the bits? I feel that I am lacking information here. From my point of view, 3 bits is more than enough for the hash algorithm (IMHO 2 bits would do), so I don't see any reason for making it longer. Secondly, making the prefix longer is good from a potential IANA allocation point of view. Sure, we could do a still longer prefix, e.g. /13, but that would then make the hash field considerably shorter and thereby less secure. In other words, IMHO we should either go with no prefix at all, and just use 3 bits for the hash algorithm, or then go to some reasonable long prefix, where 5 bits seems like a good choice considering various implementation issues and how hard it is likely to get an IANA allocation. We can certainly wait with the IANA allocation, but IMHO we should work towards one. That is the only way that I see for having "full" backwards compatibility at the IPv6 API, with channel bindings. --Pekka From thomas.r.henderson@boeing.com Mon Apr 4 10:42:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Apr 4 09:42:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AE0@xch-nw-27.nw.nos.boeing.com> =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, April 04, 2005 5:36 AM > To: Henderson, Thomas R > Cc: Tim Shepard; hipsec@honor.trusecure.com > Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20 > SHA1 broken? )=20 >=20 > Tom, >=20 > >>> That describes the essential bit of what I was trying to=20 > get at by=20 > >>> proposing we just have a byte with one or two assigned=20 > code points. > >>> So if we say this: > >>> > >>> If the prefix is 01000, > >>> then the next 3 bits are the HA. > >>> > >>> If the prefix is something other than 01000, then the=20 > syntax and > >>> semantics of the following bits (however many there may be) > >>> are to be defined by future documents. > >>> > >>> that makes me happy. > >> > >> I'm happy with that, too. > > > > Can we make it 010, with five bits HA? >=20 > Why that way? Why not five bit prefix and three HA? IMHO=20 > three bits for the hash algorithm should be enough at this=20 > point of time. What is your rational for this different=20 > allocation of the bits? =20 The rationale is simply to be able to more simply enumerate those prefixes that would collide with IPv6 address space. With five bits, it makes it longer to enumerate all of the possible collisions with that space-- unless one allows wildcards. For example, if I want to specify a different HIT space that covers all of the global unicast IPv6 addresses, with five bit prefix, I must enumerate a lot of possible prefixes. Maybe this is a non-issue, if wild card bits are supported in future prefix definitions. I was not thinking of 3 vs. 5 from an IANA allocation issue, nor do I think that 5 bits is needed for the hash algorithm.=20 Tom From pekka.nikander@nomadiclab.com Mon Apr 4 11:02:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Apr 4 10:02:00 2005 Subject: [Hipsec] Problems with the current mailing list situation Message-ID: Folks, I am primarily sending this to the people that read the archives and may be sending mail to the list without subscribing to it. In theory that should work, but in practise it does not work right now. All posts by people not on the list need to be approved by a moderator, and I happen to be that moderator. For a number of reasons I failed to handle the posts for a few weeks, with the result that there is currently about 350 mails queued in the moderator queue. Most, if not all, of that is spam. The only spam filter that we have had was me. Now, unfortunately, Safari fails to process the mailman admin web page any more, because it is so big. Or it does, but it gets so painfully slow that it is unusable in practise, taking several minutes to render the page, and then over a minute every time I click on some widget. Hence, right now I can't do anything to process the moderator queue, and it therefore just accumulates. As a result, if someone sends a legitimate message without being on the list, it will never get processed. I am sorry about the situation, but I don't have the cycles to do anything right now. We are in the process of moving the list to another host, but that hasn't happened yet. However, that doesn't help with the current queue, which most probably will remain unprocessed forever. --Pekka From pekka.nikander@nomadiclab.com Wed Apr 6 02:55:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Apr 6 01:55:00 2005 Subject: [Hipsec] Re: some questions regarding the update packet protocol In-Reply-To: <05aa01c53a1d$9877fc70$ef01a996@gmp> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648DDC@xch-nw-27.nw.nos.boein g.com> <03ae01c508b2$fcab8ff0$ef01a996@gmp> <3f8d4c130634edf9fd6c9e1e4f2c6c9a@nomadiclab.com> <045b01c50aee$28290bc0$ef01a996@gmp> <29b42c8fdcdd4feb74f9efff5f2f5f05@nomadiclab.com> <05aa01c53a1d$9877fc70$ef01a996@gmp> Message-ID: <7f880a546bb4532477491b9d250c6736@nomadiclab.com> Greg, [CC:n to the list as I think this belongs to the WG and raises important topics.] >> UPDATEs MAY be retransmitting without incrementing SEQ. ... > > How to process equal sequence numbers due (normally) to > retransmissions is > outlined in section 8.10.1. But what is the difference between > retransmission and a replay attack? Nothing as far as I can tell? IIRC, the intention is to say that as packets may get duplicated in the IP network anyway, also the sending host may send duplicate packets. For example, if the sender does not receive a corresponding ACK, it may resend an old, already signed packet instead of constructing a new packet and signing that. From the receiver's perspective, it is no different from receiving a recent packet multiple times. The receiver does not know if the packet has been duplicated in the net, is a replay attack attempt, or has been resent by the sender. Maybe the text needs to be clarified? > >> If the same >> subset of parameters is included in multiple UPDATEs with different >> SEQs, the host MUST ensure that receiver processing of the >> parameters >> multiple times will not result in a protocol error. > > I also don't understand that. Is that saying you have received the > same HIP > update packet with only the SEQ changed? So I can resend the same > update > packet with an incremented SEQ, yes? IIRC, the intention is just to clarify the semantics. For example, let say that we have a hypothetical payload "Increment a counter by one". Now, if you send two identical UPDATEs with the *same* SEQ, both containing the "increment a counter by one", the counter will be incremented once. However, if you send two UPDATEs with *different* SEQs but otherwise identical, the counter will be incremented twice. This is probably too obvious, and hence some text clarification might be needed. Suggestions? Or maybe we should write more text about the perhaps-obvious semantics issue that the sender must not assume anything about the receiver's state beyond acked UPDATEs. That is, if the sender has several pending updates out, the protocol must work correctly independent on which of the pending updates actually reach the receiver and in which order. > From the way update packets are processed and tracked, it seems that > clients > could easily bombard a service with HIP update packets that the client > only > created once but can resend many times. Of course, this can be done > already > in toiday's Internet but with HIP, if the signature is being checked, > this > will cause greater problems. One way to counter that is to remember some past received UPDATEs and any responses to them, and simply re-send the already existing response in the case of receiving a resent UPDATE. > I think their needs to be an update counter > that gets incremented with each update and decremented over time. > Once you > reach some threshold MAX_UPDATE_COUNT the receiver starts to send > challenges, maybe pre-made encrypted nonces for the update initiator to > decrypt, where the nonce must be sent back before any further update > packets > are processed. This is just an extension of the puzzle challenge idea > in > the base exchange onto the update packet protocol (make the initiator > do > some work). I think something like this would help since the HIP > exchange > is good against most attacks while the update packet protocol seems > vulnerable. In principle, sounds like a good idea under certain circumstances, especially when an non-trusted (perhaps anonymous) peer sends updates in a rapid rate, and especially if any of the signatures fails. However, before proceeding with writing any text, I think we need to better understand the pros and cons. Simply allowing either of the peers to pose a challenge to the other saying "If you want to continue please solve this puzzle" may not be a good idea, as that also may be used as a DoS tool. --Pekka From thomas.r.henderson@boeing.com Wed Apr 6 20:34:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Apr 6 19:34:01 2005 Subject: [Hipsec] Null IPsec Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AEF@xch-nw-27.nw.nos.boeing.com> =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Wednesday, March 09, 2005 3:20 PM > To: HIP > Cc: David Ward > Subject: [Hipsec] Null IPsec >=20 > Folks, >=20 > during today's meeting, the chairs got an action point to=20 > talk to the security ADs about the possibility of having a=20 > MUST implement IPsec with null encryption and/or null=20 > integrity protection. >=20 > I talked to Russ, and his gut reaction was that null=20 > encryption with integrity may be fine, but he would need to=20 > see the use case people have in mind before accepting null=20 > encryption and null integrity. >=20 We should probably try to close out this issue. At the WG meeting, I asked whether having ESP as a MUST implement portion of HIP would constrain future implementations that might not need to run ESP. Specifically, I had in mind Secure RTP (RFC 3711). HIP plus SRTP could be implemented for a VoIP node, without ESP. IIRC, Pekka pointed out that there is usually required a minimal level of interoperability specified, and by putting out HIP as a stand-alone spec with no mandatory transport format, we would violate that tenet. I then floated the idea of requiring, at a minimum, compliance with ESP packet formats (with SPIs merely serving as per-packet shim context) even if the crypto transforms were null. However, I don't sense any support for that idea, and I am not sure it is a good idea anyway. It violates RFC2406, for instance. =20 Presently, we have the following situation: i) HIP draft requires implementation of ESP: "All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [23]." ii) ESP draft requires implementation of ESP-AES-CBC with HMAC-SHA1, and ESP-NULL with HMAC-SHA1. iii) ESP-NULL is deprecated: "In addition to AES, all implementations MUST implement the ESP NULL encryption and authentication algorithms. These algorithms are provided mainly for debugging purposes, and SHOULD NOT be used in production environments. The default configuration in implementations MUST be to reject NULL encryption or authentication." Is there sentiment for changing any of these? At the very least, I think that iii) is too constraining-- we should not block the possible use of null encryption with integrity check. If no one else thinks i) is a big deal, then I will drop it. I suppose that a future RFC could override that statement if needed. Tom From Gonzalo.Camarillo@ericsson.com Thu Apr 7 05:21:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Apr 7 04:21:01 2005 Subject: [Hipsec] Minutes of HIP meeting in IETF 62 Message-ID: <4254ED06.6050302@ericsson.com> Folks, here you have the draft minutes of our last meeting. Let us know if you have any comments. http://hip.piuha.net/meetings/ietf62/notes/minutes-ietf62-hip.txt Thanks, Gonzalo From gmp@research.panasonic.com Thu Apr 7 15:41:00 2005 From: gmp@research.panasonic.com (Greg Perkins) Date: Thu Apr 7 14:41:00 2005 Subject: [Hipsec] Re: some questions regarding the update packet protocol References: <6938661A6EDA8A4EA8D1419BCE46F24C06648DDC@xch-nw-27.nw.nos.boein g.com> <03ae01c508b2$fcab8ff0$ef01a996@gmp> <3f8d4c130634edf9fd6c9e1e4f2c6c9a@nomadiclab.com> <045b01c50aee$28290bc0$ef01a996@gmp> <29b42c8fdcdd4feb74f9efff5f2f5f05@nomadiclab.com> <05aa01c53a1d$9877fc70$ef01a996@gmp> <7f880a546bb4532477491b9d250c6736@nomadiclab.com> Message-ID: <001b01c53ba2$3e400190$ef01a996@gmp> Thanks for your responses Pekka, making update packets less useful to attackers is going to be a little more complex than I thought. > IIRC, the intention is to say that as packets may get duplicated in > the IP network anyway, also the sending host may send duplicate packets. > For example, if the sender does not receive a corresponding ACK, it > may resend an old, already signed packet instead of constructing a new > packet and signing that. Ok, fair enough. > IIRC, the intention is just to clarify the semantics. For example, > let say that we have a hypothetical payload "Increment a counter by > one". > Now, if you send two identical UPDATEs with the *same* SEQ, both > containing > the "increment a counter by one", the counter will be incremented once. > However, if you send two UPDATEs with *different* SEQs but otherwise > identical, the counter will be incremented twice. > > This is probably too obvious, and hence some text clarification might > be needed. Suggestions? > > Or maybe we should write more text about the perhaps-obvious semantics > issue that the sender must not assume anything about the receiver's > state beyond acked UPDATEs. That is, if the sender has several pending > updates out, the protocol must work correctly independent on which of > the > pending updates actually reach the receiver and in which order. Ok, I think I get this now. I think the protocol should not send another, different update packet until a current outstanding update packet is acked by the receiver (or the protocol drops it, like if a mobile node sends a update packet but then gets a new ip address before receiving an ACK it can reset state and send a new update packet). This would simplify analysis of the interactions of the two HIP host's state machines. Would that cause any problems (I have trouble think of cases where I would want to send multiple update packets since I can bundle multiple requests into a single update packet)? Now If the receiving host is processing an update packet and receives a new one it too would need to reset state and then process the new update packet. A problem can occur if the receiver processes an update packet, ACKs it and changes state yet the sender has reset state and sent a new update packet before receiving the ACK. A way to fix that is that update packets have their own counters. Even after processing and sending an ACK the receiver will still reset state if it receives a new update packet with the same update packet counter (sequence number basically). An update packet sequence number only gets incremented after an ACK has been received. I think this would help keep the HIP protocol running smoothly. > One way to counter that is to remember some past received UPDATEs and > any responses to them, and simply re-send the already existing response > in the case of receiving a resent UPDATE. I thought about that previously and decided that an attacker would simply create more instances of update packets than an implementation would save, then cycle through them. There is just no way to stop this without implementing an intrusion detection system at the IP layer (that seems unlikely ;) ) or limiting the number of requests in order to limit the damage that an attacker can do. Some limit based on RTT might help here but could cause problems with fast moving mobile hosts (or host's on connection boundaries). So probably allow REA update packets at anytime but if the same update packet or a different update packet is received before RTT then drop it or even flag it as an attack and drop the connection. That would at least help. > In principle, sounds like a good idea under certain circumstances, > especially when an non-trusted (perhaps anonymous) peer sends updates > in a rapid rate, and especially if any of the signatures fails. > However, before proceeding with writing any text, I think we need > to better understand the pros and cons. Simply allowing either of > the peers to pose a challenge to the other saying "If you want to > continue please solve this puzzle" may not be a good idea, as that > also may be used as a DoS tool. Good point. I made an assumption that I never stated which is that an initiator of a HIP session can never send a challenge. If the receiver of a HIP I1 ever receives a challenge they can elect to drop the session. This is good, I think something simple yet helpful can be done here with only a little bit of extra state being saved. Attacks will be possible but I think they can be limited. Greg ----- Original Message ----- From: "Pekka Nikander" To: "Greg Perkins" Cc: ; "Christian Vogt" ; "Ahrenholz, Jeffrey M" ; "Jari Arkko" ; "Jan Mikael Melen" ; "Thomas R Henderson" Sent: Wednesday, April 06, 2005 1:54 AM Subject: [Hipsec] Re: some questions regarding the update packet protocol > Greg, > > [CC:n to the list as I think this belongs to the WG and > raises important topics.] > > >> UPDATEs MAY be retransmitting without incrementing SEQ. ... > > > > How to process equal sequence numbers due (normally) to > > retransmissions is > > outlined in section 8.10.1. But what is the difference between > > retransmission and a replay attack? Nothing as far as I can tell? > > IIRC, the intention is to say that as packets may get duplicated in > the IP network anyway, also the sending host may send duplicate packets. > For example, if the sender does not receive a corresponding ACK, it > may resend an old, already signed packet instead of constructing a new > packet and signing that. > > From the receiver's perspective, it is no different from receiving > a recent packet multiple times. The receiver does not know if the > packet has been duplicated in the net, is a replay attack attempt, > or has been resent by the sender. > > Maybe the text needs to be clarified? > > > > >> If the same > >> subset of parameters is included in multiple UPDATEs with different > >> SEQs, the host MUST ensure that receiver processing of the > >> parameters > >> multiple times will not result in a protocol error. > > > > I also don't understand that. Is that saying you have received the > > same HIP > > update packet with only the SEQ changed? So I can resend the same > > update > > packet with an incremented SEQ, yes? > > IIRC, the intention is just to clarify the semantics. For example, > let say that we have a hypothetical payload "Increment a counter by > one". > Now, if you send two identical UPDATEs with the *same* SEQ, both > containing > the "increment a counter by one", the counter will be incremented once. > However, if you send two UPDATEs with *different* SEQs but otherwise > identical, the counter will be incremented twice. > > This is probably too obvious, and hence some text clarification might > be needed. Suggestions? > > Or maybe we should write more text about the perhaps-obvious semantics > issue that the sender must not assume anything about the receiver's > state beyond acked UPDATEs. That is, if the sender has several pending > updates out, the protocol must work correctly independent on which of > the > pending updates actually reach the receiver and in which order. > > > From the way update packets are processed and tracked, it seems that > > clients > > could easily bombard a service with HIP update packets that the client > > only > > created once but can resend many times. Of course, this can be done > > already > > in toiday's Internet but with HIP, if the signature is being checked, > > this > > will cause greater problems. > > One way to counter that is to remember some past received UPDATEs and > any responses to them, and simply re-send the already existing response > in the case of receiving a resent UPDATE. > > > I think their needs to be an update counter > > that gets incremented with each update and decremented over time. > > Once you > > reach some threshold MAX_UPDATE_COUNT the receiver starts to send > > challenges, maybe pre-made encrypted nonces for the update initiator to > > decrypt, where the nonce must be sent back before any further update > > packets > > are processed. This is just an extension of the puzzle challenge idea > > in > > the base exchange onto the update packet protocol (make the initiator > > do > > some work). I think something like this would help since the HIP > > exchange > > is good against most attacks while the update packet protocol seems > > vulnerable. > > In principle, sounds like a good idea under certain circumstances, > especially when an non-trusted (perhaps anonymous) peer sends updates > in a rapid rate, and especially if any of the signatures fails. > However, before proceeding with writing any text, I think we need > to better understand the pros and cons. Simply allowing either of > the peers to pose a challenge to the other saying "If you want to > continue please solve this puzzle" may not be a good idea, as that > also may be used as a DoS tool. > > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From miika@iki.fi Thu Apr 7 17:11:02 2005 From: miika@iki.fi (Miika Komu) Date: Thu Apr 7 16:11:02 2005 Subject: [Hipsec] clarifications to the base draft Message-ID: Thomas asked for Jeff and me to make some (interop related) clarifications to the text about ENCRYPTED and HMAC calculation. Here's what we came up: 6.2.16 ENCRYPTED The ENCRYPTED parameter encapsulates another TLV, the encrypted data, which is also in TLV format. Consequently, the first fields in the encapsulated parameter(s) are Type and Length, allowing the contents to be easily parsed after decryption. Both the ENCRYPTED parameter and the encapsulated TLV(s) MUST be padded. The padding needed for the ENCRYPTED parameter is referred as the "outer" padding. Correspondingly, the padding for the parameter(s) encapsulated within the ENCRYPTED parameter is referred as the "inner" padding. The inner padding follows exactly the rules of Section 6.2.1. The outer padding also follows the same rules but with an exception. Namely, some algorithms require that the data to be encrypted must be a multiple of the cipher algorithm block size. In this case, the outer padding MUST include extra padding, as specified by the encryption algorithm. The size of the extra padding is selected so that the the length of the ENCRYPTED is the minimum value that is both multiple of eight and the cipher block size. The encryption algorithm may specify padding bytes other than zero; for example, AES [AES] uses the PKCS5 padding scheme [PKCS5] (see section 6.1.1) where the remaining n bytes to fill the block each have the value n. Note that the length of the cipher suite output may be smaller or larger than the length of the data to be encrypted, since the encryption process may compress the data or add additional padding to the data. 6.2.17 NOTIFY .. 8.3.1 HMAC calculation The following process applies both to the HMAC and HMAC_2 TLVs. When processing HMAC_2, the difference is that the HMAC calculation includes a pseudo HOST_ID field containing the Responder's information as sent in the R1 packet earlier. Both the initiator and the responder should take some care when verifying or calculating the HMAC_2. Specifically, the responder should preserve other parameters than the HOST_ID when sending the R2. Also, the Initiator has to preserve the HOST_ID exactly as it was received in the R1 packet. The HMAC TLV is defined in Section 6.2.10 and HMAC_2 TLV in Section 6.2.11. HMAC calculation and verification process: .. References: [PKCS5] ftp://ftp.rfc-editor.org/in-notes/rfc2898.txt [AES] National Institute of Standards and Technology, U.S. Department of Commerce, "Advanced Encryption Standard", Federal Information Processing Standards Publication 197, Washington, DC, November 2001. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From tkoponen@iki.fi Fri Apr 8 17:53:00 2005 From: tkoponen@iki.fi (Teemu Koponen) Date: Fri Apr 8 16:53:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <42076FE3.3070304@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> Message-ID: <31bb3e0d13017568115ed3699ad6515d@iki.fi> On Feb 7, 2005, at 15:40, Kevin Grace wrote: Kevin, >>> Today, using readily available DNS implementations and without >>> Rendezvous Servers, one can create an A record in an authoritative >>> name server for a mobile host and assign it a time-to-live of 1 >>> second. The longest the record could possibly be cached by >>> non-authoritative name servers then is 1 second.When the node moves >>> and changes IP addresses, it can successfully update its A record >>> within the authoritative name server in less than a second. The >>> total latency between when a node's address changes and when DNS is >>> properly updated need not exceed a couple seconds and could well be >>> closer to one second. >> >> >> This is very good news indeed. Would you care to share us with a >> reference? > > Sure. From the London Communications Symposium in 2002: > http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf > > The authors in the referenced paper demonstrate empirically how fast > DNS can perform zone transfers and the maximum update rate it can > support for a given configuration. Note, they are using what today > would be considered slow platforms (650 MHz PIII) and even better > performance results can be obtained today. My own organization has > conducted similar tests using faster hardware and have been able to > support over 300 individual dynamic updates/sec where each mobile node > has a unique TSIG key; each individual update completes in well under > a second. I just recalled this thread while reading a more recent paper about DNS TTL violations: Pang et al., On the responsiveness of DNS-based network control, http://www-2.cs.cmu.edu/~aditya/papers/imc04-resp.pdf My interpretation of their DNS measurements is that pure DNS based mobility is simply not possible due to the current TTL violations in Internet even though DNS itself could handle the slight increase in load, which is by the way argued in more detail in the following paper: Jung et al., DNS performance and the effectiveness of caching, http://nms.lcs.mit.edu/papers/dns-ton2002.pdf Teemu -- From Gonzalo.Camarillo@ericsson.com Fri Apr 22 07:29:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Apr 22 06:29:01 2005 Subject: [Hipsec] List migration shortly Message-ID: <4268D1B5.20008@ericsson.com> Folks, FYI: we will be migrating this mailing list to a server at ietf.org in about one week. I will send further intructions when the ietf.org folks are ready for the migration. In principle, all the subscribers of the list will automatically become subscribers of the new list. Regards, Gonzalo From gurtov@cs.helsinki.fi Mon Apr 25 03:59:01 2005 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Mon Apr 25 02:59:01 2005 Subject: [Hipsec] changes to base spec? Message-ID: <426C950A.3020706@cs.helsinki.fi> Hi, Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base Exchange Protocol that will appear in ACISP'05, July 2005. http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf They suggest several changes to the HIP specs for improving security. Do you think we should adopt any of the changes for the base spec? Andrei The more interesting security properties in the HIP base exchange relate to denial-of-service: the protocol uses client puzzles with several novel details to protect against resource-exhaustion DoS attacks. We showed that these details require modification to provide the intended protection. In particular, an attacker was able trick the honest Initiator into solving the wrong puzzles, and it was able to consume the puzzles of the honest Initiator by solving them first. Moreover, the protocol state machine requires changes to prevent deadlocks and livelocks. Our analysis of the abstract protocol complements in an important way the detailed protocol design, specification, implementation, and testing that happens during the IETF standardization process. It should be remembered that HIP is as much a multi-addressing and mobility protocol as a security protocol. We suggested solutions to all the discovered problems and believe that the proposed protocol changes fit well into the HIP framework without compromising its original goals. From julien.IETF@laposte.net Mon Apr 25 08:10:00 2005 From: julien.IETF@laposte.net (Julien Laganier) Date: Mon Apr 25 07:10:00 2005 Subject: [Hipsec] changes to base spec? In-Reply-To: <426C950A.3020706@cs.helsinki.fi> References: <426C950A.3020706@cs.helsinki.fi> Message-ID: <200504251309.44531.julien.IETF@laposte.net> Hi Andrei, On Monday 25 April 2005 08:58, Andrei Gurtov wrote: > Hi, > > Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base > Exchange Protocol that will appear in ACISP'05, July 2005. > http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf > > They suggest several changes to the HIP specs for improving > security. Do you think we should adopt any of the changes for the > base spec? I quickly went throughout the paper, and here's my first impressions: - Parts 3, 4, 5 and 7 (resp. replays of R1s, reuse of D-H keys, puzzle implementation, state machine issues) seems sensible to me. IMHO we should adopt them after a carefull review (I'll try to understand further the consequences of the modifications). - Parts 6 (initiator identity protections) seems more problematic to me. I don't fully agree with the argument that "encryption is ineffective as a privacy mechanism". While it's true that the current spec is somewhat vulnerable to tracking of cleartext HIT anyway, I would like to keep the door open for integrating into HIP Jukka and Pekka's BLIND proposal [1] for complete end-point identity protection. Thanks, --julien [1] Jukka Ylitalo, and Pekka Nikander, "BLIND: A Complete Identity Protection Framework for End-points", (to appear) in Proc. of the Twelfth International Workshop on Security Protocols, Cambridge, GB, April 26-28, 2004. From gurtov@cs.helsinki.fi Wed Apr 27 03:16:01 2005 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Wed Apr 27 02:16:01 2005 Subject: [Hipsec] changes to base spec? In-Reply-To: <200504251148.53176.julien.laganier@sun.com> References: <426C950A.3020706@cs.helsinki.fi> <200504251148.53176.julien.laganier@sun.com> Message-ID: <426F2DE9.50907@cs.helsinki.fi> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-9059-1114582496-0001-2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Thanks for feedback. I've also privately discussed the changes with Kristian Slavov @ NomadicLab. He seems to agree with them, except noting that HIT is not provably identifying the host (however with 128 bits the probability of getting a collision is negligible). Andrei Julien Laganier wrote: >Hi Andrei, > >On Monday 25 April 2005 08:58, Andrei Gurtov wrote: > > >>Hi, >> >>Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base >>Exchange Protocol that will appear in ACISP'05, July 2005. >>http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf >> >>They suggest several changes to the HIP specs for improving >>security. Do you think we should adopt any of the changes for the >>base spec? >> >> > >I quickly went throughout the paper, and here's my first impressions: > >- Parts 3, 4, 5 and 7 (resp. replays of R1s, reuse of D-H keys, puzzle >implementation, state machine issues) seems sensible to me. IMHO we >should adopt them after a carefull review (I'll try to understand >further the consequences of the modifications). > >- Parts 6 (initiator identity protections) seems more problematic to >me. I don't fully agree with the argument that "encryption is >ineffective as a privacy mechanism". While it's true that the current >spec is somewhat vulnerable to tracking of cleartext HIT anyway, I >would like to keep the door open for integrating into HIP Jukka and >Pekka's BLIND proposal [1] for complete end-point identity >protection. > >Thanks, > >--julien > >[1] Jukka Ylitalo, and Pekka Nikander, "BLIND: A Complete Identity >Protection Framework for End-points", (to appear) in Proc. of the >Twelfth International Workshop on Security Protocols, Cambridge, GB, >April 26-28, 2004. > > --=_courier-9059-1114582496-0001-2 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC 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/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDQyNzA2MTUwNVowIwYJ KoZIhvcNAQkEMRYEFNVph+fk40LxFGz2ChhDXR4FhYmRMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBAILFlYrRp0igyNjOLlJ4eSevvmCNrlKg/njLFU4FAyHdvBAQ4yvXDcQ0mxTngvcESRuU 9hjXWsN+fjrRsUoAjgl1X5ITIwhbPpmSfTVdBbmL7GPLy4k/Lwmxjm4PLUOqYAI7nguv7+Fm 1Qfis1EDa+aHIbMfvEZfv4dXD7KJsKrcD3zsylidVYHQnitDqP3/CtA0/c/OcFbeR5eu6llR fGkBvs3aoRKO9On5V2aB8K5mO0Vstz1ANm76RsFHZhwHqXx9DxbpSJRDtEIfGLMFhS+8+GtW qyo9q3JSf30AbALS7Tw/TsNQpR54UGfF8XMKK2n4bJ/ayzsh3A3HAFjTEAAAAAAAAAA= --=_courier-9059-1114582496-0001-2-- From petri.jokela@nomadiclab.com Wed Apr 27 04:22:01 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Apr 27 03:22:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Message-ID: <426F3D63.5090500@nomadiclab.com> Petri Jokela wrote: > On Wed, 9 Feb 2005, Henderson, Thomas R wrote: >> - I did not find the new conceptual protocols helpful-- to me, it seems >> unnecessary to add this terminology, unless you have some downstream >> plan to do something different with these packet exchanges. Wording >> such as "In a typical implementation, the parameters are included in R1, >> I2, and R2" seems to suggest that atypical implementations also may >> exist that include these parameters in other messages, and that we >> therefore have to be prepared for all possible situations, which I don't >> think is what is intended. I would suggest using the explicit R1, I2, >> R2, and UPDATE names for the packets instead of HES and HER. > > > The idea was that we do not bind the required information exchange to > these particular HIP packets. Perhaps we could set up the ESP Security > Association afterwards using UPDATE messages. I must admit that I have a > similar feeling that the current text is not very reader friendly. I'm working on the next version of the ESP draft. There have been some comments for and against the HES / HER conseptual protocols, but not too many. With the current definition we could allow the ESP SA establishment also in later phase, using UPDATE messages. If I have understood correctly, there were not too many comments related to this issue during last IETF meeting. Any comments now? Leave it like it is now, or change it so that the setup is done during base exchange. In general, I'm changing the structure of the draft a bit, based on Tom's feedback that was earlier on the list. /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 Wed Apr 27 22:43:02 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Apr 27 21:43:02 2005 Subject: [Hipsec] Draft: ESP usage in HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06649229@xch-nw-27.nw.nos.boeing.com> >=20 > I'm working on the next version of the ESP draft. There have=20 > been some comments for and against the HES / HER conseptual=20 > protocols, but not too many.=20 The sentiment that I and another speaker voiced at the WG meeting was to avoid the HES/HER conceptual protocols. I have not heard any other comments in favor of those protocols. > With the current definition we=20 > could allow the ESP SA establishment also in later phase,=20 > using UPDATE messages. >=20 > If I have understood correctly, there were not too many=20 > comments related to this issue during last IETF meeting. Any=20 > comments now? Leave it like it is now, or change it so that=20 > the setup is done during base exchange. Could you explain what you have in mind? I am reading the above to mean that data is first sent without ESP, and is later updated to run over an ESP SA, but perhaps I am not understanding correctly? Tom From pekka.nikander@nomadiclab.com Thu Apr 28 04:11:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Apr 28 03:11:01 2005 Subject: [Hipsec] changes to base spec? In-Reply-To: <200504251309.44531.julien.IETF@laposte.net> References: <426C950A.3020706@cs.helsinki.fi> <200504251309.44531.julien.IETF@laposte.net> Message-ID: <0e28fbb65a09974e3a846715b5a48695@nomadiclab.com> > - Parts 6 (initiator identity protections) seems more problematic to > me. I don't fully agree with the argument that "encryption is > ineffective as a privacy mechanism". While it's true that the current > spec is somewhat vulnerable to tracking of cleartext HIT anyway, I > would like to keep the door open for integrating into HIP Jukka and > Pekka's BLIND proposal [1] for complete end-point identity > protection. I don't have a firm opinion (too busy to form one), but I just want to make the remark that BLIND requires also other changes to the base, essentially creating a variant of the base exchange. Hence, I would not consider BLIND as a reason for not adopting Tuomas'es suggestion. --Pekka From Gonzalo.Camarillo@ericsson.com Thu Apr 28 04:23:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Apr 28 03:23:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06649229@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06649229@xch-nw-27.nw.nos.boeing.com> Message-ID: <42708F12.6060500@ericsson.com> Hello, >> With the current definition we could allow the ESP SA establishment >> also in later phase, using UPDATE messages. >> >> If I have understood correctly, there were not too many comments >> related to this issue during last IETF meeting. Any comments now? >> Leave it like it is now, or change it so that the setup is done >> during base exchange. > > > Could you explain what you have in mind? I am reading the above to > mean that data is first sent without ESP, and is later updated to run > over an ESP SA, but perhaps I am not understanding correctly? a use case would be a user moving between different accesses with different security properties (e.g., from a corporate Intranet to the public Internet). When the user moves to the new access the transport is updated from ESP NULL to ESP with encryption. We would have the same situation when a user moves from a low-bandwitdh access where SRTP is used to allow for header compression to a high-bandwidth access where ESP can be used. Gonzalo From petri.jokela@nomadiclab.com Thu Apr 28 04:48:00 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Apr 28 03:48:00 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <42708F12.6060500@ericsson.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06649229@xch-nw-27.nw.nos.boeing.com> <42708F12.6060500@ericsson.com> Message-ID: <42709501.7000302@nomadiclab.com> Gonzalo Camarillo wrote: >> Could you explain what you have in mind? I am reading the above to >> mean that data is first sent without ESP, and is later updated to run >> over an ESP SA, but perhaps I am not understanding correctly? > > > a use case would be a user moving between different accesses with > different security properties (e.g., from a corporate Intranet to the > public Internet). When the user moves to the new access the transport is > updated from ESP NULL to ESP with encryption. > > We would have the same situation when a user moves from a low-bandwitdh > access where SRTP is used to allow for header compression to a > high-bandwidth access where ESP can be used. If we decide to continue with this model, it might be better to get rid of the conseptual way of describing things and put more concrete definitions; describe the usage both with Base exchange and UPDATE messages. It would make the draft easier to understand. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Fri Apr 29 08:54:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Apr 29 07:54:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <42709501.7000302@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06649229@xch-nw-27.nw.nos.boeing.com> <42708F12.6060500@ericsson.com> <42709501.7000302@nomadiclab.com> Message-ID: <9744b5679a38ad18312771a89b4e6114@nomadiclab.com> >>> Could you explain what you have in mind? I am reading the above to >>> mean that data is first sent without ESP, and is later updated to run >>> over an ESP SA, but perhaps I am not understanding correctly? >> a use case would be a user moving between different accesses with >> different security properties (e.g., from a corporate Intranet to the >> public Internet). When the user moves to the new access the transport >> is >> updated from ESP NULL to ESP with encryption. >> We would have the same situation when a user moves from a >> low-bandwitdh >> access where SRTP is used to allow for header compression to a >> high-bandwidth access where ESP can be used. > > If we decide to continue with this model, it might be better to get > rid of the conseptual way of describing things and put more concrete > definitions; describe the usage both with Base exchange and UPDATE > messages. It would make the draft easier to understand. Sounds very good to me. --Pekka