Hi Raj,
this in fact is the perfect counter-example: RFC 5685 started out with
the client-gateway scenario, and when we woke up to see how it can be
generalized to the symmetric gateway-gateway case, it was too late.
Hence Sec. 10, which says that the resulting protocol is a very partial
solution for this case.
10. Use of the Redirect Mechanism between IKEv2 Peers
The redirect mechanism described in this document is mainly intended
for use in client-gateway scenarios. However, the mechanism can also
be used between any two IKEv2 peers. But this protocol is
asymmetric, meaning that only the original responder can redirect the
original initiator to another server.
I'm not saying that we were right in ignoring this case. I'm saying that
you can only get the protocol that you want if you define the
requirements clearly up front.
Thanks,
Yaron
On 29.3.2010 16:58, Raj Singh wrote:
Hi Team,
The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is
typical use of Redirect mechanism in IKEv2 where Gateway redirects
client to another less loaded gateway but at the same time RFC is also
applicable to router-router scenario when one router decides to off-load
all existing IKEv2 sessions to another gateway when it goes down for
maintenance etc.
I totally agree with Paul.
Best regards,
Raj
On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <paul.hoff...@vpnc.org
<mailto:paul.hoff...@vpnc.org>> wrote:
<wg-co-chair-hat on>
The disagreement between Dan and Yaron is over wording in the
not-at-all normative criteria draft. This draft is not intended to
become an RFC, and is not binding on the WG. It currently is being
edited by Yaron; soon it will be edited by both Yaron and Dan.
From the active thread the past few days, it seems that Dan
disagrees with Yaron's view that people thinking about the PAKE
primarily as a gateway-to-gateway solution. That's fine: others in
the WG might take one view or the other. I ask that Dan and Yaron
produce an -03 with both views in it. I note that the current WG
charter does not insist that the PAKE we choose be for
gateway-to-gateway, but that it does list "authentication between
two servers or routers" as a motivating scenario, and does not list
remote access as a motivating scenario for the proposed new work.
As WG members consider which criteria are important to them, they
should also consider what scenarios we want to emphasize in the
eventual document. I use the word "emphasize" here because we cannot
prevent implementers and administrators from using the new
authentication mechanism however they want; we have plenty of
experience with IKE and IPsec documents saying "you should use this
in that way" that are merrily ignored by large parts of the market.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
