From pekka.nikander@nomadiclab.com Mon May 3 02:57:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon May 3 01:57:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605E4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605E4@xch-nw-27.nw.nos.boeing.com> Message-ID: <78CC909C-9CCD-11D8-9001-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. > > Originally, [...], Birthday was supposed to > 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 > "unknown SPIs" as an implicit I1 packet. Even though the current nor the old versions of the drafts do not say much more, IIRC the issue was subtler. I vaguely remember one discussion with Bob M. where he described the reasons behind the design of the birthday mechanism, and I think that there was something more. But my memory fails with the details. Anyway, I don't think that it matters any more. But maybe somebody else remembers? > Now, we do not use unknown SPIs anymore as an implicit > I1. [...] I only get an I2 from my peer > if it decided it wanted to resync with me-- I can use > the cookie rotation to assure that this is a current > I2, and signature and other fields to validate. In the light of your analysis below, I agree. > Case i) (normal HIP exchange) > The only mischief that seems possible is that I1s or > R1s could be replayed, causing the initiator to get > more than one R1, while in state I1-SENT or I2-SENT. > ... Birthday here > may be useful as an R1 freshness counter, if we > allow hosts in I2-SENT to start over only if they > receive an R1 with a higher count ... Agreed. > Case ii) > The host will send an I1, which will trigger an R1 > from the peer, who is already ESTABLISHED. If > the resulting I2 passes cookie checks and signature, > then it means that the peer must want to reestablish > the SAs (resync). I do not see what additional > protection that birthday check affords-- seems > redundant with cookie rotation. Yes, this seems to be the case. OTOH, the case i) protection for the host itself still applies, as you imply. > Case iii) > 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). As I argued before, the peer should be very careful in sending NOTIFYs. If it sends a signed NOTIFY, it needs to spend cycles in signing the NOTIFY, and that opens a possible DoS attack. Sure, we can counter the threat with careful resource control, but that still leaves the possibility of increasing the CPU load without actually overloading. Sending an unsigned NOTIFY is one possible option, and might be good. OTOH, at least in IPv6 case I would rather send an ICMP Parameter Problem, Type 0, with the pointer pointing to the SPI number. That should also work for IPv4, as the SPI number fits within the first 8 bytes of the ESP payload. That would be pretty generic, and potentially work both for HIP and IKE. And even that rate limited, of course. Then the host itself must be, of course, pretty careful of not dropping its existing (incoming) SAs before it has completed resynchronisation and got an R2. We have to remember that the ICMP may be spoofed, and in the IPv4 case where it may not contain the replay protection field, it may even be sent out of the blue, without really being able to see the original ESP packet. But that all doesn't change the argument over the birthday value. In the light of operational concerns, the idea of replying to an unknown SPI with and R1 seems like a nice optimisation that just doesn't work well enough in real life. > 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. I concur. > 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 > may be forthcoming). "Birthday" may be the wrong term > for this counter. We seem to mostly agree. I think that "R1 generation counter" might be a better name for the value. There seems to be two rules governing it: - it must be strictly incremented (never decrease) - it must be incremented every time old R1s cease to be valid Could you suggest modifications to the current text? --Pekka From mkousa@cc.hut.fi Mon May 3 09:39:04 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Mon May 3 08:39:04 2004 Subject: [Hipsec] MM: Using UPDATEs for RR In-Reply-To: <4708A8BE-9A31-11D8-8F9C-0003930D291E@speakeasy.net> References: <4708A8BE-9A31-11D8-8F9C-0003930D291E@speakeasy.net> Message-ID: On Thu, 29 Apr 2004, Jonathan Wood wrote: -> ... -> Since the update ID increases by one each time and starts at 1, it is -> easy to guess. -> ... Just a minor thing came to my mind: The section 6.2.13 NES in the draft-10pre1 says about UPDATE ID "Initialized to zero and incremented for each UPDATE." When sending the first UPDATE packet, should this be interpreted as "The first UPDATE packet has ID 0 and the counter is increased after the UPDATE packet is sent" or "the UPDATE ID counter is first increased and then this increased value (1) is used in the UPDATE packet to be sent out" ? From mkousa@cc.hut.fi Mon May 3 10:20:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Mon May 3 09:20:01 2004 Subject: [Hipsec] MM: Using UPDATEs for RR In-Reply-To: References: <4708A8BE-9A31-11D8-8F9C-0003930D291E@speakeasy.net> Message-ID: On Mon, 3 May 2004, Mika Kousa wrote: -> The section 6.2.13 NES in the draft-10pre1 says about UPDATE ID -> "Initialized to zero and incremented for each UPDATE." When sending the -> first UPDATE packet, should this be interpreted as "The first UPDATE -> packet has ID 0 and the counter is increased after the UPDATE packet is -> sent" or "the UPDATE ID counter is first increased and then this increased -> value (1) is used in the UPDATE packet to be sent out" ? Ah, I'll have to answer to myself. Section 8.9 Initiating rekeying of the draft says that "The system MUST increment its outgoing UPDATE ID counter" before "The system sends the UPDATE packet", so the the first ID value is really 1 and there is no more possibilities for misunderstanding the interpretation. Case closed. From thomas.r.henderson@boeing.com Mon May 3 22:24:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon May 3 21:24:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605F4@xch-nw-27.nw.nos.boeing.com> > > 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 > > may be forthcoming). "Birthday" may be the wrong term > > for this counter. >=20 > We seem to mostly agree. I think that "R1 generation counter" > might be a better name for the value. There seems to be > two rules governing it: >=20 > - it must be strictly incremented (never decrease) > - it must be incremented every time old R1s cease > to be valid >=20 > Could you suggest modifications to the current text? >=20 > --Pekka Here is an initial cut at the main changes-- if agreeable, I can=20 propose other alignment of the text to Petri. 4.1.3 HIP replay protection =20 The HIP protocol includes the following mechanisms to protect against malicious replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1s with presigned R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays or false I2s by the cookie mechanism (Section 4.1.1 above), and optional use of opaque data. =20 Hosts are protected against replays to R2s and UPDATEs by use of a less expensive HMAC verification preceding HIP signature verification. The R1 generation counter is a monotonically incrementing 64-bit counter that MUST be initialized to zero. It is a system-wide=20 counter that keeps state across system reboots and invocations of=20 the HIP signaling process. This counter indicates the current=20 generation of valid cookie puzzles. It MUST be incremented at=20 least as often as every time old R1s cease to be valid, and=20 SHOULD never be decremented, lest the implementation expose itself=20 to the replay of previously generated, higher numbered R1s. =20 A host may receive more than R1, either due to sending multiple I1s (Section 8.4.1) or due to a replay of an old R1. When sending=20 multiple I1s, an initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1s to=20 arrive, and it SHOULD respond to an R1 among the set with the=20 largest R1 generation counter. If an initiator is processing an R1 or has already sent an I2 (still waiting for R2) and it=20 receives another R1 with a larger R1 generation counter, it MAY elect to restart R1 processing with the fresher R1, as if it were the first R1 to arrive. 6.2.4 R1_COUNTER 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R1 generation counter, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 16 R1 generation counter The current generation of valid puzzles The R1_COUNTER parameter contains an 64-bit unsigned integer in = network byte order, indicating the current generation of valid puzzles. The sender is supposed to increment this counter periodically. It is RECOMMENDED that the counter value is incremented at least as often as old PUZZLE values are deprecated so that SOLUTIONs to them are no more accepted. Open issues: i) is R1_COUNTER an optional or mandatory parameter to include in R1? ii) is 64 bits still the right length for this? iii) is there any value in putting this parameter in the I2 (may be=20 useful if initiator sends two I2s, in determining whether responder=20 bothers with subsequent received I2s or ignores them)? iv) how to address modulo sequence number comparisons-- what is the=20 acceptable window of R1 counter values-- what do you do if you get two=20 R1s with vastly different counters (is this even an issue)? v) should we specify that R1 counter values are not cached-- are flushed after a HIP association goes away? From pekka.nikander@nomadiclab.com Tue May 4 03:32:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 4 02:32:00 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605F4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605F4@xch-nw-27.nw.nos.boeing.com> Message-ID: > Here is an initial cut at the main changes-- if agreeable, I can > propose other alignment of the text to Petri. Looks very good. Minor issues and some nits below. > 4.1.3 HIP replay protection > > The HIP protocol includes the following mechanisms to protect > against > malicious replays. Responders are protected against replays of I1 > packets by virtue of the stateless response to I1s with presigned > R1 messages. Initiators are protected against R1 replays by a > monotonically increasing "R1 generation counter" included in the R1. > Responders are protected against replays or false I2s by the cookie > mechanism (Section 4.1.1 above), and optional use of opaque data. > Hosts are protected against replays to R2s and UPDATEs by use > of a less expensive HMAC verification preceding HIP signature > verification. > > The R1 generation counter is a monotonically incrementing 64-bit > counter that MUST be initialized to zero. It is a system-wide SHOULD I don't see any reason why it should be initialised to zero. That prevents one from using date&time, which is a viable option for some implementations. I think the scope MAY be system-wide but SHOULD be per HI? > counter that keeps state across system reboots and invocations of > the HIP signaling process. This counter indicates the current > generation of valid cookie puzzles. It MUST be incremented at generation(s) > least as often as every time old R1s cease to be valid, and > SHOULD never be decremented, lest the implementation expose itself "expose itself" or "expose its peers" ? > to the replay of previously generated, higher numbered R1s. > A host may receive more than R1, either due to sending multiple I1s > (Section 8.4.1) or due to a replay of an old R1. When sending > multiple I1s, an initiator SHOULD wait for a small amount of time > after the first R1 reception to allow possibly multiple R1s to > arrive, and it SHOULD respond to an R1 among the set with the > largest R1 generation counter. If an initiator is processing > an R1 or has already sent an I2 (still waiting for R2) and it > receives another R1 with a larger R1 generation counter, it MAY > elect to restart R1 processing with the fresher R1, as if it were > the first R1 to arrive. I think the text above is very good, very balanced. Most probably we want to tighten it up, but only later, with experience. Or at least I don't know how to tighten it without unnecessarily killing various interesting implementation options. > > 6.2.4 R1_COUNTER > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | R1 generation counter, 8 bytes | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Type 3 > Length 16 > R1 generation counter The current generation of valid puzzles > > > The R1_COUNTER parameter contains an 64-bit unsigned integer in > network > byte order, indicating the current generation of valid puzzles. The generation(s) > sender is supposed to increment this counter periodically. It > is RECOMMENDED that the counter value is incremented at least as > often as old PUZZLE values are deprecated so that SOLUTIONs to them > are no more accepted. Note that an implementation MAY accept several generations of puzzles at any given time. It is RECOMMENDED that an implementation accepts at least two consequent generations of puzzles. > Open issues: > i) is R1_COUNTER an optional or mandatory parameter to include in R1? Optional and non-critical but RECOMMENDED sounds right to me. Some implementations may not be able to implement it since they don't have stable storage. When included, it is covered with the signature, and therefore one can't create spoofed R1s without it when the real host would be providing it. Non-critical since some hosts may opt not to pay any attention to it. > ii) is 64 bits still the right length for this? IMHO, 32 bits is not enough. Something like 40 or 48 bits might be sufficient, but going directly to 64 is as easy. > iii) is there any value in putting this parameter in the I2 (may be > useful if initiator sends two I2s, in determining whether responder > bothers with subsequent received I2s or ignores them)? Hmm. I don't have any strong opinion. A sane initiator would include the relevant information in the Opaque/#I fields in the puzzle, or if not sufficient, to the ECHO_REQUEST. Hence, I don't think it is needed. But if someone wants to include it there, why not. In that case I think we should require the implementations to echo back also the reserved field. > iv) how to address modulo sequence number comparisons-- what is the > acceptable window of R1 counter values-- what do you do if you get two > R1s with vastly different counters (is this even an issue)? I added above the recommendation that at least two consequent generations of puzzles are accepted. Hence, the window size would be 2. I don't see any issues with vastly different counters. The smaller one is just very old replay. > v) should we specify that R1 counter values are not cached-- are > flushed > after a HIP association goes away? Yes, I think the counter values SHOULD be flushed. A local policy MAY override this on per-HIT bases, though. The default MUST be to flush them. That's erring on robustness on the cost of security, which IMHO is the right way here. But YMMV. --Pekka From pekka.nikander@nomadiclab.com Tue May 4 04:05:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 4 03:05:01 2004 Subject: [Hipsec] HIP enhanced privacy paper now online Message-ID: <7DDFF0B3-9DA0-11D8-9001-000393CE1E8C@nomadiclab.com> A paper on enhanced HIP privacy is now available through my web page. Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity Protection Framework for End-points", to appear in Security Protocols, Twelfth International Workshop, Cambridge, 24-28 April, 2004. http://www.tml.hut.fi/~pnr/publications/cam2004.pdf --Pekka From thomas.r.henderson@boeing.com Tue May 4 13:03:09 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue May 4 12:03:09 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605F5@xch-nw-27.nw.nos.boeing.com> >=20 > I don't see any issues with vastly different counters. The=20 > smaller one > is just very old replay. So long as we do not roll over the counter, there is no ambiguity. 64 bits should pretty much guarantee that. Here is a proposed revision, based on your comments (thanks). Note that I made it non-critical this time around (Type=3D2): 4.1.3 HIP replay protection =20 The HIP protocol includes the following mechanisms to protect against malicious replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1s with presigned R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays or false I2s by the cookie mechanism (Section 4.1.1 above), and optional use of opaque data. =20 Hosts are protected against replays to R2s and UPDATEs by use of a less expensive HMAC verification preceding HIP signature verification. The R1 generation counter is a monotonically increasing 64-bit counter that may be initialized to any value. The scope of the counter MAY be system-wide but SHOULD be per host identity, if there is more than one local host identity. The value of this counter SHOULD be kept across system reboots and invocations of the HIP signaling process. This counter indicates the current=20 generation of valid cookie puzzles. It MUST be incremented at=20 least as often as every time old R1s cease to be valid, and=20 SHOULD never be decremented, lest the implementation expose its=20 peers to the replay of previously generated, higher numbered R1s. =20 A host may receive more than one R1, either due to sending multiple=20 I1s (Section 8.4.1) or due to a replay of an old R1. When sending=20 multiple I1s, an initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1s to=20 arrive, and it SHOULD respond to an R1 among the set with the=20 largest R1 generation counter (where largest is defined by modulo sequence number comparisons). If an initiator is processing an R1 or has already sent an I2 (still waiting for R2) and it=20 receives another R1 with a larger R1 generation counter, it MAY elect to restart R1 processing with the fresher R1, as if it were the first R1 to arrive. Upon conclusion of an active HIP association with another host,=20 the R1 generation counter associated with the peer host SHOULD be=20 flushed. A local policy MAY override the default flushing of=20 R1 counters on a per-HIT basis. 6.2.4 R1_COUNTER 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R1 generation counter, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 12 R1 generation counter The current generation of valid puzzles The R1_COUNTER parameter contains an 64-bit unsigned integer in = network byte order, indicating the current generation(s) of valid puzzles. = The sender is supposed to increment this counter periodically. It is RECOMMENDED that the counter value is incremented at least as often as old PUZZLE values are deprecated so that SOLUTIONs to them are no longer accepted. The R1_COUNTER parameter is optional but RECOMMENDED. It MAY be = included in the R1 (in which case it is covered by the signature), and if = present in the R1, it MAY be echoed (including the Reserved field) by the=20 Initiator in the I2. =20 From pekka.nikander@nomadiclab.com Tue May 4 13:23:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 4 12:23:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605F5@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605F5@xch-nw-27.nw.nos.boeing.com> Message-ID: <683181AA-9DEE-11D8-BF27-000393CE1E8C@nomadiclab.com> Nits below. > the HIP signaling process. This counter indicates the current > generation of valid cookie puzzles. It MUST be incremented at I think the text here really should be "generation(s)" and not "generation", to keep it open to the implementations how many earlier generations to accept. > arrive, and it SHOULD respond to an R1 among the set with the > largest R1 generation counter (where largest is defined by modulo > sequence number comparisons). If an initiator is processing I find the expression in paranthesis confusing. In fact, I don't understand what you mean, exactly. > Upon conclusion of an active HIP association with another host, > the R1 generation counter associated with the peer host SHOULD be > flushed. A local policy MAY override the default flushing of > R1 counters on a per-HIT basis. Perhaps add: The reason for this RECOMMENDATION is that there MAY be hosts where the R1 generation counter (occasionally) decreases, e.g., due to system reboots. > The R1_COUNTER parameter is optional but RECOMMENDED. It MAY be > included I'd rather say "It SHOULD be included" > in the R1 (in which case it is covered by the signature), and if > present > in the R1, it MAY be echoed (including the Reserved field) by the > Initiator in the I2. --Pekka From thomas.r.henderson@boeing.com Tue May 4 13:44:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue May 4 12:44:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605F7@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, May 04, 2004 10:14 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Issue 12: Birthday check badly defined >=20 >=20 > Nits below. >=20 > > the HIP signaling process. This counter indicates the current > > generation of valid cookie puzzles. It MUST be incremented at >=20 > I think the text here really should be "generation(s)" and not > "generation", to keep it open to the implementations how many > earlier generations to accept. It may be more clear to say: "This counter indicates the current generation of cookie puzzles. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations." (I don't think that replacing "generation" with "generation(s)" says this as clearly-- at least, I did not interpret it as you later elaborated.) >=20 > > arrive, and it SHOULD respond to an R1 among the set with the > > largest R1 generation counter (where largest is defined by modulo > > sequence number comparisons). If an initiator is processing >=20 > I find the expression in paranthesis confusing. In fact, I don't > understand what you mean, exactly. >=20 I mean that 0 is greater than 7 when using 3 bits. Is this understood implicitly by the term "largest"? If we allow counter to be initialized to anything, I think that we need in the spec to handle the case in = which it rolls over, or else state that it cannot. > > Upon conclusion of an active HIP association with another host, > > the R1 generation counter associated with the peer host SHOULD be > > flushed. A local policy MAY override the default flushing of > > R1 counters on a per-HIT basis. >=20 > Perhaps add: The reason for this RECOMMENDATION is that there MAY > be hosts where the R1 generation counter (occasionally) decreases, > e.g., due to system reboots. >=20 OK, good idea. > > The R1_COUNTER parameter is optional but RECOMMENDED. It MAY be=20 > > included >=20 > I'd rather say "It SHOULD be included" >=20 OK - Tom From pekka.nikander@nomadiclab.com Tue May 4 14:05:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 4 13:05:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605F7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605F7@xch-nw-27.nw.nos.boeing.com> Message-ID: <492F39E7-9DF4-11D8-BF27-000393CE1E8C@nomadiclab.com> >>> the HIP signaling process. This counter indicates the current >>> generation of valid cookie puzzles. It MUST be incremented at >> >> I think the text here really should be "generation(s)" and not >> "generation", to keep it open to the implementations how many >> earlier generations to accept. > > It may be more clear to say: "This counter indicates the current > generation of cookie puzzles. Implementations MUST accept puzzles > from the current generation and MAY accept puzzles from earlier > generations." Much better, thanks. >>> arrive, and it SHOULD respond to an R1 among the set with the >>> largest R1 generation counter (where largest is defined by modulo >>> sequence number comparisons). If an initiator is processing >> >> I find the expression in paranthesis confusing. In fact, I don't >> understand what you mean, exactly. >> > > I mean that 0 is greater than 7 when using 3 bits. Is this understood > implicitly by the term "largest"? If we allow counter to be > initialized > to anything, I think that we need in the spec to handle the case in > which > it rolls over, or else state that it cannot. I think it is best to state that the counter MUST NOT roll over. If it does, the corresponding HI must be abandoned and replaced with a new one. In fact, I didn't even consider the case when it would roll over, therefore I didn't understand what you were referring to. --Pekka From thomas.r.henderson@boeing.com Tue May 4 22:03:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue May 4 21:03:02 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605FA@xch-nw-27.nw.nos.boeing.com> OK, here is what we have converged to: 4.1.3 HIP replay protection =20 The HIP protocol includes the following mechanisms to protect against malicious replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1s with presigned R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays or false I2s by the cookie mechanism (Section 4.1.1 above), and optional use of opaque data. =20 Hosts are protected against replays to R2s and UPDATEs by use of a less expensive HMAC verification preceding HIP signature verification. The R1 generation counter is a monotonically increasing 64-bit counter that may be initialized to any value. The scope of the counter MAY be system-wide but SHOULD be per host identity, if there is more than one local host identity. The value of this counter SHOULD be kept across system reboots and invocations of the HIP signaling process. This counter indicates the current=20 generation of cookie puzzles. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be incremented at=20 least as often as every time old R1s cease to be valid, and=20 SHOULD never be decremented, lest the host expose its peers to the=20 replay of previously generated, higher numbered R1s. Also, the R1 generation counter MUST NOT roll over; if the counter is about to become exhausted, the corresponding HI must be abandoned and=20 replaced with a new one. A host may receive more than one R1, either due to sending multiple=20 I1s (Section 8.4.1) or due to a replay of an old R1. When sending=20 multiple I1s, an initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1s to=20 arrive, and it SHOULD respond to an R1 among the set with the=20 largest R1 generation counter. If an initiator is processing an R1 or has already sent an I2 (still waiting for R2) and it=20 receives another R1 with a larger R1 generation counter, it MAY elect to restart R1 processing with the fresher R1, as if it were the first R1 to arrive. Upon conclusion of an active HIP association with another host,=20 the R1 generation counter associated with the peer host SHOULD be=20 flushed. A local policy MAY override the default flushing of=20 R1 counters on a per-HIT basis. The reason for recommending the flushing of this counter is that there may be hosts where the R1=20 generation counter (occasionally) decreases; e.g., due to hardware=20 failure. 6.2.4 R1_COUNTER 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R1 generation counter, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 12 R1 generation counter The current generation of valid puzzles The R1_COUNTER parameter contains an 64-bit unsigned integer in = network byte order, indicating the current generation of valid puzzles. The sender is supposed to increment this counter periodically. It is RECOMMENDED that the counter value is incremented at least as often as old PUZZLE values are deprecated so that SOLUTIONs to them are no longer accepted. The R1_COUNTER parameter is optional. It SHOULD be included in the R1 (in which case it is covered by the signature), and if = present in the R1, it MAY be echoed (including the Reserved field) by the=20 Initiator in the I2. =20 From pekka.nikander@nomadiclab.com Wed May 5 02:11:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed May 5 01:11:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605FA@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605FA@xch-nw-27.nw.nos.boeing.com> Message-ID: <90004BF5-9E52-11D8-BF27-000393CE1E8C@nomadiclab.com> > OK, here is what we have converged to: Looks good. Others, are you happy with Tom's suggested text? --Pekka From miika@iki.fi Wed May 5 09:42:01 2004 From: miika@iki.fi (Miika Komu) Date: Wed May 5 08:42:01 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <90004BF5-9E52-11D8-BF27-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605FA@xch-nw-27.nw.nos.boeing.com> <90004BF5-9E52-11D8-BF27-000393CE1E8C@nomadiclab.com> Message-ID: On Wed, 5 May 2004, Pekka Nikander wrote: > > OK, here is what we have converged to: > > Looks good. > > Others, are you happy with Tom's suggested text? It seemed to be ok. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mbagnulo@ing.uc3m.es Wed May 5 13:31:01 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Wed May 5 12:31:01 2004 Subject: [Hipsec] Basic question about HIP Message-ID: Hi, I was wondering which are the risks vulnerabilities by a collision of HITs. I mean, suppose that a user U has his public key PKu and his hit is HITu = hash(PKu) Suppose that another user A finds another key PKa which hash collides with the previous one, i.e. HITa=hash(PKa)= hash(PKu)=HITu would this allow A to perform some sort of attacks to U or to another party? I am sorry if this topic has already been discussed before, if this is so i would appreciate a pointer to previous discussion/documents) Thanks, marcelo From thomas.r.henderson@boeing.com Wed May 5 17:57:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed May 5 16:57:01 2004 Subject: [Hipsec] Basic question about HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060604@xch-nw-27.nw.nos.boeing.com> Marcelo, I'm not aware of a detailed analysis of this risk. It is=20 discussed a bit in the HIP architecture draft=20 (http://hip.piuha.net/drafts/) in Section 3.3. HITs are operational representations of Host Identifiers. The assumption in the architecture draft is that HITs are statistically unique but not guaranteed to be so, and that the Host Identifier (probably authenticated by some third-party service or infrastructure like X.509) is the final proof of identity. However, operationally, it may be that people use HITs as the identifiers themselves, relying on the=20 self-certifying property that it is not computationally feasible to produce a matching HI given the HIT. In that case, it seems that a vulnerability is possible if the HI is not consulted or traced back to a trusted=20 authority (e.g., an ACL based solely on HITs). Tom > -----Original Message----- > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, May 05, 2004 10:18 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Basic question about HIP >=20 >=20 > Hi, >=20 > I was wondering which are the risks vulnerabilities by a=20 > collision of HITs. > I mean, suppose that a user U has his public key PKu and his=20 > hit is HITu =3D > hash(PKu) > Suppose that another user A finds another key PKa which hash=20 > collides with > the previous one, > i.e. HITa=3Dhash(PKa)=3D hash(PKu)=3DHITu > would this allow A to perform some sort of attacks to U or to=20 > another party? > I am sorry if this topic has already been discussed before,=20 > if this is so i > would appreciate a pointer to previous discussion/documents) >=20 > Thanks, marcelo >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From mbagnulo@ing.uc3m.es Thu May 6 05:11:04 2004 From: mbagnulo@ing.uc3m.es (marcelo bagnulo) Date: Thu May 6 04:11:04 2004 Subject: [Hipsec] Basic question about HIP In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060604@xch-nw-27.nw.nos.boeing.com> Message-ID: Hi Thomas, thank you very much for answer. I would like to pose an additional question related to this... [...] > However, operationally, it may be that people use > HITs as the identifiers themselves, relying on the > self-certifying property that it is not computationally > feasible to produce a matching HI given the HIT. Well, there is something about this point that puzzles me, probably because my lack of knowledge related to this issues, but wouldn't the fact that the HIT is fixed to 128 bits may affect this property in the future? I mean, AFAIK, as the computational power increases, the length of public keys has to be increased in order to preserve the security provided. However, in the case of the HITs, the length is fixed, so it won't be possible to increase its length. So, even if today it is not computationally feasible to produce a HI that matches with a HIT, would this remain so from 20 years from now? And if this happens, how would HIP will be affected? > In > that case, it seems that a vulnerability is possible > if the HI is not consulted or traced back to a trusted > authority (e.g., an ACL based solely on HITs). Considering that current IPv6 applications use 128 bit long strings (IP addresses) as endpoint identifiers, so it would be natural for them to use HITs as endpoint identifiers. I guess that during the first period of adoption of HIP, HITs will be used as identifiers instead of the HI. So, i can see the usage of the HIT as a transition tool. But in the long term goal is that applications will use the HI or HIT? In brief, is it recommended that future apps use the HIT or the HI? Regards, marcelo > > Tom > > > -----Original Message----- > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > Sent: Wednesday, May 05, 2004 10:18 AM > > To: hipsec@honor.trusecure.com > > Subject: [Hipsec] Basic question about HIP > > > > > > Hi, > > > > I was wondering which are the risks vulnerabilities by a > > collision of HITs. > > I mean, suppose that a user U has his public key PKu and his > > hit is HITu = > > hash(PKu) > > Suppose that another user A finds another key PKa which hash > > collides with > > the previous one, > > i.e. HITa=hash(PKa)= hash(PKu)=HITu > > would this allow A to perform some sort of attacks to U or to > > another party? > > I am sorry if this topic has already been discussed before, > > if this is so i > > would appreciate a pointer to previous discussion/documents) > > > > Thanks, marcelo > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@honor.trusecure.com > > http://honor.trusecure.com/mailman/listinfo/hipsec > > From pekka.nikander@nomadiclab.com Thu May 6 06:00:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu May 6 05:00:01 2004 Subject: [Hipsec] Basic question about HIP In-Reply-To: References: Message-ID: <43599EA1-9F40-11D8-B651-000393CE1E8C@nomadiclab.com> > I was wondering which are the risks vulnerabilities by a collision of > HITs. > I mean, suppose that a user U has his public key PKu and his hit is > HITu = > hash(PKu) > Suppose that another user A finds another key PKa which hash collides > with > the previous one, > i.e. HITa=hash(PKa)= hash(PKu)=HITu First, as you sure know, the probability of such collisions is extremely low. Since HITs are effectively 126 bits long, for any given HIT the probability that there is a collision is approximately (2^-126) * N where N is the total number of HITs. If you assume 100 billion HITs, or a few ten hits for each human on earth, the probability that somebody is colliding with your specific HIT is still 2^(-126+37) = 2^-89. Not very likely, I would say. On the other hand, due to the birthday paradox, there is the possibility that given a large enough population, there may be collisions. If there are HITs in total, of which are used, the probability that there is at least one collisions is m - 1 m - 2 m - 3 m - n + 1 p = 1 - ------- * ------- * ------- * ... * ----------- m m m m Since in our case m >> n , the approximation m - 1 = m - 2 = m - 3 = ... m - n + 1 still gives a reasonable bound for the probability, the real probability being lower. Hence, (m - n + 1)^n p < 1 - --------------- m^n m^n - n * m^(n-1) * (n+1) + k * m^(n-2) * (n+1)^2 - .... = 1 - ---------------------------------------------------------- m^n m^n n * m^(n-1) * (n+1) k * m^(n-2) * (n+1)^2 = 1 - ----- + --------------------- - ----------------------- m^n m^n m^n Since m >> n, the series is dominated by the first term, and we can approximate n * m^(n-1) * (n+1) n * (n+1) n^2 p ~= --------------------- = ----------- ~= ----- (as n >> 1) m^n m m Hence, if we have 2^37 HITs used from the population of 2^126 HITs, the probability that there is at least one collision is in the order of (2^37)^2 2^74 p ~= ---------- = ------- = 2^-52 ~= 2.2 * 10^-16 2^126 2^126 While this probability is still extremely small, it has less entropy than the currently used cryptographic keys, and therefore can't necessarily be completely ignored. Hence, as a result of this back-of-the-envelope analysis, the answer is "it depends". > would this allow A to perform some sort of attacks to U or to another > party? As Tom already answered, that depends on whether you use just HITs to identify trusted parties (you shouldn't) or if you just the full public key to identify trusted parties. For opportunistic protection, collisions don't really matter due to the small magnitude of probability. --Pekka From miika@iki.fi Thu May 6 09:59:00 2004 From: miika@iki.fi (Miika Komu) Date: Thu May 6 08:59:00 2004 Subject: [Hipsec] Basic question about HIP In-Reply-To: References: Message-ID: On Thu, 6 May 2004, marcelo bagnulo wrote: > Considering that current IPv6 applications use 128 bit long strings (IP > addresses) as endpoint identifiers, so it would be natural for them to use > HITs as endpoint identifiers. I guess that during the first period of > adoption of HIP, HITs will be used as identifiers instead of the HI. So, i > can see the usage of the HIT as a transition tool. But in the long term goal > is that applications will use the HI or HIT? > > In brief, is it recommended that future apps use the HIT or the HI? I see the HIT (and LSI too) as transition tools. In fact, I think I referred to the API scheme that uses the HITs and LSIs as "legacy API" in some earlier discussion on this list. It would seem much nicer to have the whole HI in the application to avoid collisions and allow some modularity in the HIP protocol if the length of the identifiers need to be changed in the protocol itself some day. This, however, requires some changes in the apps... and eventually a new API. I have implemented such an API (called "native HIP API") and it works. I also ported an example application (v6 telnet) to use the API and it works fine too. The native HIP API has a new resolver (HIP counterpart for getaddrinfo) and a nice way to hide the ugly details of HIs and locators. But I would rather postpone the discussion of this topic to June when I am finally going to release the documentation for public consumption and we will have a more solid base for discussion. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From thomas.r.henderson@boeing.com Thu May 6 11:54:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu May 6 10:54:01 2004 Subject: [Hipsec] Basic question about HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060608@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es]=20 > Sent: Thursday, May 06, 2004 1:58 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: RE: [Hipsec] Basic question about HIP >=20 >=20 > Hi Thomas, >=20 > thank you very much for answer. >=20 > I would like to pose an additional question related to this... >=20 > [...] >=20 > > However, operationally, it may be that people use > > HITs as the identifiers themselves, relying on the > > self-certifying property that it is not computationally > > feasible to produce a matching HI given the HIT. >=20 > Well, there is something about this point that puzzles me,=20 > probably because > my lack of knowledge related to this issues, but wouldn't the=20 > fact that the > HIT is fixed to 128 bits may affect this property in the=20 > future? I mean, > AFAIK, as the computational power increases, the length of=20 > public keys has > to be increased in order to preserve the security provided.=20 > However, in the > case of the HITs, the length is fixed, so it won't be=20 > possible to increase > its length. I think that it may be possible to increase the HIT size in the future, if needed, although it may possibly incur as much pain as IPv4 to IPv6 is causing now. It is probably to be avoided. > So, even if today it is not computationally feasible to=20 > produce a HI that > matches with a HIT, would this remain so from 20 years from now? > And if this happens, how would HIP will be affected? >=20 Offhand, I do not know what the timeframe is before this=20 self-certifying property is lost. My guess is that it would be a long time. However, in such a case, you would lose the=20 masquerade protection and would need to do a reverse lookup if you wanted to fully authenticate the HIT. That, I believe, was one reason behind the so-called Type 2 HITs that have the top 60 or so bits allocated to a Host Assigning Authority--=20 to enable reverse lookups. Even in such as case, one would not lose the ability to use type 1 HITs for opportunistic security. Furthermore, there is mechanism in the protocol to support an initiator sending a certificate to back up the host identity. So it is not clear how this would evolve exactly in such a case, but there seem to be a couple of options. But, as Pekka suggested, one should try to use the public key=20 itself if identification is needed, even today. Miika Komu has=20 been studying how we might transition from using the HITs in API=20 calls to using the host identities, and I see that he already=20 replied too. > > In > > that case, it seems that a vulnerability is possible > > if the HI is not consulted or traced back to a trusted > > authority (e.g., an ACL based solely on HITs). >=20 > Considering that current IPv6 applications use 128 bit long=20 > strings (IP > addresses) as endpoint identifiers, so it would be natural=20 > for them to use > HITs as endpoint identifiers. I guess that during the first period of > adoption of HIP, HITs will be used as identifiers instead of=20 > the HI. So, i > can see the usage of the HIT as a transition tool. But in the=20 > long term goal > is that applications will use the HI or HIT? >=20 > In brief, is it recommended that future apps use the HIT or the HI? >=20 Well, I would say "not the HITs". Whether the apps would use HIs=20 directly or something else is an open research area. Tom From pekka.nikander@ericsson.com Fri May 7 03:59:00 2004 From: pekka.nikander@ericsson.com (Pekka Nikander) Date: Fri May 7 02:59:00 2004 Subject: [Hipsec] open issues for issue tracker In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605ED@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605ED@xch-nw-27.nw.nos.boeing.com> Message-ID: <1BF7D8EE-9FFB-11D8-B651-000393CE1E8C@ericsson.com> [Sorry for the delay in processing this.] > [mm] address check RR design (raised by JW yesterday and today) I updated MM issue #3 to reflect this. > [mm] use of multiple SAs (JW, 4/16 message) This is now MM issue #4. For the list of open MM issues, go to http://hip4inter.net/cgi-bin/roundup.cgi/hip-mm/index --Pekka From pekka.nikander@nomadiclab.com Fri May 7 04:12:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri May 7 03:12:00 2004 Subject: [Hipsec] Test, please ignore Message-ID: This is a test message, please ignore. --Pekka From petri.jokela@nomadiclab.com Tue May 11 01:12:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue May 11 00:12:01 2004 Subject: [Hipsec] open issues for issue tracker In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605ED@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605ED@xch-nw-27.nw.nos.boeing.com> Message-ID: On Fri, 30 Apr 2004, Henderson, Thomas R wrote: > [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. I have now closed all these issues. I will open new ones if needed. /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 Tue May 11 01:17:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue May 11 00:17:00 2004 Subject: [Hipsec] Base HIP, issue #29: type 2 HITs Message-ID: The current pre-version of the draft defines type 1 HITs mandatory, but still refers to type 2 HITs that will be defined in the DNS draft. Will this be the case in the DNS draft? IF the DNS draft will define the HIT containing a HAA, this issue could be closed. Else we should remove the reference to the DNS draft and change the text. Comments? /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 Tue May 11 04:07:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue May 11 03:07:00 2004 Subject: [Hipsec] Base HIP: new issues Message-ID: <40A08721.2070701@nomadiclab.com> I added some new issues to the tracker: Issue tracker: http://hip4inter.net/cgi-bin/roundup.cgi/hip-base/index Issue #35: ICMP error type to be used for errors that occur before the cookie has been solved. Issue #36: UPDATE message handling (8.11.) needs some work. Issue #37: the usage of the "Notification data" -field is not clearly defined for the NOTIFY parameter. Issue #38: Size of K in PUZZLE and the Opaque field. Shall we maintain the Opaque field in the PUZZLE/SOLUTION or should we use only ECHO REQUEST/REPLY for this purpose? And what to do with the K that is currently 8 bits in front of the Opaque field: is 8 bits enough, or shall we allocate more space for it? K and Opaque should probably be two different issues, but they are fighting for the same space in the parameter, so that's why I put them under the same issue. Any comments/proposals? /petri From Julien.Laganier@Sun.COM Tue May 11 04:12:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue May 11 03:12:01 2004 Subject: [Hipsec] Base HIP, issue #29: type 2 HITs In-Reply-To: References: Message-ID: <200405111006.56864.julien.laganier@sun.com> On Tuesday 11 May 2004 05:09, Petri Jokela wrote: > The current pre-version of the draft defines type 1 HITs mandatory, > but still refers to type 2 HITs that will be defined in the DNS > draft. Will this be the case in the DNS draft? In the -00pre1 DNS draft I've almost finished, there's still type 2 HITs defined. I do not really have any opinion on whether or not they should exist at all... However, I think that, until we run out of space for type 1 HITs, it might be better to keep the door open. We'll anyway be able to deprecate them latter if we find them useless. > IF the DNS draft will define the HIT containing a HAA, this issue > could be closed. Else we should remove the reference to the DNS > draft and change the text. So what is the WG's feeling? I'll act accordingly: keep/remove these type 2 HIT and HAA from the DNS draft. Thanks, --julien From pekka.nikander@nomadiclab.com Tue May 11 05:37:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 11 04:37:01 2004 Subject: [Hipsec] Base HIP, issue #29: type 2 HITs In-Reply-To: <200405111006.56864.julien.laganier@sun.com> References: <200405111006.56864.julien.laganier@sun.com> Message-ID: <920D1DC9-A32D-11D8-A45A-000393CE1E8C@nomadiclab.com> > So what is the WG's feeling? I'll act accordingly: keep/remove these > type 2 HIT and HAA from the DNS draft. I think that Type 2 HITs and the HAA field are pretty useful for the time being. Once/if we get DHTs/overlays working, the day may come when we don't need them any more. But before that, they are probably useful. Hence, if the design is simple and useful, let's keep them. --Pekka From petri.jokela@nomadiclab.com Tue May 11 09:03:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue May 11 08:03:00 2004 Subject: [Hipsec] Issue 12: Birthday check badly defined In-Reply-To: <90004BF5-9E52-11D8-BF27-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605FA@xch-nw-27.nw.nos.boeing.com> <90004BF5-9E52-11D8-BF27-000393CE1E8C@nomadiclab.com> Message-ID: <40A0CC57.3080600@nomadiclab.com> Pekka Nikander wrote: >> OK, here is what we have converged to: > > > Looks good. > > Others, are you happy with Tom's suggested text? Good text. I will import it into next preliminary version of the draft, and release the pre-version (unless there comes some arguments against the proposed text). /petri From thomas.r.henderson@boeing.com Tue May 11 10:20:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue May 11 09:20:01 2004 Subject: [Hipsec] Base HIP, issue #29: type 2 HITs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04521CD4@xch-nw-27.nw.nos.boeing.com> I would like to keep the potential for future definition =20 of type 2 HITs. Tom From thomas.r.henderson@boeing.com Tue May 11 18:00:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue May 11 17:00:01 2004 Subject: [Hipsec] Base HIP: new issues Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060628@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Tuesday, May 11, 2004 12:56 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Base HIP: new issues >=20 > Issue #38: Size of K in PUZZLE and the Opaque field. >=20 > Shall we maintain the Opaque field in the PUZZLE/SOLUTION or should we > use only ECHO REQUEST/REPLY for this purpose? And what to do=20 > with the K > that is currently 8 bits in front of the Opaque field: is 8=20 > bits enough, > or shall we allocate more space for it? >=20 > K and Opaque should probably be two different issues, but they are > fighting for the same space in the parameter, so that's why I put > them under the same issue. >=20 > Any comments/proposals? >=20 My proposal to put Opaque in the puzzle was strictly a bit conservation proposal-- avoiding another TLV in the R1 if the opaque data was small=20 enough to be stored in a few bytes. =20 4 bytes for K is overkill-- a K larger than 160 doesn't make sense in the context of the SHA-1 hash, and in practice it will be much smaller than 160. Tom From pekka.nikander@nomadiclab.com Wed May 12 03:42:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed May 12 02:42:00 2004 Subject: [Hipsec] Base HIP: new issues In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060628@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060628@xch-nw-27.nw.nos.boeing.com> Message-ID: >> Issue #38: Size of K in PUZZLE and the Opaque field. >> >> Shall we maintain the Opaque field in the PUZZLE/SOLUTION >> or should we use only ECHO REQUEST/REPLY for this purpose? >> And what to do with the K that is currently 8 bits in front >> of the Opaque field: is 8 bits enough, or shall we allocate >> more space for it? >> >> K and Opaque should probably be two different issues, but they are >> fighting for the same space in the parameter, so that's why I put >> them under the same issue. >> >> Any comments/proposals? >> > > My proposal to put Opaque in the puzzle was strictly a bit conservation > proposal-- avoiding another TLV in the R1 if the opaque data was small > enough to be stored in a few bytes. > > 4 bytes for K is overkill-- a K larger than 160 doesn't make sense > in the context of the SHA-1 hash, and in practice it will be much > smaller than 160. I agree with Tom. --Pekka From pekka.nikander@nomadiclab.com Wed May 12 07:27:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed May 12 06:27:00 2004 Subject: [Hipsec] ICMP error types (was Re: Base HIP: new issues) In-Reply-To: <40A08721.2070701@nomadiclab.com> References: <40A08721.2070701@nomadiclab.com> Message-ID: <2A516350-A406-11D8-AD89-000393CE1E8C@nomadiclab.com> > Issue #35: ICMP error type to be used for errors that occur before the > cookie has been solved. Here is a text proposal, based on my earlier comments. --Pekka ----------------------------------------------------------- New subsection (4.3?) to Section 4:
HIP error processing behaviour depends on whether there exists an active HIP association or not. In general, if an HIP security association exists between the sender and receiver of a packet causing an error condition, the receiver SHOULD respond with a NOTIFY packet. On the other hand, if there are no existing HIP security associations between the sender and receiver, or the receiver cannot reasonably determine the identity of the sender, the receiver MAY respond with a suitable ICMP message; see for more details.
----------------------------------------------------------- A change to Section 5.1, HIP Scenarios: Old text: > The receiver 'detects' the situation when it receives an ESP > packet that contains an unknown SPI. The receiving host MAY > send a NOTIFY packet with NOTIFY parameter informing about > invalid SPI or it MAY initiate a new HIP negotiation. > However, > managing such situations is implementation dependent. New text: The receiver 'detects' the situation when it receives an packet that contains an unknown SPI. The receiving host MAY send an ICMP packet with the Parameter Problem type to inform about invalid SPI (see , and it MAY initiate a new HIP negotiation. However, managing such situations is implementation dependent. ----------------------------------------------------------- A change to Section 5.3: Old text: > If a system receives an ESP packet for an unknown SPI, it is > possible > that it has lost the state and its peer has not. It MAY send a > NOTIFY packet with INVALID_SPI error type. Reacting to ESP traffic > with unknown SPI depends on the implementation and the environment > where the implementation is used. New text: If a system receives an ESP packet for an unknown SPI, it is possible that it has lost the state and its peer has not. It MAY send an ICMP packet with the Parameter Problem type, the Pointer pointing to the SPI value within the ESP header. Reacting to ESP traffic with unknown SPI depends on the implementation and the environment where the implementation is used. ----------------------------------------------------------- Changes to Section 5.4.2: Old text: > Receive ESP for unknown SA, send NOTIFY with INVALID_SPI parameter > and > stay at UNASSOCIATED New text: Receive ESP for unknown SA, optionally send ICMP as defined in and stay at UNASSOCIATED ----------------------------------------------------------- Changes to Section 6.2.18 (NOTIFY): - remove Error Type 5, INVALID_MAJOR_VERSION - remove Error Type 11, INVALID_SPI - remove Error Type 30, INVALID_COOKIE_SOLUTION ----------------------------------------------------------- New subsection (6.3) to Section 6:
When a HIP implementation detects a problem with an incoming packet, and it either cannot determine the identity of the sender of the packet or does not have any existing HIP security association with the sender of the packet, it MAY respond with an ICMP packet. Any such replies MUST be rate limited as described in . In most cases, the ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 for ICMPv6), with the Pointer field pointing to the field that caused the ICMP message to be generated. XXX: Should we say something more about rate limitation here?
If a HIP implementation receives a HIP packet that has an unrecognized HIP version number, it SHOULD respond, rate limited, with an ICMP packet with type Parameter Problem, the Pointer pointing to the VER./RES. byte in the HIP header.
If a HIP implementation receives a HIP packet that has other unrecoverable problems in the header or packet format, it MAY respond, rate limited, with an ICMP packet with type Parameter Problem, the Pointer pointing to the field that failed to pass the format checks. However, an implementation MUST NOT send an ICMP message if the Checksum fails; instead, it MUST silently drop the packet.
If a HIP implementation receives an ESP packet that has an unrecognized SPI number, it MAY responder, rate limited, with an ICMP packet with type Parameter Problem, the Pointer pointing to the the beginning of SPI field in the ESP header.
If a HIP implementation receives an I2 packet that has an invalid cookie solution, the behaviour depends on the underlying version of IP. If IPv6 is used, the implementation SHOULD respond with an ICMP packet with type Parameter Problem, the Pointer pointing to the beginning of the Puzzle solution #J field in the SOLUTION payload in the HIP message. If IPv4 is used, the implementation MAY respond with an ICMP packet with the type Parameter Problem, copying enough of bytes form the I2 message so that the SOLUTION parameter fits in to the ICMP message, the Pointer pointing to the beginning of the Puzzle solution #J field, as in the IPv6 case. Note, however, that the resulting ICMPv4 message exceeds the typical ICMPv4 message size as defined in .
----------------------------------------------------------- Change to Section 8.2 Processing incoming application data Old text: > 1. Detect the proper IPsec SA using the SPI. If the resulting SA > is > a non-HIP ESP SA, process the packet according to standard IPsec > rules. If there are no SAs identified with the SPI, the host > MAY > send a NOTIFY packet with error type INVALID_SPI. How to handle > lost state is an implementation issue. New text: Detect the proper IPsec SA using the SPI. If the resulting SA is a non-HIP ESP SA, process the packet according to standard IPsec rules. If there are no SAs identified with the SPI, the host MAY send an ICMP packet as defined in . How to handle lost state is an implementation issue. ----------------------------------------------------------- New subsection 8.5.2 to Section 8.5:
If an implementation receives a malformed I1 message, it SHOULD NOT respond with a NOTIFY message, as such practice could open up a potential denial-of-service danger. Instead, it MAY respond with an ICMP packet, as defined in .
----------------------------------------------------------- New subsection 8.6.1 to Section 8.6:
If an implementation receives a malformed R1 message, it MUST silently drop the packet. Sending a NOTIFY or ICMP would not help, as the sender of the R1 typically doesn't have any state. An implementation SHOULD wait for some more time for a possible good R1, after which it MAY try again by sending a new I1 packet.
----------------------------------------------------------- New subsection 8.7.1 to Section 8.7:
If an implementation receives a malformed I2 message, the behaviour SHOULD depend on how much checks the message has already passed. If the puzzle solution in the message has already been checked, the implementation SHOULD report the error by responding with a NOTIFY packet. Otherwise the implementation MAY respond with an ICMP message as defined in .
----------------------------------------------------------- I don't think that Sections 8.8 or 8.11-8.15 need anything specific. Should there be a generic subsection in 8., maybe 8.16, that defines the general rules? I think not, as they are defined in the new Section 6.3. From kristian.slavov@iki.fi Wed May 12 07:47:01 2004 From: kristian.slavov@iki.fi (Kristian Slavov) Date: Wed May 12 06:47:01 2004 Subject: [Hipsec] Base HIP: new issues In-Reply-To: <40A08721.2070701@nomadiclab.com> References: <40A08721.2070701@nomadiclab.com> Message-ID: <40A20CA6.2010307@iki.fi> Petri Jokela wrote: > I added some new issues to the tracker: > > Issue #35: ICMP error type to be used for errors that occur before the > cookie has been solved. What are those errors? I can think of SRC/DST HITs being wrong, peer's HOST_ID not matching with its HIT, a wrong solution to the puzzle/unable to solve the puzzle and generally invalid I1/R1/I2. Wrong HITs in HIP header should probably lead to silent discard of the packet, or an ordinary ICMP destination unreachable message. If peer's HOST_ID in R1 is different from peer's HIT, then I guess we should drop the R1 and possibly send another I1. I don't think it is rational to send an ICMP message to the responder and "demand" it to fix its HOST_ID TLV and calculate new signature(s). Wrong solution to the puzzle could be notified, although I think every implementation SHOULD know whether or not it solved the puzzle (or else the implementation doesn't work). If the initiator is unable to solve the puzzle, it could request another R1 by resending I1. There is no need for ICMP error message here. For general problems in I1/R1/I2, we could use ICMP Parameter Problem message. Botrh ICMP and ICMPv6 seem to support it. The pointer field in the ICMP PP message could be the offset to the start of the offending TLV. [RFC792, RFC2463] There is a problem, however, that since the ICMP packet does not carry the whole HIP packet, the offsets do not necessarily point to the problem TLV. Especially if there are optional and variable length TLVs. -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 From petri.jokela@nomadiclab.com Fri May 14 06:03:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri May 14 05:03:00 2004 Subject: [Hipsec] Base HIP, issue #29: type 2 HITs In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04521CD4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04521CD4@xch-nw-27.nw.nos.boeing.com> Message-ID: <40A496B4.4000006@nomadiclab.com> Henderson, Thomas R wrote: > I would like to keep the potential for future definition > of type 2 HITs. Ok, I will close the issue and leave the current definition. /petri From petri.jokela@nomadiclab.com Fri May 14 06:08:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri May 14 05:08:00 2004 Subject: [Hipsec] Base HIP: new issues In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060628@xch-nw-27.nw.nos.boeing.com> Message-ID: <40A497FC.9000800@nomadiclab.com> Pekka Nikander wrote: >>> Issue #38: Size of K in PUZZLE and the Opaque field. >>> >>> Shall we maintain the Opaque field in the PUZZLE/SOLUTION >>> or should we use only ECHO REQUEST/REPLY for this purpose? >>> And what to do with the K that is currently 8 bits in front >>> of the Opaque field: is 8 bits enough, or shall we allocate >>> more space for it? >>> >>> K and Opaque should probably be two different issues, but they are >>> fighting for the same space in the parameter, so that's why I put >>> them under the same issue. >>> >>> Any comments/proposals? >>> >> >> My proposal to put Opaque in the puzzle was strictly a bit conservation >> proposal-- avoiding another TLV in the R1 if the opaque data was small >> enough to be stored in a few bytes. >> >> 4 bytes for K is overkill-- a K larger than 160 doesn't make sense >> in the context of the SHA-1 hash, and in practice it will be much >> smaller than 160. > > > I agree with Tom. Ok, we leave it as described in draft version 10-pre2. Issue closed. /petri From Julien.Laganier@Sun.COM Fri May 14 07:45:02 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri May 14 06:45:02 2004 Subject: [Hipsec] Milestone status In-Reply-To: <407E5FA9.8020702@ericsson.com> References: <407E5FA9.8020702@ericsson.com> Message-ID: <200405141337.18522.julien.laganier@sun.com> On Thursday 15 April 2004 12:10, Gonzalo Camarillo wrote: > 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: > 5) Apr 04 First version of the HIP basic rendezvous mechanism > specification. > 5) Julien has agreed to release an initial version of the > rendezvous draft at the end of April or the beginning of May. Hi folks, A pre-version of the rendezvous draft is (finally ;) available at: We would greatly appreciate any comments related to that draft. Thanks, -- Julien Laganier & Lars Eggert From Gonzalo.Camarillo@ericsson.com Tue May 18 03:03:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue May 18 02:03:01 2004 Subject: [Hipsec] Base spec Message-ID: <40A9B337.1050801@ericsson.com> Folks, the cut-off for 00 documents for the San Diego meeting is July 12th. I would like to have a very stable version of the base spec by then. The idea is to have a 3 week WGLC right before San Diego. This way, we could resolve any issue that remained unresolved in the face to face meeting. To meet this time plan, we need to be more aggressive than we have been so far closing open issues. That is, brainstorming time is over. We need to reach rough consensus and close all the open issues in the tracker. Petri will be driving this work until he goes on vacation. Then, Jan will take over the editorship of the document and will release the version that will be WGLCed no later than July 12th. Thanks, Gonzalo From petri.jokela@nomadiclab.com Wed May 19 01:46:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed May 19 00:46:00 2004 Subject: [Hipsec] Base HIP: issue #34, 384-bit group Message-ID: <40AAF203.5070904@nomadiclab.com> We have now the 384-bit group, generated by Tero Kivinen. Thanks! We have discussed where to put the actual definition, and the best place seems to be the base specification. So, I propose to add the group definition in an Appendix and close the issue: --8<--- Appendix G. 384-bit group Note that the 384-bit group is defined only to be used with HIP. The security level of this group is low and it is designed to be used only when the host is not powerful enough (e.g. some PDAs) or when lower security is enough for protecting communication (e.g. web surfing). This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } Its hexadeciaml value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF The generator is: 2. --8<--- From pekka.nikander@nomadiclab.com Wed May 19 04:35:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed May 19 03:35:01 2004 Subject: [Hipsec] Base HIP: issue #34, 384-bit group In-Reply-To: <40AAF203.5070904@nomadiclab.com> References: <40AAF203.5070904@nomadiclab.com> Message-ID: <50F24339-A96E-11D8-B588-000393CE1E8C@nomadiclab.com> > We have now the 384-bit group, generated by Tero Kivinen. Thanks! > > We have discussed where to put the actual definition, and the best > place seems to be the base specification. So, I propose to add the > group definition in an Appendix and close the issue: Looks good to me. --Pekka From Julien.Laganier@Sun.COM Wed May 19 05:10:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed May 19 04:10:01 2004 Subject: [Hipsec] Milestone status In-Reply-To: <407E5FA9.8020702@ericsson.com> References: <407E5FA9.8020702@ericsson.com> Message-ID: <200405191102.23309.julien.laganier@sun.com> On Thursday 15 April 2004 12:10, Gonzalo Camarillo wrote: > These are the milestones we should be looking at: > > 3) Mar 04 First version of the HIP DNS resource record(s) > 3) Julien has agreed to release an initial version of the DNS draft > at the beginning of May. Folks, Last but not least, a preliminary version of the DNS draft is available at: We welcome any comments on this proposal. Note that, however, as I'll be in vacation until June, 1st, I won't be able to process comments until then. Thanks, --julien From petri.jokela@nomadiclab.com Wed May 19 05:36:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed May 19 04:36:01 2004 Subject: [Hipsec] Base HIP: issue #34, 384-bit group In-Reply-To: <16555.7581.742936.213119@fireball.kivinen.iki.fi> References: <40AAF203.5070904@nomadiclab.com> <16555.7581.742936.213119@fireball.kivinen.iki.fi> Message-ID: <40AB280B.8040404@nomadiclab.com> Tero Kivinen wrote: > Petri Jokela writes: > >>We have discussed where to put the actual definition, and the best place >>seems to be the base specification. So, I propose to add the group >>definition in an Appendix and close the issue: > > > I would recommend even stronger language about the weakness of the > group... Some editions and I made a change in the usage: OR => AND. This 384-bit group is defined only to be used with HIP. NOTE: The security level of this group is very low! The encryption may be broken in a very short time, even real-time. It should be used only when the host is not powerful enough (e.g. some PDAs) and when security requirements are low (e.g. during normal web surfing). /petri > >>Appendix G. 384-bit group >> >> Note that the 384-bit group is defined only to be used with HIP. The >> security level of this group is low and it is designed to be used >> only when the host is not powerful enough (e.g. some PDAs) or when >> lower security is enough for protecting communication (e.g. web >> surfing). >> >> This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } >> >> Its hexadeciaml value is: >> >> FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 >> 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF >> >> The generator is: 2. From kivinen@iki.fi Wed May 19 09:51:00 2004 From: kivinen@iki.fi (Tero Kivinen) Date: Wed May 19 08:51:00 2004 Subject: [Hipsec] Base HIP: issue #34, 384-bit group In-Reply-To: <40AAF203.5070904@nomadiclab.com> References: <40AAF203.5070904@nomadiclab.com> Message-ID: <16555.7581.742936.213119@fireball.kivinen.iki.fi> Petri Jokela writes: > We have now the 384-bit group, generated by Tero Kivinen. Thanks! Remember that the strength of that group is about the same than than cipher having key size of 40-50 bits, so assume that it will be broken in few minutes or even in real time... > We have discussed where to put the actual definition, and the best place > seems to be the base specification. So, I propose to add the group > definition in an Appendix and close the issue: I would recommend even stronger language about the weakness of the group... > > Appendix G. 384-bit group > > Note that the 384-bit group is defined only to be used with HIP. The > security level of this group is low and it is designed to be used > only when the host is not powerful enough (e.g. some PDAs) or when > lower security is enough for protecting communication (e.g. web > surfing). > > This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } > > Its hexadeciaml value is: > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF > > The generator is: 2. -- kivinen@safenet-inc.com From petri.jokela@nomadiclab.com Fri May 21 05:54:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri May 21 04:54:01 2004 Subject: [Hipsec] Base draft: Section 11 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605EE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605EE@xch-nw-27.nw.nos.boeing.com> Message-ID: <40ADCF22.8020503@nomadiclab.com> Henderson, Thomas R wrote: >>-----Original Message----- >>From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] >>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 >> > Section 11 > - XXX someone needs to add the BEET reference and fix up this > first paragraph A proposal to get rid off "XXX" in section 11, replace the XXX -paragraph with the following: 11. ESP with HIP HIP is designed to be used in end-to-end fashion. The IPsec mode used with HIP is the BEET mode (A Bound End-to-End mode for ESP) [REF-to-BEET]. The BEET mode provides some features from both IPsec tunnel and transport modes. The HIP uses HITs and LSIs as the "inner" addresses and IP addresses as "outer" addresses like IP addresses are used in the tunnel mode. Instead of tunneling packets between hosts, a conversion between inner and outer addresses is made at end-hosts and the inner address is never sent in the wire after the initial HIP negotiation. When compared to ESP tunnel mode, there is no tunnel overhead in packets. /petri From kristian.slavov@iki.fi Fri May 21 07:07:00 2004 From: kristian.slavov@iki.fi (Kristian Slavov) Date: Fri May 21 06:07:00 2004 Subject: [Hipsec] Base draft: Section 11 In-Reply-To: <40ADCF22.8020503@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040605EE@xch-nw-27.nw.nos.boeing.com> <40ADCF22.8020503@nomadiclab.com> Message-ID: <40ADE129.8010509@iki.fi> Petri Jokela wrote: > > A proposal to get rid off "XXX" in section 11, replace the XXX > -paragraph with the following: > > > 11. ESP with HIP > > HIP is designed to be used in end-to-end fashion. The IPsec mode > used with HIP is the BEET mode (A Bound End-to-End mode for ESP) > [REF-to-BEET]. The BEET mode provides some features from both IPsec > tunnel and transport modes. The HIP uses HITs and LSIs as the "inner" > addresses and IP addresses as "outer" addresses like IP addresses are > used in the tunnel mode. Instead of tunneling packets between hosts, > a conversion between inner and outer addresses is made at end-hosts > and the inner address is never sent in the wire after the initial HIP > negotiation. When compared to ESP tunnel mode, there is no tunnel > overhead in packets. In the HIPL project we currently do not have ESP BEET. Instead, we use transport mode IPsec and do the address mapping "manually" before routing and sending the IPv6 packet. In practise, we do the same thing as the BEET mode does. We just don't do it in the IPsec processing. The end result is the same. If the proposed text is used, is our implementation noncompliant? -- Kristian Slavov, Researcher Helsinki Institute for Information Technology Gsm: +358-40-7220960 From shep@alum.mit.edu Fri May 21 11:57:01 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Fri May 21 10:57:01 2004 Subject: [Hipsec] Base spec In-Reply-To: Your message of Tue, 18 May 2004 09:54:47 +0300. <40A9B337.1050801@ericsson.com> Message-ID: Gonzalo said: > the cut-off for 00 documents for the San Diego meeting is July 12th. I > would like to have a very stable version of the base spec by then. The > idea is to have a 3 week WGLC right before San Diego. This way, we could > resolve any issue that remained unresolved in the face to face meeting. > > To meet this time plan, we need to be more aggressive than we have been > so far closing open issues. That is, brainstorming time is over. We need > to reach rough consensus and close all the open issues in the tracker. > > Petri will be driving this work until he goes on vacation. Then, Jan > will take over the editorship of the document and will release the > version that will be WGLCed no later than July 12th. Is the current editing-in-progress version of the base spec publicly readable somewhere? (And sorry if this was announced before and I missed it.) If not, perhaps it would be a good idea to push out a new revision of the internet draft every other week or so between now and then. That way, I know what I'm reading is up to date. Just a suggestion. (For now, I'm going to go have a look at draft-moskowitz-hip-09.txt .) -Tim Shepard shep@alum.mit.edu From pekka.nikander@nomadiclab.com Fri May 21 13:59:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri May 21 12:59:01 2004 Subject: [Hipsec] Base spec In-Reply-To: References: Message-ID: <77DA753C-AB4F-11D8-81E7-000393CE1E8C@nomadiclab.com> Tim, > Is the current editing-in-progress version of the base spec publicly > readable somewhere? (And sorry if this was announced before and I > missed it.) Petri has been trying to keep a recent version at www.hip4inter.net http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-10- pre2.txt --Pekka From thomas.r.henderson@boeing.com Fri May 21 22:29:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri May 21 21:29:01 2004 Subject: [Hipsec] Base draft: Section 11 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04521DDC@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Kristian Slavov [mailto:kristian.slavov@iki.fi]=20 > Sent: Friday, May 21, 2004 4:00 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Base draft: Section 11 >=20 >=20 > Petri Jokela wrote: > >=20 > > A proposal to get rid off "XXX" in section 11, replace the XXX=20 > > -paragraph with the following: > >=20 > >=20 > > 11. ESP with HIP > >=20 > > HIP is designed to be used in end-to-end fashion. The IPsec mode > > used with HIP is the BEET mode (A Bound End-to-End mode for ESP) > > [REF-to-BEET]. The BEET mode provides some features from=20 > both IPsec > > tunnel and transport modes. The HIP uses HITs and LSIs=20 > as the "inner" > > addresses and IP addresses as "outer" addresses like IP=20 > addresses are > > used in the tunnel mode. Instead of tunneling packets=20 > between hosts, > > a conversion between inner and outer addresses is made at=20 > end-hosts > > and the inner address is never sent in the wire after the=20 > initial HIP > > negotiation. When compared to ESP tunnel mode, there is no tunnel > > overhead in packets. >=20 > In the HIPL project we currently do not have ESP BEET.=20 > Instead, we use transport=20 > mode IPsec and do the address mapping "manually" before=20 > routing and sending the=20 > IPv6 packet. In practise, we do the same thing as the BEET=20 > mode does. We just=20 > don't do it in the IPsec processing. The end result is the same. >=20 > If the proposed text is used, is our implementation noncompliant? >=20 Might be more clear to summarize (last sentence) that=20 "BEET provides IPsec transport mode syntax (no inner headers) with=20 limited tunnel mode semantics (fixed logical inner addresses--=20 the HITs-- and changeable outer IP addresses)." I think that the HIPL implementation is compliant to this explanation. Tom p.s. BEET is expired-- will it be resubmitted? From Gonzalo.Camarillo@ericsson.com Sun May 23 19:46:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sun May 23 18:46:01 2004 Subject: [Hipsec] Base spec In-Reply-To: References: Message-ID: <40B13607.6020507@ericsson.com> Hi Tim, good suggestion. Nevertheless, I do not know whether Petri has enough cycles to release new pre-versions so often. Petri? In any event, the idea is that a person that reads the last available pre-version and the issues in the issue tracker gets an up-to-date idea of what's going on. Thanks, Gonzalo Tim Shepard wrote: > Gonzalo said: > > >>the cut-off for 00 documents for the San Diego meeting is July 12th. I >>would like to have a very stable version of the base spec by then. The >>idea is to have a 3 week WGLC right before San Diego. This way, we could >>resolve any issue that remained unresolved in the face to face meeting. >> >>To meet this time plan, we need to be more aggressive than we have been >>so far closing open issues. That is, brainstorming time is over. We need >>to reach rough consensus and close all the open issues in the tracker. >> >>Petri will be driving this work until he goes on vacation. Then, Jan >>will take over the editorship of the document and will release the >>version that will be WGLCed no later than July 12th. > > > Is the current editing-in-progress version of the base spec publicly > readable somewhere? (And sorry if this was announced before and I > missed it.) > > If not, perhaps it would be a good idea to push out a new revision of > the internet draft every other week or so between now and then. That > way, I know what I'm reading is up to date. > > Just a suggestion. > > (For now, I'm going to go have a look at draft-moskowitz-hip-09.txt .) > > -Tim Shepard > shep@alum.mit.edu -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From petri.jokela@nomadiclab.com Mon May 24 03:00:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon May 24 02:00:01 2004 Subject: [Hipsec] Base spec In-Reply-To: <77DA753C-AB4F-11D8-81E7-000393CE1E8C@nomadiclab.com> References: <77DA753C-AB4F-11D8-81E7-000393CE1E8C@nomadiclab.com> Message-ID: <40B19ACF.2090902@nomadiclab.com> Pekka Nikander wrote: > Tim, > >> Is the current editing-in-progress version of the base spec publicly >> readable somewhere? (And sorry if this was announced before and I >> missed it.) > > > Petri has been trying to keep a recent version at www.hip4inter.net > > http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-10- pre2.txt I'll put next version out soon when the BIRTHDAY / R1_COUNTER related texts have been updated in the draft. It will be out some day this week. After R1_COUNTER related fixes, the most important issue is the UPDATE message handling. Related to issue #37: One question for all: what shall we do with the Notification data -field usage? At the moment, the draft specifies noticiation data field content only for Type 1 error message. For the rest of the types there is nothing specified. So 1) Shall we leave it unspecified at the moment, and concentrate on that issue later. This is by no means a critical issue. 2) Shall we try to define these now. I would go for number 1 choise, and change the issue into "wish" from "bug". /petri From pekka.nikander@nomadiclab.com Tue May 25 10:21:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue May 25 09:21:00 2004 Subject: [Hipsec] Test, please ignore. Message-ID: Testing the shadow archive hosted by the IETF. --Pekka From petri.jokela@nomadiclab.com Fri May 28 08:03:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri May 28 07:03:01 2004 Subject: [Hipsec] Base draft: preliminary version 3 available Message-ID: <40B72801.2080106@nomadiclab.com> Preliminary version 3 of the base draft - draft-moskowitz-hip-10-pre3 - is now available (txt, html, diff 09->10pre3, diff 10pre2->10pre3): http://hip4inter.net/drafts.php Some notes: - Issue #36 (UPDATE): solution to this issue is not yet proposed in this pre-draft - Issue #34: 384-bit group now in Appendix - Issue #35: ICMP fixes - Issue #12: Birthday -> R1_COUNTER fixes /petri