Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard

[Hui Deng <[e-mail]>]

Comments inline, thanks

2009/9/3 Tero Kivinen <[e-mail]>:
> Yaron Sheffer writes:
>> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in
>> fact an early version of our work did exactly that. But the working group
>> gave us a clear direction to use a separate exchange, and this is where we
>> disagree: I believe we did have a strong WG consensus that the
>> implementation benefits of having a separate exchange (i.e. not overloading
>> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the
>> alternative.
>
> I agree on that (both to the WG having consensus and also that using
> separate exchange is better).
[Hui] I don't think so. IMO, in the list, the comparison of extended
IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus yet.
It was a ballot in the mailing list in the begining, and it is quite
clear more people opposing
sepaparate exchange, we could do one more round ballot if needed.

>
>> > I know that how a client detects the need for resumption is out of the
>> > scope of this draft. But, there is the possibility that IPsec client
>> > may be continuously deceived and believe the fail of IPsec gateway. It
>> > may continuously present the ticket and update the ticket. In this
>> > sense, IMHO, this draft should take care of this case.
>> >
>> [YS] If I understand the scenario correctly, it is similar to an attacker
>> repeatedly sending notifications to an IKE client, making it believe that
>> the IKE exchange has failed and needs to be reinitiated. This attack against
>> plain-vanilla IKE would be much more CPU-intensive to the client and to the
>> (real) gateway, compared to repeated session resumption. Even when you
>> factor in the cost of generating a new ticket. Moreover, the regular IKEv2
>> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well.
>
> Regardless what notifications or ICMP messages you send to any of the
> IKE end points that MUST NOT cause them to consider IKE SA failed. It
> "MUST conclude that the other endpoind has failed only when repeated
> attemtps to contact it have gone unanswered for timeout period or when
> a cryptographically protected INITIAL_CONTACT notification is received
> on a different IKE SA to the same authenticated identity." (RFC 4306
> section 2.4)
>
> Notifications and ICMP messages may trigger other end to send empty
> INFORMATIONAL message to check whether the other end is alive or not
> and only if that times out then the other end is considered dead.
>
> This means this kind of attack is not possible with notifications and
> ICMP.
>
> On the other hand I do agree with Peny that, as resumption draft makes
> it out of scope for this draft, how a client detects the need of
> resumption, we might need more text explaining this attack. I.e. we
> might need to add text to security considerations which says that the
> client implementations should not trust any untrusted source when they
> are trying to detect whether the resumption is needed.

[Hui] I also agree with Peny and Tero. Although way of detecting
failure of gateways is out of the scope of current charter, WG draft
should at least handle the issues incurred by mis-judgement of client.

thanks

-Hui