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

Daniel Palomares <> Thu, 27 February 2014 18:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C9A71A015A for <>; Thu, 27 Feb 2014 10:16:57 -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 J6R9Kuvdw44A for <>; Thu, 27 Feb 2014 10:16:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::244]) by (Postfix) with ESMTP id 7B1351A036E for <>; Thu, 27 Feb 2014 10:16:52 -0800 (PST)
Received: by with SMTP id rd18so236055iec.11 for <>; Thu, 27 Feb 2014 10:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1nMO/WzOyEbk3mmEESE5XtzOQd5NgTHZdwGwI6oboHI=; b=mIjNMRdik8Dtmc+DTblA6arQ4/RquxKfajl4gxgA0pirf4tvPOoKH2xqz5y168abN3 t+uWhmUVzWTW2sG8aDfxbMLxIpyo+89fKsTGV6NpvojPP7m+IM+CWef1rzIIKeYgQN6n 5W4Yz5IPzuhggoXJEg4QxlDTcSx65sAkTtsHuqSVw8hcEen9U8WjdrmD7QA68R/l+HsN S9RmBlcBIr0rg5EBM5Lv1l1VxeSkIBQ7LI3EUISr9J5HJsG99ykmdp6p486w5Gi5FiO2 Sqk+td30hlIOjIZBIDylgY3VPsITjxTtEhdIlWt/Ch9bX30S9gNCjmk0H1h9JUcbJGE9 ZvVw==
MIME-Version: 1.0
X-Received: by with SMTP id wi19mr7020865icb.53.1393525010847; Thu, 27 Feb 2014 10:16:50 -0800 (PST)
Received: by with HTTP; Thu, 27 Feb 2014 10:16:50 -0800 (PST)
In-Reply-To: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc>
References: <> <7A4D82FA3EF546E499D0A0CD18C58153@buildpc>
Date: Thu, 27 Feb 2014 19:16:50 +0100
Message-ID: <>
From: Daniel Palomares <>
To: Valery Smyslov <>
Content-Type: multipart/alternative; boundary=bcaec51f966341ddc204f367539b
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: Thu, 27 Feb 2014 18:16:57 -0000

Hello Valery,

Thanks for commenting on the draft .

2014-02-21 12:02 GMT+01:00 Valery Smyslov <>om>:

>  Hi,
> I have some comments regarding the draft.
> First, I'm a bit puzzled by intended status of the draft: Standards Track.
> From my understanding this means, that the document defines some protocol,
> that needs to be standardized to get interoperability. But the draft
> defines
> no protocol, it just speculates on what contents of IKE/IPsec SA must
> contain.
> While no doubt it is helpful, I think that the proper intended status for
> the draft
> is Informational.

You are right, the draft is intended to be INFORMATIONAL. This is already
changed in version -01, but will be uploaded later as this draft tool is
disable until 3th march.

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

> 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)?

Kind Regards,
Daniel Palomares

> Valery Smyslov.
> ----- Original Message -----
> *From:* Daniel Palomares <>
> *To:*
> *Sent:* Thursday, February 13, 2014 6:09 PM
> *Subject:* [IPsec] Draft: IKEv2/IPsec Context Definition
>  Hi,
> Please find a draft we have Posted. They concern the definition of IKEv2
> and IPsec contexts.
> Comments are welcome,
> BR,
> 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
> URL:
> Status:
> Htmlized:
> Abstract
>    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
>    user.
> *Daniel* *PALOMARES*
> *Orange Labs, Issy-les-Moulineaux*
> +33 6 34 23 07 88
> ------------------------------
> _______________________________________________
> IPsec mailing list