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

From: Daniel Palomares <[email-masked]>
Date: Thu, 13 Feb 2014 15:09:48 +0100

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

---

From: yogendra pal <[email-masked]>
Date: Mon, 17 Feb 2014 11:20:53 +0530

Hi Daniel,

Quickly went through your draft, have one input for you,
[In section "*5. IPsec Session parameters*"]
 - Consider to have case of IPCOMP also for ipsec session parameters.

BR,
Yogendra Pal
(Ericsson)

On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares <
[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: yogendra pal <[email-masked]>
Date: Tue, 18 Feb 2014 21:55:18 +0530

Hi Daniel,

Given that ike and ipsec can runs on different context and nodes, context
SHOULD capture at least *instance-id* or *flow-id*. This *instance-id* can
help the node to identify which packet processing unit will process this
ipsec traffic or which ipsec instance out of multiple ipsec processing unit
will process this ipsec traffic.

Let me take a simple example case to explain:

On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10} and
out of which ike is using single unit = {1} and ipsec is using 7 processing
unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} for general
purpose.

Each IPsec SA processing can be tied with specific processing unit and can
be called as *instance-id *or *flow-id*. This SA can hold *instance-id
*or *flow-id
*information. Upon sync up of context for each IPsec SA to other node B
upon failure, it can process the same SA on specific *instance-id* or
*flow-id.*

P.S: If your need some text around this, I can provide you a example and
usage of it.

BR,
Yogendra Pal
(Ericsson, India)

---

From: Daniel Palomares <[email-masked]>
Date: Tue, 18 Feb 2014 19:17:11 +0100

Hi Yogendra,

Thank you for your comments and pointing out the lack of the IPComp
parameter.
I will update the draft including the IPComp flag , as well as the IPcomp
algo and the cpi-in/out values.

I understand when you say  the draft "SHOULD capture at least
*instance-id*or *flow-id".
*However, I'm not familiar with this definitions as IKEv2 or IPsec
standards. Please don't hesitate to address me to those documents if they
are actually standardized.

On the other hand, I could understand that those parameters you just
mention (*instance-id* and *flow-id*), might be proprietary solutions to
improve IPsec treatment among several processing units. If it is the case,
I believe that our document may introduce supplementary information in the
context prior some negotiation, but I believe we should let the whole
mailing-list discuss about this.

By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in
order to keep an IKEv2/IPsec session alive.

KR,
Daniel Palomares

2014-02-18 17:25 GMT+01:00 yogendra pal <[email-masked]>:

> SHOULD capture at least *instance-id* or *flow-id*. This *instance-id*can help the node to identify which packet processing unit will process
> this ipsec traffic or which ipsec instance out of multiple ipsec processing
> unit will process this ipsec traffic.
>
> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10}
> and out of which ike is using single unit = {1} and ipsec is using 7
> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10}
> for general purpose.
>
> be called as *instance-id *or *flow-id*. This SA can hold *instance-id *or
> *flow-id *information. Upon sync up of context for each IPsec SA to other
> node B upon failure, it can process the same SA on specific *instance-id*or
> *flow-id.*
>

---

From: yogendra pal <[email-masked]>
Date: Wed, 19 Feb 2014 10:57:40 +0530

Hi Daniel,

I agree w/ what you said, let the ipsec mailing list discussion this out, I
just opened the forum w/ my inputs "*instance-id".  *Since this draft is
towards keeping IKEv2/IPsec session alive when any fault is detected on
current node.

Thanks,
Yogendra Pal
(Ericssson, India)

On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares <
[email-masked]> wrote:

> *instance-id* or *flow-id". *However, I'm not familiar with this
> definitions as IKEv2 or IPsec standards. Please don't hesitate to address
> me to those documents if they are actually standardized.
>
>> Each IPsec SA processing can be tied with specific processing unit and
>> can be called as *instance-id *or *flow-id*. This SA can hold *instance-id
>> *or *flow-id *information. Upon sync up of context for each IPsec SA to
>> other node B upon failure, it can process the same SA on specific
>> *instance-id* or *flow-id.*
>>
>>>> Please find a draft we have Posted. They concern the definition of
>>>> IKEv2 and IPsec contexts.
>>>> Comments are welcome,
>>>>
>>>> BR,
>>>>
>>>> Daniel Palomares
>>>>
>>>>
>>>>
>>>>
>>>>

