Subject: [Mip6] Re: Comments on draft-ietf-mip6-ha-switch-00.txt

From: Brian Haley <[email-masked]>
Date: Tue, 01 Aug 2006 16:22:06 -0400

Hi Alex,

Alexandru Petrescu wrote:
> James Kempf wrote:
>> Actually, no. I was thinking of draft-ietf-mip6-ha-switch-00.txt.
> 
> The draft looks good.
> 
> It describes a message exchange between HA and MN.  A HA
> Switch message (a Mobility Header) is sent by HA to MN, optionally
> providing a list of alternate Home Agents.  The MN replies back with a
> BU requesting deletion of the current BCE.  Subsequently the MN performs
> IKE with a randomly chosen HA in the provided list or HA discovery
> otherwise.  The HA Switch message uses IPsec.
> 
> Could you please clarify whether HA Switch considers only HAs on a same
> home link, or can accomodate on different links too.  Because if the
> latter then it's clear that a Home Address should be acquired too, in
> which case ongoing sessions will be interrupted, a thing which should
> absolutely be mentioned.

It would be assumed that the new HA would have to be able to offer 
services for the home prefix this MN is using, the actual text just 
refers to the home link:

  Home Agent Addresses

      A list of alternate home agent addresses on the home link for the
      mobile node.  The number of addresses present in the list is
      indicated by the "# of Addresses" field in the Home Agent Switch
      message.

Guess we could update the "home link" text with something better.

>> There are various reasons why a mobility service provider might want
>>  to do this; an example is if the service provider revokes the
>> account of a user it has reason to believe might use the old home
>> agent address to disrupt service for other users.  With a signaling 
>> message, the service provider could inform mobile nodes to look for a
>>  new home agent.
> 
> Makes no sense.
> 
> It's sufficient for HA to revoke the key of a disruptive MN and it's
> recommended to do that instead of renumbering its HAs and inform all
> other MNs to switch, too much work.
> 
> It might have made sense if a majority of MNs were disruptive.

Would you prefer we removed the text?

>> The home agent addresses field should be constructed as described in 
>> Section 10.5.1 of [3775].
> 
> That cited section is 2-pages long and starts with a description on how
> to build a home agent list and ends with what should be put in the Home
> Agent Addresses field.
> 
> What that means is basically (1) how to collect information from HA RAs
> and (2) how to sort the HA addresses in the Home Agent Addresses field.
> 
> But this spec mentions scenarios "overloaded", "load balancing",
> "maintenance", "functional load balancing", "HA renumbering" without
> providing means to convert these words into actual Preference and
> Lifetime values in the RA.  I'd have preferred that.

When I wrote that it was under the assumption that the HA list built 
from received RAs already had what we needed - a sorted list of HAs on 
the link, so I didn't want to reinvent text.

We also purposely left any load-balancing requirements out of this draft 
just to focus on the signaling aspect - that could be a whole draft in 
itself.

> Also, this spec says that MN chooses randomly the HA in the HA list, so
> no reason to order the list before sending it.

This was a small attempt to load-balance as you don't want every MN to 
choose the first HA in the list, and you don't want the HA to randomize 
it for every MN.  Again, we assumed we already had a sorted list to work 
with.

>> 4.2 Retransmissions
> 
> It's good to have re-transmissions.
> 
> However, since their very goal is to provide reliability against packet
> loss or re-ordering it would be interesting to have an id in the
> message, and echoed back.

The BU/0 is the ACK essentially, but I think you knew that...

> Doing so would avoid a situation where the HA sends a switch to MN
> suggesting another HA1, then HA1 goes down, and HA sends another switch
> with HA2 inside.  If the first switch message is lost and HA receives
> BU/0 then MN has no more connectivity (because HA1 is down and HA
> believes MN responded to the right switch message).

If the MN loses all of its HAs it should fall-back to some bootstrapping 
mechanism, which is outside the scope of the draft :)

Some of this might be covered better in the ha-reliability draft?

