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

[Yaron Sheffer <[e-mail]>]

Hi Hui,

Thank you for your comments. Regarding your second comment, please see http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4

Regards,
	Yaron

> -----Original Message-----
> From: Hui Deng [mailto:[e-mail]]
> Sent: Tuesday, September 22, 2009 17:40
> To: Tero Kivinen
> Cc: Yaron Sheffer; IPsecme WG; [e-mail]; Peny Yang
> Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption
> (IKEv2 Session Resumption) to Proposed Standard
> 
> 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
> 
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

Email secured by Check Point