I agree with Scott's position. In the case of site-to-site VPN, where
SAs are NOT set up by configuration, but rather triggered by traffic,
you can have a tunnel triggered by traffic from A to B, but later mostly
used in the opposite direction. This would benefit from allowing the
original responder to be a token taker.
And to answer Tero's original concern, if we require the token maker's
SPI to be unpredictable, then we don't need to worry about token
stealing and we can send the token in the first IKE_AUTH message. Which
would make things a little more regular.
Thanks,
Yaron
On 09/10/2010 06:02 PM, David Wierbowski wrote:
Tero writes:
Paul Hoffman writes:
True, we need some other term for it. Something like the original
IKE_SA_INIT initiator or the party initiating the initial connection
(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
exchanges and rekeys can only be sent by the peer who originally sent
them in the IKE_AUTH, and in IKE_AUTH limit the QCD_TOKEN to the
responder.
Is this added complexity really needed? It sounds like a dangerous
addition. Please be sure the value is actually worth the risk.
I am suggesting simplyfying the protocol, not adding complexity. It
might add some text to the specification, but reduce code from the
implementation, as then implementation is always either token maker or
taker, never both.
I disagree with this "simplification." Tero's logic is that this does make
sense in some cases (e.g. his case), so let's disallow it. As Scott Moonen
pointed out, there are cases where it is perfectly valid to expect either
endpoint to send the next packet and cases where it makes sense that either
endpoint can initiate the creation of an IKE SA. I see no reason to
restrict who can be a token maker and a token taker. IMHO, Adding this
restriction just reduces the potential effectiveness of the solution.
Dave Wierbowski
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
