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

["Narayanan, Vidya" <vidyan at qualcomm.com>]

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:brian.haley at hp.com] 
> Sent: Tuesday, March 20, 2007 12:08 PM
> To: Francis Dupont
> Cc: mip6 at ietf.org; Basavaraj Patil; ietf-ipsec-failover at vpnc.org
> Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt
> 
> 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
> 

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