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

yogendra pal <jntupal@gmail.com> Tue, 18 February 2014 16:25 UTC

Return-Path: <jntupal@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 B31D81A04DC for <ipsec@ietfa.amsl.com>; Tue, 18 Feb 2014 08:25:23 -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 c3YhXY00OBBK for <ipsec@ietfa.amsl.com>; Tue, 18 Feb 2014 08:25:21 -0800 (PST)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5E1A04F1 for <ipsec@ietf.org>; Tue, 18 Feb 2014 08:25:21 -0800 (PST)
Received: by mail-yh0-f48.google.com with SMTP id f10so15701882yha.35 for <ipsec@ietf.org>; Tue, 18 Feb 2014 08:25:18 -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=ghQNUTWxD2tJRGiS4L+92+tQlRggI2Ct/Hpa36fuoxQ=; b=b0ehktsj3qS2NuLOovJPvUTdXhgu161gfchTbJlXfmjmQvkSBkPN7AtXCA3zrH+ha3 uyF76N8/ztiTvwya8Fv3gVtSOwFq+hhB9JLA06y1l2q0h/3ChD8T8QzjvbGz8ll1/mOR WT7enCQ+UZQl3Os7RLyJp9OFBJHIFFniuoTyr3KVbXL8Nld95NAsTQRACGVwXo3VJtAU dpGZOiEsX9UB/PxziLqkiN9UujAyG03fKdxEGAmOYhVS1nXmN3Qog/DrcWqlk9c4o+U/ DqbeYKAnGpEyJlr2VY+TLvK3cJDlVoB9xqEBENntAL5Rgux8Ks5PkYapBvFCF8HMfY9+ 5juQ==
MIME-Version: 1.0
X-Received: by 10.236.100.235 with SMTP id z71mr30933288yhf.43.1392740718135; Tue, 18 Feb 2014 08:25:18 -0800 (PST)
Received: by 10.170.189.70 with HTTP; Tue, 18 Feb 2014 08:25:18 -0800 (PST)
In-Reply-To: <CA+dB4X4iRjk9hH3wyX8Qj93Kd77BnvGpsm=FK3OHho=S-+Ngiw@mail.gmail.com>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com> <CA+dB4X4iRjk9hH3wyX8Qj93Kd77BnvGpsm=FK3OHho=S-+Ngiw@mail.gmail.com>
Date: Tue, 18 Feb 2014 21:55:18 +0530
Message-ID: <CA+dB4X7Q0BgOhZ_FKKp6eYA7jhZn=CsqEZ6Mit4EruHPojt5aw@mail.gmail.com>
From: yogendra pal <jntupal@gmail.com>
To: Daniel Palomares <daniel.palomares.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=20cf301b65fbc4cdfe04f2b0b744
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/60M6odGlcprHk2gLFxUCUuvu2WA
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: Tue, 18 Feb 2014 16:25:23 -0000

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)


On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntupal@gmail.com> wrote:

> 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 <
> daniel.palomares.ietf@gmail.com> wrote:
>
>> 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
>>
>>
>
>
>
>