Samita Chakrabarti writes: 1. HA De-registration During de-registration process, MN sends BU with lifetime=0 to HA. After successful processing HA wants to send BA back to MN, HA does Neighbor Soliciation to MN to update its neighbor cache entry. Problem : section 11.5.4 states: " After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations from its home agent." Some MN implementations don't respond if the source address of the NS is link-local; it only replies when source address of NS from HA is global. Proposal : Should the draft clarify that MN should respond to all scopes of NS source address ? ------------------ Jari Arkko responds to Samita Chakrabarti: Interesting. Yes, I suppose this is necessary. I looked at RFC 2461 but it gives some freedom for choosing the source address, so we can't stick to one. Suggested text: "... from either the link-local address of the home agent or from any of its global addresses." Question: do we need to clarify where these addresses come from? I suppose the link-local address comes from the RA, and the global addresses come from the PI options? ------------------ Ed Remmell: Or, "just say no" to sending the BU with L=1 ;-) ------------------ Vijay Devarapalli responds to Ed Remmell: Ed, you got it wrong. here is the real issue. there is a tiny window when the MN comes home, where both the HA and the MN are both capable of defending MN's home address. the MN sends a deregistration BU. but before the HA responds with a Bind Ack, if somebody sends a NS for MN's home address, should the MN respond? It could be the HA itself doing the NS. the HA sends out the NS when it tries to send the binding ack (it doesnt have a neighbor cache entry for the MN's home address). The spec currently says MN should respond to NS from the HA. but if the HA uses link local address as the source address of the NS, the MN cant figure out if it is the HA sending the NS or it is some other node on the home link sending the NS. if the HA uses its global address as the source address for the NS, the MN can immediately recognize that it is the HA sending the NS. IMO, there is no harm in the MN replying to any NS in this tiny window. it is possible that some node on the home link might get two Neighbor Advertisments for the MN's home address in this window. but this is such a rare case, we shouldnt worry about it at all. we dont have to change any spec if we follow this. ------------------ Ed Remmell responds to Vijay Devarapalli: Hmmm... thanks, I'm not sure what I was thinking. Perhaps I was thinking that I would send the deregistration BU using the link-local scope address of the MN (since I register with L=0, I can still freely use that address when I return to home, the HA is not defending it). But then the specification (and the IPsec security policies) require that I send the deregistration BU with the source address being the home address. Is it possible for me to send the deregistration BU with the source address being my link-local scope address but using the Home Address destination option? If so, I'd prefer to do it that way, so I can avoid this other requirement about who I can and can't respond to w/ regards to the NS targeting my home address. I agree with your statement: " IMO, there is no harm in the MN replying to any NS in this tiny window. it is possible that some node on the home link might get two Neighbor Advertisments for the MN's home address in this window. but this is such a rare case, we shouldnt worry about it at all. we dont have to change any spec if we follow this." The MN is deregistering at this point in time anyways. ------------------ Vijay Devarapalli responds to Ed Remmell: You should be able to do this. but remember you cant set the L bit to 1, if you use this method. ------------------ Greg Daley responds to Vijay Devarapalli: It's important to note that the MN arriving home will be able to send its NA with O bit set. this will override the existing HA NA, which will be using proxy-ND (O bit cleared). There is really no problem with both the HA and the MN sending the NA to anyone, since the MN wins any ND contest. ------------------ Samita Chakrabarti responds to Jari Arkko: > Suggested text: "... from either the link-local address of the home > agent or from any of its global addresses." Ok. But does the MN know about HA's link-local address ? > Question: do we need to clarify where these addresses come > from? I suppose the link-local address comes from the RA, > and the global addresses come from the PI options? Vijay explained: > the spec currently says MN should respond to NS from the HA. but > if the HA uses link local address as the source address of the NS, > the MN cant figure out if it is the HA sending the NS or it is > some other node on the home link sending the NS. if the HA uses > its global address as the source address for the NS, the MN can > immediately recognize that it is the HA sending the NS. > > IMO, there is no harm in the MN replying to any NS in this tiny > window. it is possible that some node on the home link might get > two Neighbor Advertisments for the MN's home address in this > window. but this is such a rare case, we shouldnt worry about it > at all. we dont have to change any spec if we follow this. For clarity, I'd think, HA should include PI with NS if it uses link-local address as its source address (since RFC2461 is liberal about scope of source address of NS), so MN can verify that it's indeed coming from the HA. On the other hand if we say that NA from MN's hoa always over-rides the proxy NA from HA, I am afraid, that might create some security hole. What if a malicous node starts sending NA by using a MN's home address while the HA is defending the actual MN's address. Is it a valid concern ? ------------------ Jari Arkko responds to Samita Chakrabarti: > For clarity, I'd think, HA should include PI with NS if it uses > link-local address as its source address (since RFC2461 is liberal > about scope of source address of NS), so MN can verify that it's indeed > coming from the HA. This would seem possible. But I think the MN would know the home agent's link-local address. Every RA MUST use a link-local address, and presumably we must have seen an RA to even know that this particular home agent is on the link? This still leaves the possibility that if the home agent has multiple link-local addresses, the NS could come from a different one than the RA. Hmm... perhaps this is an issue. > On the other hand if we say that NA from MN's hoa always over-rides > the proxy NA from HA, I am afraid, that might create some security > hole. What if a malicous node starts sending NA by using a MN's home > address while the HA is defending the actual MN's address. Is it a > valid concern ? This is possible in any case, until SEND comes around. So lets not try to solve that here. So, we appear to have the following possibilities: 1. Vijay: Just allow the MN to respond to NS starting from the sending of the BU, not from the reception of the BA. 2. Samita: Use a PI option in the NS to distinguish the HA from other senders. 3. Jari: Rely on NS and RA to come from the same link-local address. Or require this. I think we should do #2 or #1. It is not very clear to me which one should be preferred. ------------------ Vijay Devarapalli responds to Jari Arkko: Lets go with #1. I feel we are wasting our time discussing such a minor issue. the window of this happening would be in terms of milliseconds. and there is no harm done, because the NA from the mobile node overrides the proxy NA from the home agent. Vijay Devarapalli continues: I guess I was not very clear in my earlier mail. my proposal is to let the MN respond to any NS. ------------------ Ed Remmell responds to Vijay Devarapalli: Yes, please, I'm strongly in favor of this, it is much simpler for the MN. ------------------ Samita Chakrabarti writes: Ideally, the MN should not respond to any NS in the home-network before it finishes de-registering; so I thought it should make sure to check whether this NS is from its own HA. But if it's harmless (not clear to me) for the MN to respond to any NS before it de-registers, then I am OK with #1, because it's less work for the MN. ------------------ Jari Arkko: Meeting result: Most people seem to be in favor of approach #1. Official minutes of IETF-56: 279 - NS src addr from HA to figure out the MN's addr Proposal 1: start answering NSes after sending the BU Jari: I prefer proposal 1 ??: agree with proposal 1 TJ: I also agree ------------------ Jari Arkko writes: I'm trying to close issue #279, which had to do with the source address of Neighbor Solicitations from the home agent when the mobile node is returning home. In IETF-56, we discussed a number of alternatives. Most people seemed to favor an approach originally suggested by Vijay, where the mobile node can start answering Neighbor Solicitations sent from any address, right after it has sent a Binding Update, even before receiving a Binding Acknowledgement. The current text is After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations from its home agent. The replies MUST be sent using a unicast Neighbor Advertisement to the home agent's link-layer address. The problem was that we didn't know which address the home agent would use, so it couldn't really be implemented. Here's the text proposal that relaxes the rule so that the check for the home agent is no longer necessary: After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations for its home address. Such replies MUST be sent using a unicast Neighbor Advertisement to the sender's link-layer address. It is necessary to reply, since sending the Binding Acknowledgement from the home agent may require performing Neighbor Discovery, and the mobile node may not be able to distinguish Neighbor Solications coming from the home agent from other Neighbor Solications. Note that a race condition exists where both the mobile node and the home agent respond to the same solicitations sent by other nodes; this will be only temporary, however, until the Binding Update is accepted. ------------------ Ed Remmell writes: Looks good to me. ------------------ ------------------ ------------------