|
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. 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). Moreover, a host assisted ticket based solution will run
into deployment issues in a wireless network where access and paging channels
are scarce resources. 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). 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 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. 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. BR, Kuntal From:
owner-ietf-ipsec-failover@xxxxxxxxxxxxx
[mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of Charlie Kaufman 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." |