================================================ ================= PART1 ======================== ================================================ Hiroshi Miyata: Issue 1:(Editrial) Clarification on deregistration at CN : Draft needs to clarify how the authentication data would be calculated in the case when MN sends de-registration request (BU with lifetime =0) from a foreign link. i.e coa addr != home addr and contains homeaddress option. Normally in CN case Authdata is calculated by using the message COA addr | CNaddr | BU. Should COA addr be replaced by homeaddress in this situation ? ----- Vijay Devarapalli: issue 327 has 4 issues. 1 - ? ----- Jari Arkko: I think part 1 shows that a clarification is needed in the text. Here's the suggested edit: Change Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) Where | denotes concatenation and "correspondent" is the IPv6 address of the correspondent node. Note that, if the message is sent to a destination which is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead the home address from the type 2 Routing header should be used. to Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) Where | denotes concatenation. "Care-of address" is the care-of address which will be registered for the mobile node if the Binding Update succeeds. Note that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. "Correspondent" is the IPv6 address of the correspondent node. Note that, if the message is sent to a destination which is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead the home address from the type 2 Routing header should be used. ----- Brian Haley: The final edits on the issue list for 327 and 331 look ok, but I would leave 332 alone as Ed suggested. ----- Michael Roe: 327 is trickier - 4 separate technical issues, at least 3 of which are to do with what happens when a MN away from home wants to delete its home binding (e.g. if it wants to stop being a mobile node). (a) Computation of authentication data when MN deregisters from a foreign link. You proposed: Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) Where | denotes concatenation. "Care-of address" is the care-of address which will be registered for the mobile node if the Binding Update succeeds. Note that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. This still isn't very clear. I take it that "Care-of address" is meant to be the home address (not the CoA) when the lifetime of the binding is zero? ----- Jari Arkko: Yes. Maybe: Where | denotes concatenation. "Care-of address" is the care-of address which will be registered for the mobile node if the Binding Update succeeds, or the home address of the mobile node if this option is used in de-registration. Note also that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. I think this falls into the category of a clarification rather than a technical change. If people can agree to this, I can notify the RFC editor. ----- Ed Remmell: Looks good to me. ----- Michael Roe: This proposal looks OK to me. It makes me very nervous that we're going to accidentally break something important, but I can't see anything wrong with it. I view it as a technical changte, because it explicitly permits a new case (deregistration while away from home) tnat had not been considered in some of the earlier security analysis of the protocol. So, OK, I don't mind if you go ahead and make this change. ----- ================================================ ================= PART2 ======================== ================================================ Issue 2: (Edtrial) Using Ipsec. Does home agent need to check tunnel outer source address against CoA of the BC? As IPsec common sense, the tunnel outer source address should not be checked. But I-D 24 says that THE source address must be checked. of Ipsec. Does home agent need to check tunnel outer source address against CoA of the BC? It should be clarified. Could you give me the reference> marc@mentat.com ----- Vijay Devarapalli: 2 - HA can skip checking the source address on the outer tunnel if packet is protected by IPsec. for all other tunneled packets, the HA MUST verify the source address on the outer tunnel against the CoA in the binding cache entry. ----- Jari Arkko: Right. Do you have suggested text? Do we need text? ----- Yukiyo Akisada writes: For me, I need the text. At least I was confusing about this behavior when developping the conformance test. Especially, the last paragraph in section 10.4.5 should be more clear. Vijay's sentence makes me clear. ----- Jari Arkko: Ok. I suggest adding the following text to the end of 10.4.5: This check is not necessary if the tunnel packet is accompanied by a valid ESP header. ----- Vijay Devarapalli writes: We probably should make it more explicit by saying This check is not necessary if the reverse-tunneled packet is protected by ESP in tunnel mode. ----- Jari Arkko: Ok. ----- Brian Haley: The final edits on the issue list for 327 and 331 look ok, but I would leave 332 alone as Ed suggested. ----- Michael Roe: 327 is trickier - 4 separate technical issues, at least 3 of which are to do with what happens when a MN away from home wants to delete its home binding (e.g. if it wants to stop being a mobile node). (b) Using Ipsec. Does home agent need to check tunnel outer source address against CoA of the BC? It's OK with me if the tunnel src address isn't checked when using ipsec. ----- Jari Arkko: I think we have agreement on this one. ----- Yukiyo Akisada: It looks fine for me. ----- Michael Roe: Yes, this text is OK with me. ----- ================================================ ================= PART3 ======================== ================================================ Issue 3: (Technical) HA Ipsec. At Deregistration, Does HA need to keep the SPD entry? HoTI w/ Ipsec tunnel from Homelink has to be accepted by HA. The behavior of HA, when MN returns home, have to be clarified. If HA removes the SPD of returning MN, the MN could not send deregistration to CN. Thus, corresponding SPD for incoming HoTI using reverse tunnel must be remain even MN succeed home deregstration. ----- Vijay Devarapalli: 3 - it is not clear to me why the MN is reverse tunneling the HoTi message from the home link. I was at Connectathon, but dont remember the discussion. :( I remember now. the MN sends a de-registration BU from the home link, and wants to send a HoTi message from the home link immediately. if the HA deletes the SPD entries when it deletes the binding cache entry, a reverse tunneled HoTi message could get dropped. it was suggested the Home Agent keep the SPD entries alive for a short while before deleting the SPD entries. or the MN could wait for the binding ack to come back when de-registering from the home link and then send a direct HoTi message (not reverse tunneled) to the CN. ----- Jari Arkko: I like the latter approach better. Is there a need to change text? ----- Ed Remmell: Some comments below about proposed issue #327 changes: > I like the latter approach better. Is there a need to change text? This is tricky when the MN is deregistering when on a foreign link. In this case, there is no clear guidance in the draft about how to support simultaneous MN deregistration of CN RO bindings and MN deregistration with the home agent. The former approach (HA keeps SPD entries alive for some short time after MN deregistration) described above would support this, without requiring changes on the MN. In our MN, when we deregister on a foreign link we do something tricky to handle this scenario: when we still have CN RO bindings to deregister, our deregistration binding update to the home agent is actually a registration binding update with a very short lifetime (so it will expire soon, but it gives us enough time to complete our deregistration of CN RO bindings). This allows us to continue to use the tunnel through the home agent to tunnel the HoTI and CoTI messages to CNs that we deregister RO bindings with. ----- Brian Haley: The final edits on the issue list for 327 and 331 look ok, but I would leave 332 alone as Ed suggested. ----- Ed Remmell: I wasn't suggesting any new material to be added to the draft, I was only being devil's advocate w/ regards to issue #327, specifically: From Vijay's e-mail: > 3 - it is not clear to me why the MN is reverse tunneling > the HoTi message from the home link. I was at > Connectathon, but dont remember the discussion. :( > > I remember now. the MN sends a de-registration BU from the > home link, and wants to send a HoTi message from the home > link immediately. if the HA deletes the SPD entries when it > deletes the binding cache entry, a reverse tunneled HoTi > message could get dropped. it was suggested the Home Agent > keep the SPD entries alive for a short while before deleting > the SPD entries. > > or the MN could wait for the binding ack to come back when > de-registering from the home link and then send a direct HoTi > message (not reverse tunneled) to the CN. I like the latter approach better. Is there a need to change text?" I was giving an example of why the former approach of having the HA keep the SPD around for a short time after the MN deregisters with the HA might be a good recommendation to add to the draft. This would not affect your MN. ----- Michael Roe: 327 is trickier - 4 separate technical issues, at least 3 of which are to do with what happens when a MN away from home wants to delete its home binding (e.g. if it wants to stop being a mobile node). (c) HA Ipsec. At Deregistration, Does HA need to keep the SPD entry? I think that the HA should delete the SPD entry when the MN deregisters. If a MN away from home needs to delete bindings at some CNs, it should delete these first, and then delete the binding at the HA. ----- Ed Remmell: For issue #327, part 3: Perhaps just include a warning to MN implementors that the tunnel through the home agent for sending the HoTI and CoTI to CNs only exists as long as the MN home registration exists, so if the MN needs to deregister with both CNs and with the HA, it should deregister with CNs first if it needs to use this tunnel to send the HoTI and CoTI (which is what we do currently - but we had to figure that out by doing system testing, so it isn't obvious). In the case of the MN deregistering while at home, the MN can send the HoTI and CoTI directly after it has successfully deregistered with the HA. I agree with Michael Roe: "I think that the HA should delete the SPD entry when the MN deregisters. If a MN away from home needs to delete bindings at some CNs, it should delete these first, and then delete the binding at the HA." I agree that it would be too much at this time to add a requirement (or even a recommendation) for the HA that it keep around SPD entries for some period of time to support this tunneling after the MN has deregistered. ----- Jari Arkko: I believe what Ed and others have talked about is a warning to implementers that the tunnel exists only as long as the registration exists. There was some other discussion about keeping SPD entries around, but I think we ended up not wanting to say anything about that. I think this issue is a borderline one. If we really need it, perhaps we can use this text: Note that the tunnel via the home agent typically stops operating at the same time as the registration is deleted. Is it this simple or do you want more? ----- Ed Remmell: "same time as" -> "same time that" "Note that the tunnel via the home agent typically stops operating at the same time *that* the home registration is deleted." ----- Mike Roe: This change is OK with me. ----- ----- ================================================ ================= PART4 ======================== ================================================ Issue 4: (Question) Deregistration BU w/o Home address option have to be Lifetime=0. Following 4 cases would happen. For Sender(MN), C2,C3,C4 must not be generated. For Receiver(HA), When HA reveived C2, C3 or C4, how should it be treated? | Lifetime=0 | Lifetime!=0 | -------------+------------+-------------+ w/ HoA | C1 | C2 | -------------+------------+-------------+ w/o HoA | C3 | C4 | -------------+------------+-------------+ ----- Vijay Devarapalli: This just needs a clarification. if the MN is not including a Home Address Option in a de-registration BU from the home link, it MUST set the lifetime to 0. if the lifetime is 0, it is always a de-registration BU. ----- Jari Arkko: Yes. Need for text change? ----- Yukiyo Akisada writes: I also need the text change about this. It also confused me. ----- Jari Arkko: I have taken another look at the text. Section 11.5.4, Returning Home, says this (my emphasis): A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the *Lifetime field to zero*, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its *home address as the source address* in the Binding Update. Section 11.7.1 (sending bus) says this: o The *packet MUST contain a Home Address destination option*, giving the mobile node's home address for the binding. o The value specified in the Lifetime field SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. Section 10.3.1 (reg), says this: o A *Home Address destination option MUST be present* in the message. Section 10.3.2 (de-reg), says this: A Binding Update is validated and authorized in the manner described in the previous section. Section 9.5.1 (recv bu), says this: o If the Lifetime specified in the Binding Update is nonzero *and* the specified care-of address is not equal to the home address for the binding, then this is a request to cache a binding for the home address. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.1; otherwise, it is processed according to the procedure specified in Section 9.5.2. o If the Lifetime specified in the Binding Update is zero *or* the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3. I think all the above is actually pretty clear. You need to know if you are doing a reg or a de-reg. Then we have the following cases: REG - SENDER: HAO is mandatory, coa!=hoa, and lifetime!=0 RECEIVER: HAO is mandatory, coa!=hoa, and lifetime!=0 DE-REG - SENDER: HAO is optional, coa=hoa, and lifetime=0 RECEIVER: HAO is optional, coa=hoa or lifetime=0 The only things that you can't find from the text are: - For a registration, the lifetime must be non-zero (and not just smaller than the address lifetime). - For a de-registration, Section 10.3.2 refers to 10.3.1 for the validation rules, which include "MUST have HAO". This relates to issue 332 as well (another e-mail). I suggest that the two items be fixed as follows: o The value specified in the Lifetime field SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. => o The value specified in the Lifetime field SHOULD be non-zero and less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. and A Binding Update is validated and authorized in the manner described in the previous section. => A Binding Update is validated and authorized in the manner described in the previous section, except that the use of the Home Address destination option is not required. ----- Brian Haley: The final edits on the issue list for 327 and 331 look ok, but I would leave 332 alone as Ed suggested. ----- Greg O'Shea: FWIW we send HAO in BU to HA when we return home. It is allowed in draft 24 - please do not make any changes that disallow it. ----- Michael Roe: 327 is trickier - 4 separate technical issues, at least 3 of which are to do with what happens when a MN away from home wants to delete its home binding (e.g. if it wants to stop being a mobile node). You proposed: o The value specified in the Lifetime field SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. => o The value specified in the Lifetime field SHOULD be non-zero and less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. Ok, but I would have said that "... the Lifetime field MUST be non-zero and SHOULD be less than or equal to the remaining valid lifetime..." ----- Jari Arkko: I'm going to do editorial changes, or actually have done them already. If its a technical clarification or change, obviously we're not going to do controversial modifications. In fact, we probably shouldn't do a modification if there's even a slightest chance that it might be controversial or problematic. Also, I'd like to get the RFC published this week, which means that we should have an agreement today or early tomorrow. I have a bad feeling about #327. Nothing specific about any proposals, but this seems complicated enough that will get it wrong with 80% probability if we attempt to do it in a couple of days... ----- Michael Roe: I agree with this. I have no problem with fixing the typos, but issue #327 involves technical changes. We've looked at our implementation, and we don't think the proposed changes to resolve #327 will cause us any problems (especially as our MN doesn't bother to inform the HA if a home address is deleted while away from home - our MN just relies on the binding timing out). However, there is a risk that they might break something. I would consider #327 as "possibly controverisal". As you said: > Yes. I have a bad feeling about this one. Nothing specific about any > proposals, but this seems complicated enough that will get it wrong > with 80% probability if we attempt to do it in a couple of days... With this in mind, I'd be in favour of just fixing the typos and leaving draft 24 as it is on issue #327. ----- Vijay Devarapalli: 327 has four parts to it. Which part do you guys think is controversial? The third part? 1, 2 and 4 shouldn't be a problem. I agree 3 is more than just an editorial change or a clarification. ----- Yukiyo Jakisada: >> if you are doing a reg or a de-reg. Then we have the following cases: >> >> REG - SENDER: HAO is mandatory, coa!=hoa, and lifetime!=0 >> RECEIVER: HAO is mandatory, coa!=hoa, and lifetime!=0 >> >> DE-REG - SENDER: HAO is optional, coa=hoa, and lifetime=0 >> RECEIVER: HAO is optional, coa=hoa or lifetime=0 In the result, BU (lifetime!=0) w/o HaO means DE-REG for receiver, right? In my memory, at the last Connectathon, Vijay said that the receiver also requires 'coa=hoa and lifetime=0' for de-registraion. # In this case, the receiver was HA. If the receiver disallows to receive BU (lifetime!=0) w/o HaO for de-registraion, we need text change. Which is the correct way? I'm still confusing. ----- Vijay Devarapalli: >> Vijay said that the receiver also requires 'coa=hoa and >> lifetime=0' for de-registraion. >> # In this case, the receiver was HA. I think I said if the Home Address option is present and home address is equal to care-of, then it means de-registration to the receiver irrespective of what the lifetime field is. if the lifetime is 0, it always means de-registration. >> If the receiver disallows to receive BU (lifetime!=0) w/o HaO >> for de-registraion, >> we need text change. this should be disallowed. ----- Jari Arkko: Unless I'm missing something, with Ed's text for part 2, the only thing that remains for the part 4 is this: o The value specified in the Lifetime field SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. => o The value specified in the Lifetime field MUST be non-zero and SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. If this is it, I think this clarification can be added. Note that the MUST is not a new requirement, all this is really implied by other parts of the spec already. ----- Assuming that this change refers to "11.7.1 Sending Binding Updates to the Home Agent", specifically the list following "To register a care-of address or to extend the lifetime of an existing registration, the mobile node sends a packet to its home agent containing a Binding Update, with the packet constructed as follows:" then I'm OK with this change. ----- Jari Arkko: Yes, that was the intent. ----- Mike Roe: This change is OK with me. If I recall correctly, our implementation sometimes needs to send a BU when the remaining valid lifetime of the CoA is less than 4 seconds. In this case, we make sure to round up to avoid a lifetime of 0. So "MUST be non-zero" and "SHOULD be less than or equal ..." sounds right. -----