Subject: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt

From: "Peny Yang" <[email-masked]>
Date: Mon, 7 Jul 2008 18:05:20 +0900

Hi, folks:

We have submitted the draft on IKEv2 SA synchronization. Please check it.
Comments are more than welcome.

And, if possible, I would like to apply for a slot to present our work
in the incoming IPsec WG meeting in Dublin.

Thanks a lot
BRG
Peny

> >-----Original Message-----
> >From: [email-masked]
[mailto:[email-masked]]
> >On Behalf Of [email-masked]
> >Sent: Monday, July 07, 2008 4:30 PM
> >To: [email-masked]
> >Subject: I-D Action:draft-xu-ike-sa-sync-00.txt
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >     Title           : IKE SA Synchronization
> >     Author(s)       : Y. Xu, et al.
> >     Filename        : draft-xu-ike-sa-sync-00.txt
> >     Pages           : 17
> >     Date            : 2008-07-07
> >
> >It will take a long time to do security association syncronization
> >among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/
> >IPsec SAs.  The major reason is that the prcocedure of IKEv2 SA re-
> >establishment will incur a time-consuming computation especially in
> >the Diffie-Hellman exchange.  In this draft, a new IKE security
> >associations synchronization solution is proposed to reduce the
> >computation by directly transferring the indexed IKE SA from old
> >gateway to new gateway, wherein the most expensive Diffie-Hellman
> >calculation can be avoided.  Without some time-consuming IKEv2
> >exchanges, the huge amount of IKE/IPsec SA synchronization procedures
> >can be finished in a short time.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Jul 2008 13:31:52 +0300

Hi Peny.

Looks like we have a lot of drafts lately dealing with crash recovery:  
IFARE, QCD, SIR, and now yours (in chronological order).

Specifically, it looks like your proposal is competing with the IFARE  
proposal:
http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt

I've only gave it a cursory read, but if I understand it correctly,  
you propose to follow something like session resumption in TLS, where  
the client detects the failure of the gateway, and begins a new  
IKE_INIT. You add a payload to the IKE_INIT exchange with the IKE  
cookies of the old IKE SA. If the server has a copy, the asymmetric  
operations are not performed, and we get the keys with relatively  
cheap operations.

You may want to post to the list some cons/pros of your proposal vs  
ipsec-failover.

Specific comments about the draft:
  - I think you should add a specific description about how keys are  
derived with a successful stub lookup
  - I think you should remove the text that deals with internal  
structure (and the use of STL). We only need to know what the gateway  
should be able to look up
  - I'm not sure I understand section 3.6.  I understand the format of  
the SYN payload, but I don't get the stub-related signaling.  Are you  
specifying the signaling protocol between the gateways, or is that  
left as a local matter?  Is interoperability between different  
vendor's gateways a goal of this specification?

Thanks

Yoav

On Jul 7, 2008, at 12:05 PM, Peny Yang wrote:

> Scanned by Check Point Total Security Gateway.
> <draft-xu-ike-sa- 
> sync-00.txt>_______________________________________________
> IPsec mailing list
> [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 07 Jul 2008 15:53:58 +0300

Hi Peny,

thanks for your submission. Please note that while session resumption is 
on the ipsecme charter, failover from one gateway to another is 
explicitly outside the charter.

The agenda for Dublin is likely to be busy; we will make an effort to 
accommodate short presentations of IPsec-related drafts, even when they 
don't strictly fall within the charter.

Regards,

    Yaron

---

From: "Peny Yang" <[email-masked]>
Date: Mon, 7 Jul 2008 23:05:46 +0800

Hi, Yoav:

> http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt
[Peny] Well, considering problem of the IPsec failover, some operator
may need a stateful network-centric solution.

> You may want to post to the list some cons/pros of your proposal vs
[Peny] Just as I mentioned above, this solution is about a stateful
network-centric one to solve the problem of IPsec failover. Especially
when we consider the possibility that the IPsec client may be cracked,
our solution can be an useful alternative for operators. It only
incurs a very small extension on the base IKEv2 protocol.
And, I agree that our solution may need to be improved for the cases
when the mobile IPsec client does the IKE SYNC during handover. But,
such kind of cases are quite unusual. We will make the improvement in
the following updates.

>  - I think you should add a specific description about how keys are derived
> with a successful stub lookup
>  - I think you should remove the text that deals with internal structure
> (and the use of STL). We only need to know what the gateway should be able
> to look up
>  - I'm not sure I understand section 3.6.  I understand the format of the
> SYN payload, but I don't get the stub-related signaling.  Are you specifying
> the signaling protocol between the gateways, or is that left as a local
> matter?  Is interoperability between different vendor's gateways a goal of
> this specification?
[Peny] Thank you very much for your comments. We will update our draft
based on your comments within next week.

Thank you again for your help.

BRG
Peny

> <draft-xu-ike-sa-sync-00.txt>_______________________________________________
> > IPsec mailing list
> > [email-masked]

---

From: "Peny Yang" <[email-masked]>
Date: Mon, 7 Jul 2008 23:13:28 +0800

Hi, Yaron:

> thanks for your submission. Please note that while session resumption is on
> the ipsecme charter, failover from one gateway to another is explicitly
> outside the charter.
[Peny] Thanks a lot for your comments. As many people in this list are
interested in this topic and some drafts are posted like "IPsec GW
failover" and my draft, will you please kindly help us to open a
related discussion for IPsec failover?

> don't strictly fall within the charter.
[Peny] Thank you very much for your arrangement. :)

