+1 for leaving it as-is. Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen
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
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