-- 
Thanks and Regards,
Yogendra Pal
+919686202644

---

From: Daniel Migault <[email-masked]>
Date: Wed, 19 Feb 2014 10:03:29 +0100

Hi,

My understanding is that at the time a format will be defined for
embedding IKEv2 and IPsec context, we should be able to embed also
proprietary parameters similar to vendor-ID with IKEv2. Of course
these parameters will be most probably ignored by other
implementations.

Is there any format you like to see xml, jason, bytes format... ?

What is not clear to me is why a SA on a processing unit X of node A
MUST necessarily be also on processing unit X of node B. I understand
processing unit as a CPU or a specific core. Am I right?

BR,
Daniel

On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal <[email-masked]> wrote:
> just opened the forum w/ my inputs "instance-id".  Since this draft is
> On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares
> <[email-masked]> wrote:
>>
>> Hi Yogendra,
>>
>> I understand when you say  the draft "SHOULD capture at least instance-id
>> or flow-id". However, I'm not familiar with this definitions as IKEv2 or
>> IPsec standards. Please don't hesitate to address me to those documents if
>> they are actually standardized.
>>
>> mention (instance-id and flow-id), might be proprietary solutions to improve
>> IPsec treatment among several processing units. If it is the case, I believe
>> that our document may introduce supplementary information in the context
>> prior some negotiation, but I believe we should let the whole mailing-list
>> discuss about this.
>>
>>> SHOULD capture at least instance-id or flow-id. This instance-id can help
>>> the node to identify which packet processing unit will process this ipsec
>>> traffic or which ipsec instance out of multiple ipsec processing unit will
>>> process this ipsec traffic.
>>>
>>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} for
>>> general purpose.
>>>
>>> can be called as instance-id or flow-id. This SA can hold instance-id or
>>> flow-id information. Upon sync up of context for each IPsec SA to other node
>>> B upon failure, it can process the same SA on specific instance-id or
>>> flow-id.
>>>
>>>> [In section "5. IPsec Session parameters"]
>>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares
>>>> <[email-masked]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
>>>>>
>>>>> Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/
>>>>> Htmlized:
>>>>> Daniel PALOMARES
>>>>> Orange Labs, Issy-les-Moulineaux
>>>>>
>>>>> +33 6 34 23 07 88
>>>>>
>>>>>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: yogendra pal <[email-masked]>
Date: Wed, 19 Feb 2014 15:52:45 +0530

See inline comments

>>Is there any format you like to see xml, jason, bytes format... ?
[Yogendra Pal] instance-id or flow-id will be in bytes, atmost 4 bytes.

>>processing unit as a CPU or a specific core. Am I right?
[Yogendra Pal]
1. From end-user perspective, initiator may NOT know his tunnel
is with A or B (since, operator would have configured A and B with
same tunnel endpoint for redundancy).

2. Given that A and B are supporting redundancy for tunnel. Operator
configure(s)
node A and B as same h/w, however, B can be a low hanging node (asymmetric
h/w).

3. Node A can be a device (e.g router) with multiple blades or linecard and
each linecard doing ipsec processing.
Similarly B also. In general, operator have load balancing/sharing which
will dictates different tunnels
hosted on different linecards and hence the steering logic/load balancing
algorithm. This steering logic resulting
into

*flow-id or instance-id. *
I hope I have answered your query

Thanks,
Yogendra Pal
(Ericsson, India)

On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault <[email-masked]> wrote:

> instance-id
> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
> >>>>>
> >>>>> Status:
> >>>>>    IPsec/IKEv2 clusters are constituted of multiple nodes accessed
> via
> >>>>> a

---

From: yogendra pal <[email-masked]>
Date: Thu, 20 Feb 2014 11:22:48 +0530

Hi Daniel,

Few more queries/input I have.

1. When you say "IKEv2 Session parameters" and "IPsec Session parameters" ,
is it implicit that respective IKEv2 policy and IPsec policy governing
these sessions are also part of these session parameters or they get
explicitly synced between
nodes ?

