Re: [IPsec] Draft: IKEv2/IPsec Context Definition

"Valery Smyslov" <> Fri, 28 February 2014 06:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EEB601A03FF for <>; Thu, 27 Feb 2014 22:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fstKXSOmzMbb for <>; Thu, 27 Feb 2014 22:30:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) by (Postfix) with ESMTP id 674A91A02D3 for <>; Thu, 27 Feb 2014 22:30:40 -0800 (PST)
Received: by with SMTP id z11so2349203lbi.8 for <>; Thu, 27 Feb 2014 22:30:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=mJUMdH3Oz5XIIDrVFUzuTfFklqQcWOJQYj0y5WZbw7Q=; b=yali2XXSxjF5sb2cajLUdDVDKwIVMh4Wz5pi+UR0EfatsdXNSPM385lOszuDLS6l9M GFhDpSXtPXgInL7fMBuSE4eZEPOp0CHa2C8mQg7D9pmxz/5WiFPYPjno8SD/KlIdo16U Z3GnDFiYgfnXuwQuH3Q9Y4pibIuohAQqWDBdCd/lsPK/a9pKC/e0Dsbsh8/PCCgc5TrW J4gbea2Xq01+RCDFZyeh34ZPzE45bYCyPe5cv/H8k/AEnqtwEgwATs/3cJPL2TrYqXpD bWa2+3r13wZ7D+t5ty+GnvJEZ36+rFSvNsm/gjmb43M/a211f2735m84G1LFs9t1xX2C VQzQ==
X-Received: by with SMTP id be18mr9862492lab.3.1393569037833; Thu, 27 Feb 2014 22:30:37 -0800 (PST)
Received: from buildpc ([]) by with ESMTPSA id gb8sm2538734lbc.13.2014. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Feb 2014 22:30:36 -0800 (PST)
Message-ID: <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
From: "Valery Smyslov" <>
To: "Daniel Palomares" <>
References: <><7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <>
Date: Fri, 28 Feb 2014 10:30:34 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0993_01CF3470.1D4CFD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: IPsecme WG <>
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Feb 2014 06:30:45 -0000

Hi Daniel,
  ----- Original Message ----- 
  From: Daniel Palomares 
  To: Valery Smyslov 
  Cc: IPsecme WG 
  Sent: Thursday, February 27, 2014 10:16 PM
  Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition

  Hello Valery, 

  Thanks for commenting on the draft .

    Then, I've been always thinking that the content of the IKE/IPsec SA is 
    an implementation issue. The draft tries to mandate this content,
    but it lacks plenty of absolutely needed information (this is especially true
    for IKE SA), like MID counters, window bitmaps, lifetimes, credential information,
    VIDs, features, statistics and so on. 

  Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some information was missing, but they actually appear in the structure example on the Appendix. These parameters, together with those pointed out by Yogendra in previous comments, are explicitly added in their corresponding sections. 
Sorry, I still couldn't find in IKEV2CONTEXT structure neither next_mid, 
nor next_expected_mid, nor window_bitmap etc. All this parameters
are mandatory for IKEv2 to work properly.

  On the other hand, the draft tries to mandate one way of presenting some data, 
    ignoring the fact that it is not the only (and probably not the best) way. For example,
    instead of transferring nonces and DH secret to the other node one may 
    transfer computed SK_* keys. This approach may have some advantages both 
    from security and performance perspectives.

  We actually think sending keys is one quick way to build an IKE_SA/IPsec_SA.  As I said before, all the keys SK_* were included in the Appendix but are missing within the lists in sections 4 and 5. They are added in the following version of the draft -01.

  We also included three different level of parameters in order to classify their relevance: Mandatory, Optional or Vendor Specific. 

  Note that the draft does not intend to define the format for transferring the parameters/contexts. The draft actually identifies each parameter that MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify the relevance of the parameter, it can be defined as Mandatory (M), Optional (O) or Vendor Specific (V).

  I have one question concerning about comment concerning the keys (SK_*), : 

  A node can send all the keys (SK_*) to avoid their recalculation in the other node, ignoring the Nonces and DH secret. However,  ignoring Nonces might lead to the impossibility of REKYING crypto material. Please correct me if I'm wrong. So my question is: 
  Are you proposing to add all SK_* together with the Nonce and DH information? Or, do you think that sending all keys might be enough (ignoring Ni, Nr and DH-related information)?
Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED,
SK_*, keymat for Child SA and AUTH payload content.Anyway, once the exchange
is complete, the nonces, appeared in this exchange, may be discarded.

Actually, you have 3 choices to exchange IKEv2 keying information between nodes in cluster:
1. Send your private DH key, peer's KE content and nonces. In this case
    other nodes will recalculate all keys from the very beginning.
2. Send SKEYSEED and nonces.
3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, as these
    keys are used only during authentication (unless you implement Session Resumption,
    but it also depends on how you store the tickets - by value or by reference).

All approaches are equally possible. There seems to be some
security and performance benefists for approach 3, but somebody
may argue. Implementation may use any of this approaches
and I don't think it's good to mandate the only approach,


  Kind Regards,
  Daniel Palomares

    Valery Smyslov.

      ----- Original Message ----- 
      From: Daniel Palomares 
      Sent: Thursday, February 13, 2014 6:09 PM
      Subject: [IPsec] Draft: IKEv2/IPsec Context Definition


      Please find a draft we have Posted. They concern the definition of IKEv2 and IPsec contexts. 
      Comments are welcome,


      Daniel Palomares

      Name:        draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

      Revision: 00
      Title:       IKEv2/IPsec Context Definition
      Document date:    2014-02-12
      Group:        Individual Submission
      Pages:        8


         IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a
         single address by the end user.  The traffic is then split between
         the nodes via specific IP load balancing policies.  Once a session is
         assigned to a given node, IPsec makes it difficult to assign the
         session to another node.  This makes management operations and
         transparent high availability for end users difficult to perform
         within the cluster.

         This document describes the contexts for IKEv2 and IPsec that MUST be
         transferred between two nodes so a session can be restored.  This
         makes possible to transfer an IPsec session transparently to the end

      Daniel PALOMARES

      Orange Labs, Issy-les-Moulineaux

      +33 6 34 23 07 88


      IPsec mailing list