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

[Brian Haley <brian.haley at hp.com>]

Francis Dupont wrote:

>    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.
>    
> => IMHO the easiest and fastest way is to go and/or read the agenda of
> 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.

>    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.
>
> => 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.

>    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.
>    
> => 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.

>    >  - 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 :-).
>    
>    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.
>    
> => what do you think about my proposal?

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

>    >  - 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).
>    
>    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.
>    
> => 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.

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

_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6