Hi Raj,
No, RFC 5685 tried for generality without defining the usage scenario in
advance, and this attempt failed. The solution cannot be used
gateway-gateway, because it depends on the (arbitrary)
initiator/responder distinction.
Thanks,
Yaron
On 30.3.2010 15:43, Raj Singh wrote:
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
<mailto: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>
<mailto: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> <mailto:IPsec@ietf.org
<mailto:IPsec@ietf.org>>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
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