>> Upon receipt of a Home Agent Switch message, the mobile node MUST stop 
>> using its current home agent for services and MUST delete its home 
>> binding by sending a Binding Update message as described in [2].
>>
> I'm not sure about the MUST above, I'd rather make it a SHOULD.  Because
> otherwise someone may come up with the idea that even if the HA is
> loaded and needs to switch MN to another HA then MN is probably in a
> situation where it absolutely wants to continue using this HA, so send
> it back a new message "I don't want to switch".  When can this happen?
> If MN is in the middle of a HoTI/HoT it surely doesn't want to switch HAs.

We used MUST because you have to assume the HA is going down.  If the MN 
ignores it then it's going to lose connectivity and/or have to bootstrap 
again.

Thanks for the feedback.

-Brian

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Aug 2006 12:25:10 +0200

Brian Haley wrote:
>> It describes a message exchange between HA and MN.  A HA Switch 
>> message (a Mobility Header) is sent by HA to MN, optionally 
>> providing a list of alternate Home Agents.  The MN replies back 
>> with a BU requesting deletion of the current BCE.  Subsequently the
>>  MN performs IKE with a randomly chosen HA in the provided list or
>>  HA discovery otherwise.  The HA Switch message uses IPsec.
>> 
>> Could you please clarify whether HA Switch considers only HAs on a
>>  same home link, or can accomodate on different links too.  Because
>>  if the latter then it's clear that a Home Address should be 
>> acquired too, in which case ongoing sessions will be interrupted, a
>>  thing which should absolutely be mentioned.
> 

No, it's fine to me.  I've missed that home link text, sorry.

>>> There are various reasons why a mobility service provider might 
>>> want to do this; an example is if the service provider revokes 
>>> the account of a user it has reason to believe might use the old
>>>  home agent address to disrupt service for other users.  With a 
>>> signaling message, the service provider could inform mobile nodes
>>>  to look for a new home agent.
>> 
>> Makes no sense.
>> 
>> It's sufficient for HA to revoke the key of a disruptive MN and 
>> it's recommended to do that instead of renumbering its HAs and 
>> inform all other MNs to switch, too much work.
>> 

I suggest so.  It can actually be interpreted as a DoS attack: I steal
somebody's MN, the owner signals this to operator and operator renumbers
all other MNs.  Where I live there are about 200.000 stolen mobile
phones a year and about 80% of them are discarded by operator based on
IMEI, just heard on radio.

>>> The home agent addresses field should be constructed as described
>>>  in Section 10.5.1 of [3775].
>> 
>> That cited section is 2-pages long and starts with a description on
>>  how to build a home agent list and ends with what should be put in
>>  the Home Agent Addresses field.
>> 
>> What that means is basically (1) how to collect information from HA
>>  RAs and (2) how to sort the HA addresses in the Home Agent 
>> Addresses field.
>> 
>> "maintenance", "functional load balancing", "HA renumbering" 
>> without providing means to convert these words into actual 
>> Preference and Lifetime values in the RA.  I'd have preferred that.
>> 
>> 
>> 
> 
>  from received RAs already had what we needed - a sorted list of HAs
>  on the link, so I didn't want to reinvent text.
> 
> We also purposely left any load-balancing requirements out of this 
> draft just to focus on the signaling aspect - that could be a whole 
> draft in itself.
> 
>> Also, this spec says that MN chooses randomly the HA in the HA 
>> list, so no reason to order the list before sending it.
> 
> This was a small attempt to load-balance as you don't want every MN 
> to choose the first HA in the list, and you don't want the HA to 
> randomize it for every MN.  Again, we assumed we already had a sorted
>  list to work with.

Brian, I understand now why you need MN to randomize its choice.  Please
allow me to continue if you don't mind.

What exactly will HAs put in the RA Preference and Lifetime?

For example, if all HAs put same Preference value then they must (by
3775) randomize the list, so again MN wouldn't need to choose randomly,
just pick the first.

