[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Observation from tonight's Bar BOF on IPsec Failover



Kuntal,
A few clarifications inline.  

> -----Original Message-----
> From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx 
> [mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of 
> Chowdhury, Kuntal
> Sent: Wednesday, December 05, 2007 11:28 AM
> To: Charlie Kaufman; ietf-ipsec-failover@xxxxxxxx
> Cc: tim.polk@xxxxxxxx
> Subject: RE: Observation from tonight's Bar BOF on IPsec Failover
> 
> Hello Charlie,
> 
>  
> 
> The summary is good and thanks for sharing it with us. As one 
> of the participants in yesterday's discussion, my observation 
> was that we went into solution discussion too soon w/o having 
> any discussion on the scenario and scope for the proposed 
> work item. I believe there are fundamental differences among 
> the group of participants on the scope/scenario.
> 

Let me provide a fundamental clarfication here.  The purpose of
yesterday's meeting was to discuss the solution and see how it meets the
goals in the problem statement.  It was not to rehash the scope or
scenarios.  This was not a BoF held with a view to forming a WG.  It was
an informal solution discussion that Tim requested so that he can get a
sense of the community's viewpoint of the solution.  Sorry if this
wasn't clear in yesterday's discussion - as I wasn't a part of it, I
can't really tell.  

The goals and scenarios have achieved rough consensus, as described in
the PS.  Let me remind you that you were part of the people who reviewed
the document.  

>  
> 
> However, we spent a good amount of time discussing a solution 
> that is being proposed by a few of the participants. I see 
> that the solution has major issues (I brought up one of them 
> during the discussion, regarding two gateways coming up at 
> the same time in the network for the same host/client simply 
> because there was a transient loss of connection at the host 
> with the existing gateway). 

I see no issues with what you are describing.  The client is still going
to connect only to one of those gateways.  

> Moreover, a host assisted ticket 
> based solution will run into deployment issues in a wireless 
> network where access and paging channels are scarce resources. 
> 

I work for a company that is as deeply into wireless networks as any
other and see no issues with it.  The word "ticket" seems to raise
alarms for the wrong reasons.  The IKEv2/IPsec state contained in this
ticket is not large by any definition of it.  

> 
> Regarding the usefulness of maintaining the internal IP 
> address, it is a fundamental requirement if applicability 
> statement includes mobile IP. Even otherwise, it will be a 
> very strong requirement if the solution is deployed in the 
> real world networks (e.g. 3G wireless networks). 
> 

First of all, while there is no *requirement* to maintain the same
internal IP address, the solution works just the same if the new gateway
is able to allow retention of the same IP address.  And, second, I fully
disagree that the solution is useless without maintaining the same IP
address for the needs of 3G networks or Mobile IP.  A new IP address is
assigned within the same RT that does the failover.  If the mobile nodes
are switching to a new Home Agent, it is not disastrous to switch to a
new home address.  If all the home agents are on the same network
segment, handling the same pool of home addresses, you can use a
VRRP-like solution to handle any failover and really don't need
something that involves the client or a distributed solution. 

>  
> 
> If requirement 4 is not addressed, it won't be a failover 
> solution; it will be rather optimized re-connection mechanism 
> w/Io IP session continuity. Without gateway - gateway 
> communication, we still have to live with the scenario where 
> the host/client brings up multiple IPsec/IKEv2 sessions 
> simply because it is confused, or in a radio fade zone, or 
> simply it is a rouge host/client.  
> 

I have no idea what you are talking about here.  I see no reason why a
host would bring up multiple IKEv2 sessions.  As I said, the protocol is
client-initiated and the client should always only connect to one
gateway, upon a failure. 

>  
> 
> I strongly believe that a scalable and deployable IPsec/IKEv2 
> failover solution must include gateway - gateway 
> communication. It will address all the requirements that you 
> listed below in a much more secure, scalable, and efficient 
> way. I still believe that is how we need to address it. The 
> solution and the direction that some of the participating 
> members want to take unfortunately exclude that in their solution. 
> 

Well, I have to say that that is not the consensus we have in the
community.  The majority of the people were not interested in a gateway
- gateway protocol and more interested in client-gateway
interoperability.  If you think that this solution doesn't meet any
specific goals stated in the PS, please point out which ones and how it
is not met.  Then, we can discuss addressing that. 

>  
> 
> In summary, I would like to say, it is not that we don't want 
> a solution for IPsec/IKEv2 failover. It is the way a solution 
> is being pushed here is what not acceptable. The scope of the 
> work must include gateway - gateway communication for the 
> stated reasons.
> 

Well, there was explicit consensus to keep that out of scope.  It is
possible that an inter-gateway protocol can augment this in the scope of
Mobile IP, but, for IKEv2 session resumption itself, there was no
consensus to address it that way. 

Vidya

>  
> 
> BR,
> 
> Kuntal
> 
>  
> 
>  
> 
> ________________________________
> 
> From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx 
> [mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of 
> Charlie Kaufman
> Sent: Wednesday, December 05, 2007 12:30 AM
> To: ietf-ipsec-failover@xxxxxxxx
> Cc: tim.polk@xxxxxxxx
> Subject: Observation from tonight's Bar BOF on IPsec Failover
> 
>  
> 
> I noticed something at tonight's Bar BOF that I believe will 
> be a critical factor in whether an eventual BOF succeeds: 
> different groups seemed to have very different scenarios they 
> were trying to address (which is OK) and they didn't seem to 
> understand or respect the important scenarios of the other 
> groups (which is not).
> 
>  
> 
> As I see it, there are four things the IPsec Failover 
> protocol is trying to save over just redoing a fresh IKE 
> exchange in the case of failover. The first two relate solely 
> to performance; the second two have user visible implications.
> 
>  
> 
> 1)   The cost of a fresh Diffie-Hellman calculation.
> 
> 2)   The cost of two round trips during the exchange.
> 
> 3)   Rerunning an EAP exchange that could involve user participation.
> 
> 4)   Keeping the "internal" IP address so that open tunneled 
> TCP connections can stay open and applications that cache the 
> client's IP address don't need to be restarted.
> 
>  
> 
> The protocol being proposed could facilitate achieving all of 
> those goals in their particular scenarios. Some people seemed 
> to believe that (4) was the really important consideration 
> and the others were nice-to-have. Others seemed to think that 
> 1-3 were the important considerations and (4) was 
> unrealistic. It is unrealistic in some scenarios, but very 
> realistic in others. MOBIKE provides such capabilities, and 
> it would be worth exploring how much overlap there is in the 
> goals of these two protocols. There may have been people who 
> valued different subsets of those features who weren't quite as vocal.
> 
>  
> 
> If these groups want to jointly present a proposal (and the 
> chances of success are much greater if they do), they need to 
> learn to (at least in "public") speak respectfully of the 
> needs of the other groups - which probably implies 
> understanding them. It appears there is an "everybody wins" 
> protocol on the table; we just all need to get behind it (and 
> its successors).
> 
>  
> 
>                --Charlie
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> postmaster@xxxxxxxxxxxxxxxxxxx -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>