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> 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 > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
