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

Daniel Palomares <daniel.palomares.ietf@gmail.com> Mon, 03 March 2014 11:45 UTC

Return-Path: <daniel.palomares.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37B1A000D for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 03:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI81Pj-n-She for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 03:45:45 -0800 (PST)
Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id C6F161A0007 for <ipsec@ietf.org>; Mon, 3 Mar 2014 03:45:44 -0800 (PST)
Received: by mail-ie0-f195.google.com with SMTP id lx4so890904iec.2 for <ipsec@ietf.org>; Mon, 03 Mar 2014 03:45:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZiACgZnll+6o1W/t3Vig7BwsBorVVSaQtbsoCMmu7cg=; b=tECoEtKOW7iNFpyH/9BvZltijS7DHZbrHFu1+1k2TaZwQQPKpJ2Xec7vNKhG36NVx4 sc/3nqVml0b5M+YIRLH1n27CJIc4pnUgXxKItYn64fxe+uLlQGmDrI/BQiAOAwW/Wy7H g3sRx/mdjY9BZN5nZmg1w2SSfic2yzShiADHyHMok4usYM3SGKQnHb+0sTWq+R0tJD+S VksB9evO1Ii6qZS8/YpHoUVSEFntgVuqE50FsKo+4BpmrBtBvfJ16S8saHg3baHBj1ZK 0xl7tpGYR5+jZhjrjmYsMfjm+c7vQy/jj+be4La4umB0gGTAAUkZRP2lWhMs87SN0ZX+ krqA==
MIME-Version: 1.0
X-Received: by 10.42.254.3 with SMTP id nc3mr974026icb.67.1393847141767; Mon, 03 Mar 2014 03:45:41 -0800 (PST)
Received: by 10.50.40.131 with HTTP; Mon, 3 Mar 2014 03:45:41 -0800 (PST)
In-Reply-To: <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com> <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <CAHf5+hpJB6XUWR931vPWGdbsB-UNFa4F0k-5fF=4TG88ADMPSw@mail.gmail.com> <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
Date: Mon, 3 Mar 2014 12:45:41 +0100
Message-ID: <CAHf5+hp9kc4wqWwH3gByZmrYuKrE-y+uW6V+XV=4g1Z6joCT0Q@mail.gmail.com>
From: Daniel Palomares <daniel.palomares.ietf@gmail.com>
To: Valery Smyslov <svanru@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51593e3c19ec904f3b253e5
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eo_9yblQ7j2InaJnjsiHhcbhSQY
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 11:45:48 -0000

Thank you for your comments Valery.

*From:* Daniel Palomares <daniel.palomares.ietf@gmail.com>
> *To:* Valery Smyslov <svanru@gmail.com>
> *Cc:* IPsecme WG <ipsec@ietf.org>
> *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.
>

You are right, and thank you for pointing that out. The window bitmap was
missing. I added in the following version of the draft. Even though I
implemented a testbed, I forgot to add it on the draft.
On the other hand, I have a question concerning the netxt_mid or
next_expected_mid. Are you talking about the message's ID? If yes, they are
added already as part of the IKEv2 parameters as well in version 01. I will
publish it in a few hours.


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

I appreciate your comments concerning the keys SK_* . We actually defined
three additional  flags for each parameter depending on their
relevance/usage: mandatory, optional or vendor specific. However, if you
don't mind, I will also add your comments to the draft as part of the key
management. In fact, when sending all SK_* (using a mandatory flag), then
Nonces, KE, and DH key become optional. But I will clarify this in version
-01 of the draft too.


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

By now, we only wish to agree in the parameters that should be transmitted
concerning the IKEv2 and IPsec contexts. Following steps would be to define
a format  for transferring such data. One could think in JSON format?. I
agree that one should not mandate how applications will implement such
solutions, but in order to reach interoperability between different
constructors, then we need to define this.


Kind Regards,
Daniel PALOMARES,



Regards,
> Valery.
>
>
>
>
>
> Kind Regards,
> Daniel Palomares
>
>
>
>>
>  Regards,
>> Valery Smyslov.
>>
>>
>>  ----- Original Message -----
>> *From:* Daniel Palomares <daniel.palomares.ietf@gmail.com>
>> *To:* ipsec@ietf.org
>> *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:
>> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt<http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt>
>> Status:
>> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/
>> Htmlized:
>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>
>>
>> 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
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>