ietf
[Top] [All Lists]

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

2009-09-02 17:18:46
Hi Peny,

Thank you for reviewing this draft. Please see my comments below.

Regards,
        Yaron

-----Original Message-----
From: ipsec-bounces(_at_)ietf(_dot_)org 
[mailto:ipsec-bounces(_at_)ietf(_dot_)org] On Behalf Of
Peny Yang
Sent: Wednesday, September 02, 2009 17:18
To: ietf(_at_)ietf(_dot_)org
Cc: IPsecme WG
Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption
(IKEv2 Session Resumption) to Proposed Standard

Sorry, I should cc IPsec mail list. Comments are sent again.

Hi, floks:

I have two comments on the draft of IKEv2 Session Resumption:

1) Sorry, I have to talk about my concern on the new
IKE_SESSION_RESUME. In WG last call, actually I made this comment.
However, no feedback was given, maybe because my comment was a little
late for WG last call. So, I just copy it here again as a comment for
IESG last call.

Well,  we've discussed pros and cons of IKE_SA_INIT and
IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus
is still not fully achieved on this item. So far, I still prefer to
choosing extended IKE_SA_INIT for ticket presenting. This solution is
specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01

As a summary, the virtues are as follows:
- RFC5077 (TLS session resumption) also uses the similar scheme, which
extends the message of clienthello with session ticket extension. The
extended IKE_SA_INIT solution has the similar way. It's easy to extend
the base IKEv2 protocol stack to support session resumption.
- Considering the case of failing session resumption, the extended
IKE_SA_INIT solution can save one round trip.
- As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated
after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way
need less code to be supported compared with IKE_SESSION_RESUME.

The down side:
- some people thought the way of extended IKE_SA_INIT will make the
base IKEv2 protocol stack more complex. IMHO, it's an issue of
implementation.
Again, I still support to use extended IKE_SA_INIT for ticket
presenting instead of IKE_SESSION_RESUME.

[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.

2) Maybe I missed some discussions.
There is the case: responder may receives a ticket for an IKE SA that
is still active and if the responder accepts it. In one of previous
versions of this draft, there once was some description on this case.

[YS] I believe you are referring to the text now in Sec. 4.3.4.

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.

BRG
Peny

On Mon, Aug 31, 2009 at 10:09 PM, The 
IESG<iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:

- 'IKEv2 Session Resumption '
  <draft-ietf-ipsecme-ikev2-resumption-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2009-09-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, 
please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-
07.txt


IESG discussion can be tracked via

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17
990&rfc_flag=0

_______________________________________________
IPsec mailing list
IPsec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf