Subject: [IPsec] QCD applicability (issues #198 and #201)

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 14:36:28 +0200

Hi all

An issue that has come up on this mailing list, and also in Beijing, is what implementations should assume either of the two roles (token maker and token taker).

The current text is in section 9.1, and is summarized as follows:
   o  For remote-access clients it makes sense to implement the token
      taker role.
   o  For remote-access gateways it makes sense to implement the token
      maker role.
   o  For inter-domain VPN gateway it makes sense to implement both
      roles, because it can't be known in advance where the traffic
      originates.
   o  It is perfectly valid to implement both roles in any case, for
      example when using a single library or a single gateway to perform
      several roles.

Tero's comments were that the interdomain case (bullet #3) was not interesting (issue #201), because in inter-domain VPN, both sides can start an Initial exchange, or that the initiator and responder should only be taker and maker respectively (issue #198).

While I think few would argue that a remote access client needs to be a token maker, there were some people (including all document authors) who argued that QCD is useful for inter-domain, and that it shouldn't matter who was the original initiator, because over the life of an SA traffic might shift to be initiated on the other side.

I think it's time to resolve this. Do we leave this as-is, or do we cut down the applicability.

Yoav

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 13 Dec 2010 09:08:28 -0500

+1 for leaving it as-is.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	Yoav Nir <[email-masked]>
To:	"[email-masked]" <[email-masked]>
Date:	12/13/2010 07:36 AM
Subject:	[IPsec] QCD applicability (issues #198 and #201)
Sent by:	[email-masked]

Hi all

An issue that has come up on this mailing list, and also in Beijing, is
what implementations should assume either of the two roles (token maker and
token taker).

Tero's comments were that the interdomain case (bullet #3) was not
interesting (issue #201), because in inter-domain VPN, both sides can start
an Initial exchange, or that the initiator and responder should only be
taker and maker respectively (issue #198).

While I think few would argue that a remote access client needs to be a
token maker, there were some people (including all document authors) who
argued that QCD is useful for inter-domain, and that it shouldn't matter
who was the original initiator, because over the life of an SA traffic
might shift to be initiated on the other side.

I think it's time to resolve this. Do we leave this as-is, or do we cut
down the applicability.

Yoav
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Dec 2010 17:39:50 +0200

+1, both peers should be able to assume one or both roles.

Thanks,
	Yaron

On 12/13/2010 04:08 PM, Scott C Moonen wrote:
> Inactive hide details for Yoav Nir ---12/13/2010 07:36:47 AM---Hi all An
> issue that has come up on this mailing list, and also Yoav Nir
> ---12/13/2010 07:36:47 AM---Hi all An issue that has come up on this
> mailing list, and also in Beijing, is what implementations
>
> ------------------------------------------------------------------------
>
>
>
> Hi all
>
> what implementations should assume either of the two roles (token maker
> and token taker).
>
> interesting (issue #201), because in inter-domain VPN, both sides can
> start an Initial exchange, or that the initiator and responder should
> only be taker and maker respectively (issue #198).
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Dec 2010 17:36:42 +0200

> cut down the applicability. 

I am in favor of making the protocol simplier to implement and
especially much simplier to test, and restrict the token taker and
token maker roles to initiator and responder respectively.

In site to site VPN case there are more efficient methods for recovery
which are faster than QCD and which are already allowed in IKEv2
specification and do not require special handling from the other end.

I have explained those in my previous emails:

http://www.ietf.org/mail-archive/web/ipsec/current/msg06573.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg06579.html
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Dec 2010 12:16:27 -0800

We have heard very few comments on this thread, and yet it is an important one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 09:52:04 -0800

I am going to close these issues accepting Yoav's proposal from 2010-12-13.

Not only would it be nice, but it would be *really useful to the IPsec community*, if there were more people in the WG who were reading our two remaining documents and commenting on the open issues...

--Paul Hoffman, Director
--VPN Consortium