2. I have NOT seen IKEv2 SA lifetime present in the "IKEv2 Session
parameters" similar to, IPsec SA lifetime present in "IPsec Session
parameters". Is this got missed or will be coming as part of explicit sync
of policy b/w nodes ? If it's implicit then we SHOULD add this into "IKEv2
Session parameters" to support IKEv2 SA rekey.

3. Similar to (2), Is ESN (extended sequence number) support will come in
into "IPsec Session parameters" ?

4. For IPsec SA, if PFS is enabled, does it need to reflect in "IPsec
Session parameters" ?

5. In IKEv2, there is option to support ike-window-size, will this also be
part of "IKEv2 Session parameters" ?

6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will this
be synced as part of IKEv2 Session parameters" ?

6. For IRAS usecase, ip address assignment from tunnel address pool will be
synced separately and will NOT be covered as part of this document or will
it be part of "IKEv2 Sesssion parameters" ?

Thanks,
Yogendra Pal
(Ericsson, India)

On Wed, Feb 19, 2014 at 3:52 PM, yogendra pal <[email-masked]> wrote:

> 3. Node A can be a device (e.g router) with multiple blades or linecard
> and each linecard doing ipsec processing.
> On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault <[email-masked]>wrote:
>
>> Hi,
>>
>> >>>>>    the nodes via specific IP load balancing policies.  Once a
>> session
>> >>>>> is
>> >>>>>    This document describes the contexts for IKEv2 and IPsec that
>> MUST
>> >>>>> be

-- 
Thanks and Regards,
Yogendra Pal
+919686202644

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 21 Feb 2014 15:02:31 +0400

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.

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. 

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. 

Regards,
Valery Smyslov.

  ----- Original Message ----- 
  From: Daniel Palomares 
  To: [email-masked] 
  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

  Revision: 00
  Htmlized: http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00

  Abstract

  Daniel PALOMARES

  +33 6 34 23 07 88

------------------------------------------------------------------------------

---

From: Daniel Palomares <[email-masked]>
Date: Mon, 24 Feb 2014 11:05:13 +0100

Hello Yogendra,

2014-02-20 6:52 GMT+01:00 yogendra pal <[email-masked]>:

> 1. When you say "IKEv2 Session parameters" and "IPsec Session parameters"
> , is it implicit that respective IKEv2 policy and IPsec policy governing

Yes, these parameters are the IKEv2 and IPsec policies governing the
sessions.

> 6. For IRAS usecase, ip address assignment from tunnel address pool will
> be synced separately and will NOT be covered as part of this document or
> will it be part of "IKEv2 Sesssion parameters" ?
>
>
We have included all these parameters explicitly in the following version
01. The IETF Internet-Draft Submission is disabled until 3 march 2014, so
we haven't been able to upload a newer version.
The IKEv2 lifetime, Message IDs, the ike-window-size are part of the IKEv2
session parameters, and the extended sequence numbers support will also be
part of the IPsec session parameters.

>> node A and B as same h/w, however, B can be a low hanging node
>> (asymmetric h/w).
>>

Thanks for the comments,

Regards
Daniel Palomares

---

From: Daniel Palomares <[email-masked]>
Date: Thu, 27 Feb 2014 19:16:50 +0100

Hello Valery,

Thanks for commenting on the draft .

> While no doubt it is helpful, I think that the proper intended status for

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.

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

> 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

 Regards,
> *From:* Daniel Palomares <[email-masked]>
> *To:* [email-masked]
> *Sent:* Thursday, February 13, 2014 6:09 PM
> *Subject:* [IPsec] Draft: IKEv2/IPsec Context Definition
>
>  Hi,
>
> ------------------------------
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 28 Feb 2014 10:30:34 +0400

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, 

  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.

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

  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,

Regards,
Valery.

  Kind Regards,
  Daniel Palomares

    Regards,
    Valery Smyslov.

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

      Hi,

      BR,

      Daniel Palomares

      Revision: 00

      Abstract

      Daniel PALOMARES

      +33 6 34 23 07 88

--------------------------------------------------------------------------