+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:
+1 for leaving it as-is.
Scott Moonen ([email protected])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
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
From: Yoav Nir <[email protected]>
To: "[email protected]" <[email protected]>
Date: 12/13/2010 07:36 AM
Subject: [IPsec] QCD applicability (issues #198 and #201)
Sent by: [email protected]
------------------------------------------------------------------------
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
