On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote:
> Hi Frederic,
>
> I understand the scenario now and I agree that a solution is needed. But
> I have two issues, one general and one specific:
>
> - Even though there are no interoperability implications, I think we
> should specify the token format. This will prevent people from making
> some security-critical design mistakes. In other words, we should have
> *one* token generation method.
Since there are no interoperability implications, I thing we should not specify
the format, merely suggest it. Same as we suggest a Cookie format in RFC 5996:
The exact
algorithms and syntax used to generate cookies do not affect
interoperability and hence are not specified here. The following is
an example of how an endpoint could use cookies to implement limited
DoS protection.
Also, if different methods match different scenarios, I don't think we should
have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting *two* methods.
I would not want to implement the method in section 5.2 just because somebody
has some issues with a load balancer.
>
> - The proposed method uses the taker's IP address, making some
> assumptions on the load balancer's behavior. But what if the load
> balancer behaves a bit differently, e.g. by including the source port in
> the decision function? Such a system will still have the vulnerability.
> What if we choose instead to include the *maker* identity (a sequential
> member number, or a private IP, or even a MAC address)? This would
> prevent another member from re-generating the same token for an
> attacker, and as a side benefit, will not require token changes when the
> client is roaming.
Yes, but this will interact badly with clusters. We actually do want two
cluster members to return the same tokens for the same IKE SPIs. If they have
their states synched often, then it's no problem, because they both know which
IKE SAs exist, and which do not. If they don't have their states synched and
they are hot-standby, we also don't have a problem, because a fail-over is like
a reboot (but much faster), and you can't get a response from the non-active
member. The only problem scenario is when you have load sharing and no
synchronized state, and no control over the load balancer (otherwise, I would
tell it to balance by the initiator's IKE SPI). So if one member fails, you
can't get the others to offer valid QCD tokens, and the IKE SAs have to take
the long route to recovery. With the method in 5.2, the other members (which
don't have state) can still create valid QCD tokens, to get all those clients
that connected to the down gateway to begin IKE again.
>
> Thanks,
> Yaron
>
> On 15/10/10 11:53, Frederic Detienne wrote:
>> Hi Yaron,
>>
>> In response to issue 193. For reference:
>>
>> --8<--
>> Section 9.3: this entire discussion is probably redundant, because when a
>> node fails in the LS cluster, you switch to another node. Implementing QCD
>> on top of this is probably an overkill. If we remove this section, we can
>> get rid of sec. 5.2 as well, and we can focus on a single recommended way to
>> generate the token, which would make analysis that much easier.
>> --8<--
>>
>> 9.3 has been moved to 10.4 under security consideration. I will refer to
>> 10.4 instead of 9.3 from now on.
>>
>> The token generation method highlighted in 5.1 presents a security risk
>> highlighted in section 10.4.
>>
>> We can not get rid of 5.2 nor 10.4, however we could make it clearer that
>> 5.2 is the recommended token generation method when the risk highlighted
>> in10.4 is present.
>>
>> Regards,
>>
>> fred
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
