Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-06.txt

From: [email-masked]
Date: Fri, 06 May 2011 02:15:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : Protocol Support for High Availability of IKEv2/IPsec
	Author(s)       : R. Jenwar, et al.
	Filename        : draft-ietf-ipsecme-ipsecha-protocol-06.txt
	Pages           : 26
	Date            : 2011-05-06

The IPsec protocol suite is widely used for business-critical network
traffic.  In order to make IPsec deployments highly available, more
scalable and failure-resistant, they are often implemented as IPsec
High Availability (HA) clusters.  However there are many issues in
IPsec HA clustering, and in particular in IKEv2 clustering.  An
earlier document, "IPsec Cluster Problem Statement", enumerates the
issues encountered in the IKEv2/IPsec HA cluster environment.  This
document resolves these issues with the least possible change to the
protocol.

This document defines an extension to the IKEv2 protocol to solve the
main issues of "IPsec Cluster Problem Statement" in the commonly
deployed hot-standby cluster, and provides implementation advice for
other issues.  The main issues solved are the synchronization of
IKEv2 Message ID counters, and of IPsec Replay Counters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-06.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.

---

From: Xiangyang zhang <[email-masked]>
Date: Wed, 18 May 2011 23:30:45 +0000

This proposal addresses two major issues in IPsec anti-replay service:
1. Some high end security router can configure thousands of bits for anti-replay window. For example, Juniper can configure up to 4096 bits.  The bit-shifting for this window is a tremendous burden, resulting in the performance drop.
2. High-end network processor could have multiple crypto cores to access the window.  In order to check and update the window, the exclusive lock must be obtained.  

-----Original Message-----
From: Tina Tsou [mailto:[email-masked]]
Sent: Tuesday, May 10, 2011 12:46 PM
To: [email-masked]'
Cc: 'Xiangyang zhang'
Subject: Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

Hi,
Victor and I just submitted
https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/

IPsec anti-replay algorithm without bit-shifting

This document presents a new method to do anti-replay check and 
   update, which becomes one alternative to the anti-replay 
   algorithm in RFC 4302 and RFC4303.  The new method will deem the 
   bit-shifting unnecessary.  It will reduce the number of times 
   to slide the window.  In addition, it makes bit-check and 
   bit-update easier as it does not depend on the low index of the 
   sliding window.  It is especially beneficial when the window size 
   is much bigger than 64 bits, for example, 1024 bits.

   IPsec employs one anti-replay sliding window protocol to secure 
   against an adversary that can insert the messages inside the 
   network tunnel.  This method still inherits the sliding window 
   protocol, but use one or more redundant bytes to ease the update 
   of sliding window.  The bit-shifting is deemed unnecessary with 
   updating the high and low index of the window, which is especially 
   efficient in case of the big window size.  Thus the method reduces
   the number of times to update the window.  

   In addition, the bit location is fixed for one sequence number, 
   thus makes the bit check easier and faster.

Comments are more than welcome.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 May 2011 16:25:46 +0300

Xiangyang zhang writes:
> 1. Some high end security router can configure thousands of bits for
> anti-replay window. For example, Juniper can configure up to 4096
> bits.  The bit-shifting for this window is a tremendous burden,
> resulting in the performance drop. 
> 2. High-end network processor could have multiple crypto cores to
> access the window.  In order to check and update the window, the
> exclusive lock must be obtained.   

If I have understood correctly the algorith listed in the rfc4302 etc
is only for illustrative pseudo-code, the actual implementations may
be different (and at least our implementation do not use bit-shifting
at all as it would be way too inefficient).

The anti-replay checking in the IPsec is local matter to the
implementation and does not have any interoperability requirements in
addition that the sequence number field is always present.

This draft provides nice alternative algorithm to the one provided in
the RFC, but as the algorithm listed in the current rfc is not
mandated anyways and there is no externally visible differences in the
algorithms I do not see reason to document this as RFC.

This would be better as techinal paper about providing faster
algorithm for the anti-replay checking. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 19 May 2011 16:44:34 +0300

I mostly agree with Tero. But I think this would make for a nice
independently-submitted, informational RFC.

Thanks,

Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote:

Xiangyang zhang writes:

---

From: Xiangyang zhang <[email-masked]>
Date: Fri, 20 May 2011 19:17:58 +0000

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Thursday, May 19, 2011 6:26 AM
To: Xiangyang zhang
Cc: Tina Tsou; [email-masked]
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

[xiangyang] Three RFCs describe almost the same algorithm.  
            For illustrative pseudo-code, it shifts bits when the window 
            is updated (Page 41 in RFC4303).  Definitely it is efficient
            if bit-shifting is bypassed.

            In addition, the check and set of the specific bit is also 
            simplified here.  In old method, the location of the bit 
            depends on both the largest sequence number received and 
            the current sequence number.  Instead,
            it only depends on the sequence number currently received.

---

From: Xiangyang zhang <[email-masked]>
Date: Fri, 20 May 2011 20:26:37 +0000

I agree.   Actually our intention is to provide informational RFC.  We do not change the sliding
window protocol for integrity service.  It just provide one alternative, or better alternative
in most cases, to the one specified in IPsec RFCs.

Thanks,

Xiangyang

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; [email-masked]; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

Xiangyang zhang writes:

---

From: Tina Tsou <[email-masked]>
Date: Fri, 20 May 2011 15:55:35 -0700

Yaron, Tero, and Sean,
If Sean could be the sponsor AD, I'm happy to submit it as an independent
submission.

Best Regards,
Tina TSOU
 
From: Xiangyang zhang [mailto:[email-masked]] 
Sent: Friday, May 20, 2011 1:27 PM
To: Yaron Sheffer; Tero Kivinen
Cc: [email-masked]; Tina Tsou
Subject: RE: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting
 
I agree.   Actually our intention is to provide informational RFC.  We do
not change the sliding
window protocol for integrity service.  It just provide one alternative, or
better alternative
in most cases, to the one specified in IPsec RFCs.
 
Thanks,
 
Xiangyang
 
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; [email-masked]; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting

Thanks,
    Yaron