>> However, since their very goal is to provide reliability against 
>> packet loss or re-ordering it would be interesting to have an id in
>>  the message, and echoed back.
> 

No, I though it's a BU with lifetime 0 so the HA removes the BCE(?).

>> suggesting another HA1, then HA1 goes down, and HA sends another 
>> switch with HA2 inside.  If the first switch message is lost and HA
>>  receives BU/0 then MN has no more connectivity (because HA1 is 
>> down and HA believes MN responded to the right switch message).
> 
> If the MN loses all of its HAs it should fall-back to some 
> bootstrapping mechanism, which is outside the scope of the draft :)
> 

Extending the ha-sync with an id wouldn't make sense there.

BTW, I've tried a little bit to comment on the ha-reliability draft but
I'm not sure about its current scoping.  For example it shows in Figure
2 that the HA that becomes active sends the ha-switch message to MN,
instructing it to use itself.  Or the semantics in this (ha-switch)
draft is that the HA that is about to die instructs the MN to choose
another HA in the provided list.  This is different, which one is the
right one ha-switch or ha-reliability?

>>> Upon receipt of a Home Agent Switch message, the mobile node MUST
>>>  stop using its current home agent for services and MUST delete 
>>> its home binding by sending a Binding Update message as described
>>>  in [2].
>>> 
>> I'm not sure about the MUST above, I'd rather make it a SHOULD. 
>> Because otherwise someone may come up with the idea that even if 
>> the HA is loaded and needs to switch MN to another HA then MN is 
>> probably in a situation where it absolutely wants to continue using
>>  this HA, so send it back a new message "I don't want to switch". 
>> When can this happen? If MN is in the middle of a HoTI/HoT it 
>> surely doesn't want to switch HAs.
> 
> We used MUST because you have to assume the HA is going down.  If the
>  MN ignores it then it's going to lose connectivity and/or have to 
> bootstrap again.

Ok then, more explicitely: what will MN do if receiving ha-switch during
a HoTI/HoT exchange.  Ignore the ha-switch?  Reply to HA something?
Just bootstrap?  Change HA and then instruct MN to re-HoTI/HoT?

Alex

---

From: Brian Haley <[email-masked]>
Date: Wed, 02 Aug 2006 12:55:10 -0400

Alexandru Petrescu wrote:

>>> Also, this spec says that MN chooses randomly the HA in the HA list, 
>>> so no reason to order the list before sending it.
>>
>> choose the first HA in the list, and you don't want the HA to 

Ok, I understand now, don't know how I missed this bullet in 10.5.1:

    o  The IP addresses in the Home Agent Addresses field SHOULD be
       listed in order of decreasing preference values, based either on
       the respective advertised preference from a Home Agent Information
       option or on the default preference of 0 if no preference is
       advertised (or on the configured home agent preference for this
       home agent itself).

So I'll change the ha-switch draft to not have the MN randomly select a 
HA from the message, just use the first, second, etc.

> No, I though it's a BU with lifetime 0 so the HA removes the BCE(?).

That's what I meant with BU/0, my bad shorthand.

>>>  receives BU/0 then MN has no more connectivity (because HA1 is down 
>>> and HA believes MN responded to the right switch message).
>>

HA-switch needs to be updated to support ha-reliability in allowing 
another HA to send the message, didn't have time before the cutoff.

>>>>  stop using its current home agent for services and MUST delete its 
>>>> home binding by sending a Binding Update message as described
>>>>  in [2].
>>>>
>>> Because otherwise someone may come up with the idea that even if the 
>>> HA is loaded and needs to switch MN to another HA then MN is probably 
>>> in a situation where it absolutely wants to continue using
>>> When can this happen? If MN is in the middle of a HoTI/HoT it surely 
>>> doesn't want to switch HAs.
>>

I don't understand why HoTI/HoT is a special case since it's between the 
MN and a CN, as long as the MN can send via a HA and that HA can 
intercept packets for it, mobility should work.

-Brian