headers
Lydia Xu(yixian | 6 Jul 2011 08:56
Favicon

A new draft submittted-draft-xu-tictoc-ipsec-security-for-synchronization-01

Hi all,

 

I have submitted a new Draft in TICTOC. This document is a WESP extension. And this mechanism canbe used to resove the time synchronization with IPsec encryption.

 

This document is available at the following URL:

http://tools.ietf.org/id/draft-xu-tictoc-ipsec-security-for-synchronization-01.txt

 

The document is still undergoing revision, any comments are welcome. 

 

Best Regards

                  

                    Yours sincerely,

                    Lydia Xu(许怡娴)


HUAWEI TECHNOLOGIES CO.,LTD.

 

 

Address: Huawei Building
Beijing 100085, P.R.China
Tel: +86 10 82836300
Fax: +86 10 82836920
Mobile: +86 13426219317
E-mail: xuyixian <at> huawei.com
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it.

 

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Tero Kivinen | 22 Jul 2011 01:53
Picon
Picon
Favicon

Raw ECDSA keys and IKEv2

In the RFC5996 we have format for Raw RSA keys (using PKCS1 format).
The current buzzword compatible mantra seems to be ECDSA or Elliptic
Curve keys in general, so perhaps we should also allow Raw ECDSA keys
to be used in the IKEv2?

For the format we could either use one of the following:

1) RFC5480
2) Draft-hoffman-dnssec-ecdsa-04
3) Roll our own
4) Combination of few above

The RFC5480 has the problem that it uses ASN.1, and many of the people
want to use Raw Public Keys just because they do not want to use Self
signed certificates because of ASN.1 requirement.

Draft-hoffman-dnssec-ecdsa-04 uses DNSSec registries, do we want to
reuse them?

The case 4 would most likely be best, meaning we create own wrapper
format where we have the curve information using our own registry (or
reuse IKEv2 Authentication Method registry, as the key to be used will
be used to create the Authentication Payload anyways), and then attach
to that either the format from draft-hoffman-dnssec-ecdsa-04 section
4, or from RFC 5480 section 2.2.
--

-- 
kivinen <at> iki.fi
Permalink | Reply | 0 comments |
headers
B Rampullaiah-B22344 | 22 Jul 2011 14:05
Favicon

Need Info related to simultaneous rekey of IKE/IPSec SAs.

Hi,

 

I need some information for the simulation of the following cases related to IKEV2 Exchange Collision Mechanism Implementation as per the RFC-4718.

 

1. When the host receives a request to rekey - a CHILD_SA pair that the host is currently rekeying:

Reply as usual, but prepare to close redundant SAs later based on the nonces.

 

2. When the host receives a request to rekey - the IKE_SA, and the host is currently rekeying the IKE_SA:

Reply as usual, but prepare to close redundant SAs and move inherited CHILD_SAs later based on the nonces.

 

3. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA:

      Reply with NO_ADDITIONAL_SAS.

 

How to simulate the simultaneous rekeying of IKE/IPSec SAs?

 

Regds,

Ramu.

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 1 comment |
headers
pramod.s.pawar | 22 Jul 2011 16:22
Favicon

SecureComm2011 - Call for Posters

 

SECURECOMM 2011

CALL FOR POSTERS

Seventh International Conference on Network Security & Privacy (SecureComm 2011)
London, United Kingdom
Sept 7-9, 2011

WWW: http://www.securecomm.org

Deadline for submissions: 3rd August 2011

Notification of Acceptance: 10th August 2011

The poster session will provide a forum for researchers to show their work and obtain constructive feedback on ongoing research from knowledgeable conference attendees. Areas of technical interest are the same as those listed in the technical call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available.

At least one of the authors of the poster must register for the conference for the poster to be included as part of the poster session.

 

SUBMISSION INSTRUCTIONS

Each submission should also include an abstract of up to 250 words summarizing the research work and 2 A4 pages detailing the scientific merit of the research work.

Both the abstract and the poster must have the title, authors, institutional affiliations and contact information.

Please submit your poster to the Conference General Chair Dr Muttukrishnan Rajarajan Email: r.muttukrishnan <at> city.ac.uk , in PDF format.

 

PRESENTATION OF POSTERS

