Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Mar 2007 13:43:03 +0100

Comments about draft-ietf-mip6-ha-switch-03.txt:

 - I really like the draft as I believe the service it provides is needed
  and is a major missing piece for MIPv6 in the real world but I have
  a critical concern with it: it collides with the IPsec failover
  activity, i.e., we could get two competiting mechanisms for the same
  thing. So this issue must be solved before going further:
   * obviously the basic mechanisms are the same: the server sends to the
    client a "look-somewhere-else" message with a list of potential "better"
    servers.
   * when the message is delivered to the MIPv6 stack the information
    must be propagated IKE, when it is deliveded to IKE (for instance by
    a new notification) it must be propagated to the MIPv6 stack: in all
    cases there must be an API between both.
   * when the two mechanisms overlap they don't handle exactly the same
    cases so we'll need a way to extend the coverage of the chosen one.
   * IKE has a little advantage for the security because it has a secured
    built-in reliable request/reply facility. At the opposite a new
    MH message needs an extra SPD entry, retransmission policy, etc.

 - 1.Introduction (comment): note the security function can be considered
  as an integral part of the Home Agent service.

 - 4.1 Sending Home Agent Switch Messages "o A home  agent to mobile
   node authentication option": this idle introduces a bidding down
   security issue. I propose to say the authentication MUST use the
   same mechanism than BU/BA (this is what we want and this should keep
   everybody happy :-).

 - 5.1 Receiving Home Agent Switch Messages "o The packet MUST be
   authenticated, either...": same issue (and same proposed solution).

 - 5.1 Receiving Home Agent Switch Messages: the presentation can suggest
   the connection to a new HA has to be done after leaving the current one
   (obviously this is not the intended behavior).

 - 5.1 Receiving Home Agent Switch Messages:
   perform home agent discovery -> perform home agent address discovery?

 - 9. Security Considerations: again...

 - 9. Security Considerations: use the home agent -> use a home agent?

Regards

[email-masked]

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

---

From: Brian Haley <[email-masked]>
Date: Mon, 19 Mar 2007 14:48:48 -0400

Hi Francis,

Just re-reading emails before the WG meeting tomorrow and decided I 
should comment on this.

First, thanks for the comments, I do have a few questions.

>     MH message needs an extra SPD entry, retransmission policy, etc.

Sorry, I don't have any knowledge of the IPsec failover activity you 
mentioned and how it would compete with HA-switch.  Can you point me at 
a draft?  I don't follow any IETF IPsec-related WGs at the moment.

It is true that there might have to be some API between the network 
stack and IKE, but it won't be necessary in all cases (and like Hui 
mentioned, isn't a MIPv6-specific requirement).  In the HA-reliability 
case, the MN will have an SA with every HA already, so won't need to 
tell IKE to do anything during a switch.  In the non-HA-reliability case 
there will be more work for the MN to do.

I'm also not sure that trying to switch to using a different 
infrastructure (IKE) will fit in the timeframe in which a switch 
mechanism is required.

>   as an integral part of the Home Agent service.

Did you want me to add some text?

