Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

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.hoffman@vpnc.org
> <mailto:paul.hoffman@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