Re: review for draft-kempf-mipshop-handover-key

Thread: Re: review for draft-kempf-mipshop-handover-key

Search this list only Search all lists
Re: review for draft-kempf-mipshop-handover-key
	2007-01-23 16:46:24
Erik Nordmark reviewed draft-kempf-mipshop-handover-key which was requested by the WG chairs prior to making it a WG draft. Below are my responses to the review. jak -------------------------------------------------------------- > Overall this seems like a reasonable approach, but there are some > details that might need some work. > > Editorial: When I read section 3.1 and 3.2 I was confused. Even though 3.1 > is titled mobile node considerations, in the middle it talks about what > the router does. And it section 3.2 it took me a while to figure out that > the two first paragraphs are about handling RSs and the last is about FBU > messages. > This can be made more clear by structuring the sections differently. > For instance, it might make sense to add a very short subsection in 2 > about protocol overview. That section doesn't need to say more than an RS > with a CGA source address will trigger the router to include the new > handover key options in the RA. > OK. > Then in section 3 one could split the material over more subseqtions e.g. > 3.1 Sending Router Solicitations > 3.2 Receiving Router Solicitations and Sending Router Advertisements > 3.3 Receiving Router Advertisements OK. > 3.4 Receiving FBU messages > (shouldn't there also be some text about how the MN sends FBU messages? > The document doesn't directly say what it should do differently.) > I think what Vidya and I agreed on is that we should focus on key distribution in two different ways in our respective drafts (SEND and AAA), but that the FMIP draft would cover the actual calculation of the authenticator and processing of the FBU including the authenticator. That way, the information isn't duplicated between the two drafts. The only exception is the FBU authentication algorithm type field, which is necessary in order that the router know how strong the key needs to be. > Nit: Section 3.1 last paragraph says "the AR's destination address". > Shouldn't this just be "the AR's address"? > Yes. > Clarity: Section 3.1 last paragraph loosely specifies that goes in the > authenticator. We seem to have a history for mobility protocols where such > text isn't sufficiently detailed to get interoperable implementations thus > I think it makes sense to spell out exactly how this is calculated, > perhaps by using an example. > Right, again, the exact details of how the authenticator on the FBU is calculated need to go in the FBU draft. I do need to make clear here that people need to go there to find it, though. > Editorial: Section 3.2 second paragraph. It isn't clear to me whether or > not the second sentence applies in the case where the signature did not > verify. > I'll add a sentence describing what to do if the signature doesn't verify. > Editorial: Section 3.3 first paragraph says "sufficiently large to > mitigate birthday attacks." To an implementor this doesn't provide much > guidance. Can you add a reference to some document which would provide > guidance to the implementors on what key length to use? > OK. > Technical question: Section 3.3 first paragraph says "The AR MUST generate > a unique key for each CGA key". Is such a requirement common for key > management protocols? For instance, does IKE have the same requirement? > I'm under the naive assumption that other protocols don't require such a > check, and for an AR with lots of MNs checking against all the other > 10,000 keys would be a performance issue. > There is an issue here regarding the risk of compromise. If a unique key per address isn't required, then the compromise of one mobile node could potentially compromise several others. From a quick look at RFC 4306, IKEv2 seems to use new nonces for generating the pseudo-random number, and generates each key from a different pseudo-random number, so the key should be different for each CHILD_SA. > Technical: I don't fully understand the motivation for the lifetime > constraints in section 3.3, and I think the relationship with the > preferred prefix lifetime doesn't help. Instead that leaves the door open > for questions of what happens when a MN moves around while (all) its IPv6 > addresses are deprecated. > If the purpose of these checks is to allow a handover key to be reused > when there is frequent flip-flopping, then wouldn't it be sufficient to > say > The AR SHOULD keep the handover key for a few minutes after it > has been used in order to more effciently handling MNs that move > back and forth between a set of ARs. > If you'd like you can add > The AR MUST NOT retain the handover key after the last > prefix ... has become invalid. > but I don't see what problem that solves. Even if the prefix becomes > invalid and is reassigned to some other part of the network the > probability of a different host selecting the same CGA address is > extremely small. > If my understanding is correct I think you can drop the 2nd and 3rd > paragraph in section 3.3. > Yes, you are right, the purpose is to mitigate ping-ponging. I'll remove the requested paragraphs and add the text you suggest. > Clarity: End of Section 4.1. I think it makes sense to add an example > which shows the pad and the two length fields e.g. for a 14 byte encrypted > handover key. > OK. I'll add that after the text describing the option. > End of section 4.2. Please add an example or text which shows how the > receiver determines the length of the parameter data structure from the > option length and the pad length. > > Also state that pad length can not exceed 7. > OK. > Section 4.1 and 4.2: For the length field description it makes sense to > add this from RFC 2461: > The value 0 is invalid. Nodes MUST > silently discard an ND packet that contains an > option with length zero. > > OK. > Technical: Section 5.0 doesn't talk about the thread of replayed RS > messages, nor about the threat of DoS by sending bogus RS messages > potentially causing the AR to have to generate a new handover key. > (It might be that the latter is no worse than with normal SEND assuming > the RS has a SEND signature to be verified. But if a RS doesn't require > signature verification before the handover key is generated then we could > have a new DoS issue.) > Yes, I need to add these. Thanx for pointing it out. _______________________________________________ Mipshop mailing list Mipshopietf.org https://www1.ietf.org/mailman/listinfo/mipshop