BRG
Peny

> Hi, folks:

We have submitted the draft on IKEv2 SA synchronization. Please
> check it.

And, if possible, I would like to
> apply for a slot to present our work
in the incoming IPsec WG meeting in
> Dublin.

Thanks a lot
BRG
Peny

> On Behalf Of [email-masked]
Sent: Monday, July 07, 2008 4:30
> PM
Subject: I-D
> Action:draft-xu-ike-sa-sync-00.txt

A New Internet-Draft is
> available from the on-line Internet-Drafts
directories.

 Title : IKE SA
> Synchronization
 Filename :
> draft-xu-ike-sa-sync-00.txt
 Pages : 17
 Date : 2008-07-07

It will take a
> long time to do security association syncronization
among IKE/IPsec gateways
> possibly maintaining huge numbers of IKEv2/
IPsec SAs. The major reason is
> that the prcocedure of IKEv2 SA re-
establishment will incur a
> time-consuming computation especially in
the Diffie-Hellman exchange. In
> this draft, a new IKE security
associations synchronization solution is
> proposed to reduce the
computation by directly transferring the indexed IKE
> SA from old
gateway to new gateway, wherein the most expensive
> Diffie-Hellman
calculation can be avoided. Without some time-consuming
> IKEv2
exchanges, the huge amount of IKE/IPsec SA synchronization
> procedures

A URL for this Internet-Draft
> is:

Internet-Drafts
> are also available by anonymous FTP
> at:

Below is the data
> which will enable a MIME compliant mail reader
implementation to
> automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Jul 2008 12:37:25 -0700

<Wearing my co-chair hat>

At 11:13 PM +0800 7/7/08, Peny Yang wrote:
>  As many people in this list are

We cannot start such a WG discussion until one of our other charter 
items is finished. Our charter is completely clear on this topic.

Once we finish one of the items in our charter, the WG can hopefully 
come to consensus about the next item of future work.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 09 Jul 2008 17:51:40 +0300

Hi Peny,

first, let me note that I'm a coauthor of 
draft-sheffer-ipsec-failover-03, which covers similar ground. Also, I am 
making the following comments irrespective of the current group's 
charter. I am commenting on the actual content of the draft, rather than 
its fit with the ipsecme charter.

- The problem you are trying to solve is in my opinion very valid, and 
is described very well in the "scenarios" section.
- "Stub" is not a common name for what you are proposing. Some names I 
can think of are "ticket", "token" or even "blob". There are surely others.
- In general, the document expands too much on implementation issues, 
and too little on the essential protocol issues. To illustrate the first 
point, you mention a very specific implementation of a "map" data 
structure. So specific that it wouldn't apply to Java code.
- Similarly, Sec. 3.4 (although interesting) is very much out of scope. 
Implementers can choose many ways to maintain and distribute the stubs. 
We are mainly interested in the interoperable protocol, i.e. that 
between client and gateway.
- What I am missing is how the stub is acquired by the client, and 
possibly how it is updated. In fact the only example of an IKE exchange 
is that of *using* the stub. In addition, I couldn't find any mention of 
how the stub is protected (encrypted/authenticated) or even that it is 
protected at all.
- It is also unclear to me how the proposed protocol protects against 
replay of the stub, to create multiple IKE SAs and eventually DOS the 
gateway.

Thanks,
    Yaron

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 11 Jul 2008 22:51:08 +0800

Hi, Yaron,

Thanks for your review and comments,
firstly, let me note that I'am a co-author of draft-xu-ike-sa-sync-00, we
planed to reply by Peny only, but he is on the business trip recently, so
please allow me to cut in.
2008/7/9 Yaron Sheffer <[email-masked]>:

>  Hi Peny,
>
> first, let me note that I'm a coauthor of draft-sheffer-ipsec-failover-03,
> which covers similar ground. Also, I am making the following comments
> irrespective of the current group's charter. I am commenting on the actual
> content of the draft, rather than its fit with the ipsecme charter.
>
==> Many thanks, it is the advice.

>
> - The problem you are trying to solve is in my opinion very valid, and is
> described very well in the "scenarios" section.
>
==> Thanks again.

>
> - "Stub" is not a common name for what you are proposing. Some names I can
> think of are "ticket", "token" or even "blob". There are surely others.
>
==> We will consider to replace it based on your suggestion.

>
> - In general, the document expands too much on implementation issues, and
> too little on the essential protocol issues. To illustrate the first point,
> you mention a very specific implementation of a "map" data structure. So
> specific that it wouldn't apply to Java code.
>
==> Ok, we will readjust the content for this part to not exclude the Java
code.

> Implementers can choose many ways to maintain and distribute the stubs. We
> are mainly interested in the interoperable protocol, i.e. that between
> client and gateway.
>
==> Thanks for your suggestion, it should be discarded.

>
> - What I am missing is how the stub is acquired by the client, and possibly
> how it is updated. In fact the only example of an IKE exchange is that of
> *using* the stub. In addition, I couldn't find any mention of how the stub
> is protected (encrypted/authenticated) or even that it is protected at all.
>
==> good catch, we missed the descrition of stub in the client side, will
append
in the next version, it is quite similar to gateway side.

> replay of the stub, to create multiple IKE SAs and eventually DOS the
==> current consideration is that IKE itself has mechanism of against
replay.
or we could add identification field.

>     Yaron

==>many thanks for your discussion.
Best regards,

-Hui

> [mailto:[email-masked] <[email-masked]>]
>
>
> A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>