Hi Yaron, You are saying the same things what i am saying, then i am not able to understand how its counter example? The point i want to make here, "We can emphasize the main use case scenario the draft, but protocol should have a space for generality". According to me RFC - 5685 is good example of the above.
Best regards, Raj On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer <yaronf.i...@gmail.com>wrote: > 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