Authors of accepted poster proposals will have a chance to present the poster to interested attendees during a special poster session at the conference.  Well-crafted posters will tell the story well by themselves, but authors of posters are expected to be available to describe and discuss the work in the poster during the session.

 
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Kalyani Garigipati (kagarigi | 25 Jul 2011 07:59
Picon
Favicon

Re: Need Info related to simultaneous rekey of IKE/IPSec SAs.

Hi Ramu,

 

You can have a middle router between two ike peers.

1.       Establish the ike and ipsec sa

2.       Make one of the interfaces on middle router as down.

3.       Then ensure ike/ipsec rekey happens simultaneously on both the routers. Since the middle router is down, the packets are don’t reach peer, but are retransmitted.

4.       Now make the interface up. The ike /ipsec rekey packets cross each other. And simulatenous rekey happens.

 

Regards,

Kalyani

       

 

 

From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of B Rampullaiah-B22344
Sent: Friday, July 22, 2011 5:35 PM
To: ipsec <at> ietfa.amsl.com
Subject: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs.

 

Hi,

 

I need some information for the simulation of the following cases related to IKEV2 Exchange Collision Mechanism Implementation as per the RFC-4718.

 

1. When the host receives a request to rekey - a CHILD_SA pair that the host is currently rekeying:

Reply as usual, but prepare to close redundant SAs later based on the nonces.

 

2. When the host receives a request to rekey - the IKE_SA, and the host is currently rekeying the IKE_SA:

Reply as usual, but prepare to close redundant SAs and move inherited CHILD_SAs later based on the nonces.

 

3. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA:

      Reply with NO_ADDITIONAL_SAS.

 

How to simulate the simultaneous rekeying of IKE/IPSec SAs?

 

Regds,

Ramu.

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Tero Kivinen | 25 Jul 2011 15:46
Picon
Picon
Favicon

New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt

Picon Favicon
From: gmane.ietf.ipsec <internet-drafts <at> ietf.org>
Subject: New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt
Date: 2011-07-25 13:29:50 GMT
A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-01.txt has been successfully
submitted by Tero Kivinen and posted to the IETF repository.

Filename:	 draft-kivinen-ipsecme-secure-password-framework
Revision:	 01
Title:		 Secure Password Framework for IKEv2
Creation date:	 2011-07-25
WG ID:		 Individual Submission
Number of pages: 14

Abstract:
   This document creates a generic way for Internet Key Exchange (IKEv2)
   to use any of the symmetric secure password authentication methods.
   There are multiple methods already specified in other documents and
   this document does not add new one.  This document specifies a common
   way so those methods can agree on which method is to be used in
   current connection.  This document also provides a common way to
   transmit secure password authentication method specific payloads
   between peers.

The IETF Secretariat

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 28 comments |
headers
Prashant Batra (prbatra | 26 Jul 2011 05:29
Picon
Favicon

DH keys calculation performance

Hello,

The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange 
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?

Regards,
Prashant
Permalink | Reply | 26 comments |
headers
Vishwas Manral | 26 Jul 2011 06:37
Picon

Re: DH keys calculation performance

Hi Prashant,
 
Back in the days we had some acceleration of DH in the hardware http://www.wipo.int/patentscope/search/en/WO2005008999.
 
Other things you can do is put in more CPU or use a lower DH group.
 
Thanks,
Vishwas

On Mon, Jul 25, 2011 at 8:29 PM, Prashant Batra (prbatra) <prbatra <at> cisco.com> wrote:
Hello,

The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?


Regards,
Prashant
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Yoav Nir | 26 Jul 2011 12:40
Picon
Favicon

Re: DH keys calculation performance


On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:

> Hello,
> 
> The DH exchange (Calculation of Public/Private key and the Secret) in
> IKEV2 Initial exchange 
> seems to be very expensive. This is slowing down the overall IKEv2
> tunnel establishment.
> Is there a way to optimize it?

Hi Prashant.

I know of three ways to optimize the D-H exchange.

First, note that each peer has to perform two operations: 
 1. Generate: create a random x and calculate X=2^x mod p
 2. Derive: calculate the shared secret S=Y^x mod p
The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long
before the exchange. If your problem is degraded performance at some peak, you can pre-generate some
values. This has a high cost in memory, but can be useful for dealing with peaks.

Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p
If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=x<=2048 and store these values.
After that, both the generate and derive operations become simple multiplications of the resulting
values. This has a fixed cost in memory, but can accelerate things.

Third, you may want to look at the EC groups. The EC operations require less computation.

Hope this helps

Yoav
Attachment (smime.p7s): application/pkcs7-signature, 4883 bytes
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 24 comments |
headers
Yaron Sheffer | 26 Jul 2011 13:17
Picon

Re: DH keys calculation performance

You might want to review http://tools.ietf.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces the computational costs of renewing an IKE SA when a client needs to reconnect to a gateway a second time after some failure.

Thanks,
    Yaron

On 07/26/2011 01:40 PM, Yoav Nir wrote:
On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:
Hello, The DH exchange (Calculation of Public/Private key and the Secret) in IKEV2 Initial exchange seems to be very expensive. This is slowing down the overall IKEv2 tunnel establishment. Is there a way to optimize it?
Hi Prashant. I know of three ways to optimize the D-H exchange. First, note that each peer has to perform two operations: 1. Generate: create a random x and calculate X=2^x mod p 2. Derive: calculate the shared secret S=Y^x mod p The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long before the exchange. If your problem is degraded performance at some peak, you can pre-generate some values. This has a high cost in memory, but can be useful for dealing with peaks. Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=x<=2048 and store these values. After that, both the generate and derive operations become simple multiplications of the resulting values. This has a fixed cost in memory, but can accelerate things. Third, you may want to look at the EC groups. The EC operations require less computation. Hope this helps Yoav

_______________________________________________ IPsec mailing list IPsec <at> ietf.org https://www.ietf.org/mailman/listinfo/ipsec 
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 21 comments |

Gmane