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

["Chowdhury, Kuntal" <kchowdhury@xxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan@xxxxxxxxxxxx]
> Sent: Wednesday, December 05, 2007 2:19 PM
> To: Chowdhury, Kuntal; Charlie Kaufman; ietf-ipsec-failover@xxxxxxxx
> Cc: tim.polk@xxxxxxxx
> Subject: 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.
> 
[KC>] That was not my understanding. Hannes, please correct me if I am
wrong. BTW, if it was supposed to be a private discussion among the
co-authors of your solution, it was not necessary to announce it on the
mailing list. Regardless of the intent of yesterday's session, in my
opinion, it is very premature to adopt a solution in IETF w/o agreeing
on what we are solving.


> >
> >
> > 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.
> 
[KC>] But, in the network there will be two gateways active for same the
IP session for the same host. The two gateways will advertise the same
prefix into the routing infrastructure (if IP address is ported in the
failover solution, if not Mobile IP is out of question in the solution
scope). Potentially all the access related functions e.g. charging will
happen in both the gateways. Perhaps, you may not see any problem with
that kind of situation, but I do see issues here. 


> > 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.
> 
[KC>] The whole solution raises alarm. The reason is not the "size" of
the ticket, but the number of the hosts impacted due to a gateway
failure and the need for each of the hosts to do ticket exchange
one-by-one. This simply does not scale in real practical deployments
with the gateways potentially maintaining millions of sessions. Network
node failure handling that involves the client/host in the large
wireless system does not scale.


> >
> > 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.
> 
[KC>] If the MN is switching HoA during the failover, Mobile IP is out
of scope of the solution. In that case, the host/client can easily do
regular IKEv2 RT instead of ticket exchange. After all, it has bigger
issues to tackle, such as reestablishing all its sessions, application
registrations, and presence updates etc. etc.

> >
> >
> > 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.
>
[KC>] That's exactly the point. The protocol is client initiated. Hence,
the client can initiate ticket exchange due to any reason due to any
trigger. There is no way controlling a misbehaving or confused client. 

 
> >
> >
> > 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.
> 
[KC>] I don't believe the community that agreed to discount gateway -
gateway communication represents the folks in the mobility area. 


> >
> >
> > 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.
> 
[KC>] That's the objection I am raising. It won't be acceptable to me,
if the gateway - gateway communication is left out of scope for IPsec
failover.
If you want to work on other items like "IKEv2 session resumption", you
can redefine the problem statement and go from there....



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