>    same mechanism than BU/BA (this is what we want and this should keep

This issue will be on the slide at the WG meeting for discussion, I 
suppose it would make it both easier to specify and implement, and would 
support any future BU/BA security mechanism.

>    (obviously this is not the intended behavior).

There are two cases here:

1. Switch is from current HA - in this case you would break-before-make 
and teardown the old binding before replacing with one at the new HA. 
If we don't do this then ND-proxy could fail with the new HA, along with 
the BU.

2. Switch is from new HA - you would just send a BU to the new HA, 
assuming your current HA is dead.  This method is assumed in the 
HA-reliability case.

>  - 9. Security Considerations: use the home agent -> use a home agent?

Thanks for the other editorial changes, I'll fix them in -04.

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Mar 2007 10:00:58 +0100

In your previous mail you wrote:

   Hi Francis,

   
   >     MH message needs an extra SPD entry, retransmission policy, etc.
   
=> as I've fixed the IPsec failover list address I've kept this long part.

=> IMHO the easiest and fastest way is to go and/or read the agenda of
the "ifare" BOF (tomorrow morning).

   tell IKE to do anything during a switch.

=> can I translate this into it doesn't matter to keep unused IPsec SAs
until they timeout?

   In the non-HA-reliability case  there will be more work for the MN to do.

=> collaboration can help, no collaboration is likely a source of slow down.

   
=> IMHO only on good opportunity or if someone (else) asks for this.

   
=> what do you think about my proposal?

   
   
=> IMHO this is not so clear:
 - the current HA can be clever enough to avoid the ND-proxy issue because
  it knows exactly what should happen.
 - when you move to another home link there is not possible ND-proxy issue.
So the problem is not a wording problem as I believed, perhaps we need
an explicit "break-before-make is authorized" notification.

Thanks

---

From: Brian Haley <[email-masked]>
Date: Tue, 20 Mar 2007 15:08:10 -0400

> the "ifare" BOF (tomorrow morning).

That's a long walk from my office in the US :)

Quoting text from VijayD on another list since it seems related:

"I am not sure how IFARE is related to this. IFARE does not address
transferring IPsec state. It is more explicitly moving a client to
another VPN gateway (load balancing, failover, etc..). So transferring
IPsec state is out of scope for IFARE also."

After reading the proposed charter that seems correct to me too.

> => can I translate this into it doesn't matter to keep unused IPsec SAs

Yes, in the ha-reliability case we might have unused SAs for all the 
backup HAs.

> => collaboration can help, no collaboration is likely a source of slow down.

If IFARE turns-into a WG and decides to work on HA IPsec failover that's 
great, it can specify a new protocol that supercedes HA-switch, but the 
HA-switch draft is pretty complete today.

> => what do you think about my proposal?

I would support the change, but wanted to get the other author's and WG 
feedback.

> an explicit "break-before-make is authorized" notification.

The other HA *should* be smart and not require the break, but we can't 
assume that's the case.  The only alternative right now (finding a new 
HA when yours isn't responding) behaves the same way, ha-switch is just 
a way to speed-up that process.  The ha-reliability soft switch mode is 
more desirable of course.

Thanks,

-Brian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Mar 2007 17:25:20 -0700

So, it sounds like there is some confusion on what IFARE is proposing to
do. IFARE is very much related to failover and state transfer (even if
the client is only resuming a session with the same IPsec gateway) and
very much unrelated to load balancing. 

Fundamentally, a failover solution must deal with state transfer. The
IFARE charter proposes dealing with both stateless and stateful modes of
operation - stateless mode implies state is stored in the client and
presented to the gateway upon session resumption; stateful mode implies
state is stored in the infrastructure. 

The main motivation for IFARE stems from the MIP6 use case, although
there is nothing limiting the solution to that use case. If you are in
Prague, please do plan on attending the BoF tomorrow morning. 

Thanks,
Vidya

> -----Original Message-----
> From: Brian Haley [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 12:08 PM
> To: Francis Dupont
> Cc: [email-masked]; Basavaraj Patil; [email-masked]
> Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt
> 
> Francis Dupont wrote:
> 
> "I am not sure how IFARE is related to this. IFARE does not 
> address transferring IPsec state. It is more explicitly 
> moving a client to another VPN gateway (load balancing, 
> failover, etc..). So transferring IPsec state is out of scope 
> for IFARE also."
> 
> > => can I translate this into it doesn't matter to keep unused IPsec 
> > SAs until they timeout?
> 
> Yes, in the ha-reliability case we might have unused SAs for 
> all the backup HAs.
> 
> If IFARE turns-into a WG and decides to work on HA IPsec 
> failover that's great, it can specify a new protocol that 
> supercedes HA-switch, but the HA-switch draft is pretty 
> complete today.
> 
> I would support the change, but wanted to get the other 
> author's and WG feedback.
> 
> The other HA *should* be smart and not require the break, but 
> we can't assume that's the case.  The only alternative right 
> now (finding a new HA when yours isn't responding) behaves 
> the same way, ha-switch is just a way to speed-up that 
> process.  The ha-reliability soft switch mode is more 
> desirable of course.
> 
> Thanks,
> 
> -Brian
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Mar 2007 10:20:14 +0100

=> this is why I added "read the agenda..." (:-).

   
   
=> I don't know what is exactly "transferring IPsec state" but low
latency failover (something is the slide in the screen now at ifare
session) should include something at least close...

   
=> I believe that nobody wants two competitive protocols doing the same
thing... BTW I checked at the beginning of the session whether such
collaboration was in the agenda and the answer was yes (BTW I specified
the mobile IP cloud because of the proposed merge of mip6/nemo/monami6).

   assume that's the case.

=> but the current HA has a better knowledge of the context so IMHO
we should use it to control the way the switch could be done when
some ways can raise issues.

   The only alternative right now (finding a new 
   HA when yours isn't responding) behaves the same way, ha-switch is just 
   a way to speed-up that process.

=> in fact I don't believe it is true because the client doesn't know if
things were broken for the HA... So you can have a HA only working for
the ND-proxy part and messing the DAD from the other HA! Of course
this is not really related to the HA-switch protocol (i.e., there is
nothing we can do so nothing to put in the document).

   The ha-reliability soft switch mode is more desirable of course.
   
=> yes but the world is not (yet :-) perfect.

Thanks