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

yogendra pal <jntupal@gmail.com> Wed, 19 February 2014 05:27 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 610091A0443 for <ipsec@ietfa.amsl.com>; Tue, 18 Feb 2014 21:27:47 -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 bZ3x9DqLUhDJ for <ipsec@ietfa.amsl.com>; Tue, 18 Feb 2014 21:27:44 -0800 (PST)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1115D1A043E for <ipsec@ietf.org>; Tue, 18 Feb 2014 21:27:43 -0800 (PST)
Received: by mail-yk0-f172.google.com with SMTP id 200so36089064ykr.3 for <ipsec@ietf.org>; Tue, 18 Feb 2014 21:27:40 -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=a0S+oa5LrIEKELfO7mkY4u6w38/dacdZ093A0mNrQ3Q=; b=UncX91wtuw5SlHNEbyWoNHvZXCp+PNtHg3dytsc7CoVr7zJEa4JLxihvsAmgW0xTjw SI6Z0LwzV2Xlj9PSAnCDt4ArumSOG6BaTNRlfqo/c1sZfHCSixmc4HP3hjF+GHCbzJWy DIz7KKQuSYwadSmJNRRgBLEjABaGnKE7AtE972SKoVHcIMCxphMu8sk6aaQeUKq+pfxN a3oLX/j7w7ZmIn8c3hbS3d56Jv3rB9fEB3RtK4s6j85mc94pf0nTOPj5gmx69LYsC4En jkWLxADvbDdDlTPj+k14F98CY32N2NhPJ5+9LMsOhscDn4CP6SrqJon7lvz6CXSRQMZ/ RRew==
MIME-Version: 1.0
X-Received: by 10.236.100.235 with SMTP id z71mr35106333yhf.43.1392787660682; Tue, 18 Feb 2014 21:27:40 -0800 (PST)
Received: by 10.170.189.70 with HTTP; Tue, 18 Feb 2014 21:27:40 -0800 (PST)
In-Reply-To: <CAHf5+hqQ--k6DQsK9ChW6D18wpY6i4gUgN_dGoTR4CvexwGq-Q@mail.gmail.com>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com> <CA+dB4X4iRjk9hH3wyX8Qj93Kd77BnvGpsm=FK3OHho=S-+Ngiw@mail.gmail.com> <CA+dB4X7Q0BgOhZ_FKKp6eYA7jhZn=CsqEZ6Mit4EruHPojt5aw@mail.gmail.com> <CAHf5+hqQ--k6DQsK9ChW6D18wpY6i4gUgN_dGoTR4CvexwGq-Q@mail.gmail.com>
Date: Wed, 19 Feb 2014 10:57:40 +0530
Message-ID: <CA+dB4X4EHrbF6xXGRUvNWxZdpaNqcO3gYyy-Sc5rNrH1UiWmJQ@mail.gmail.com>
From: yogendra pal <jntupal@gmail.com>
To: Daniel Palomares <daniel.palomares.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="20cf301b65fbc33c7d04f2bba54c"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/but58SNIMTbusQdHRkT-P8MHD4I
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: Wed, 19 Feb 2014 05:27:47 -0000

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

> 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 <jntupal@gmail.com>:
>
> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>


-- 
Thanks and Regards,
Yogendra Pal
+919686202644