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

yogendra pal <jntupal@gmail.com> Wed, 19 February 2014 10:22 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 CB6E91A0457 for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:22:52 -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 62mPV0hhcioC for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:22:49 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CD2081A03EE for <ipsec@ietf.org>; Wed, 19 Feb 2014 02:22:48 -0800 (PST)
Received: by mail-yk0-f174.google.com with SMTP id 20so456704yks.5 for <ipsec@ietf.org>; Wed, 19 Feb 2014 02:22:45 -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=AkQyVPtAKaEMXwq5nHFMAiIQQClQnMJ0FUuxkUjQgl8=; b=YHxBsZhBmHReimTibulbbZtkh4gYutXO8nzd17YixsXaWGVJ7PqhOdf0w1/7a6yHyL QO7M4IaeZQgIFKCpi7M1q4S8i8F1icUouPtFHdzBXYIn5vSUFOeUDoXzVlWIl0pv6rzN b/5w0S8a/58QroE8YJh5Pa3o/f6a3UWdGbwP8ZaDT/Udsks2qAjl+3ucB05nvETRcWZ2 MXEpl5YRcU7TCyZvr/pQyxVBUdDqhjlNwYK2/2HiVs/9yoWG4LcL9pHjU4YGyRMZFAQY 126WBaKOdzOUtFFVFyA2n+9B6lXJPUiXwthSskSEX90HcAiDdjmfxcyoQ2QSJxTFESc+ bOEA==
MIME-Version: 1.0
X-Received: by 10.236.100.235 with SMTP id z71mr37050824yhf.43.1392805365419; Wed, 19 Feb 2014 02:22:45 -0800 (PST)
Received: by 10.170.189.70 with HTTP; Wed, 19 Feb 2014 02:22:45 -0800 (PST)
In-Reply-To: <CADZyTkkMTo88ccJsyVg_Z55Y=znNiFpbvApNTq_UY93M61g=AQ@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> <CA+dB4X4EHrbF6xXGRUvNWxZdpaNqcO3gYyy-Sc5rNrH1UiWmJQ@mail.gmail.com> <CADZyTkkMTo88ccJsyVg_Z55Y=znNiFpbvApNTq_UY93M61g=AQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 15:52:45 +0530
Message-ID: <CA+dB4X58BSTHb6E0Fecz+bDptYuvXqYaewre3=D-E5tjB=yfLA@mail.gmail.com>
From: yogendra pal <jntupal@gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="20cf301b65fb0c133904f2bfc588"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Tipc_DxNrTtRG5PyTi4uhmV0ZIs
Cc: IPsecme WG <ipsec@ietf.org>, Daniel Palomares <daniel.palomares.ietf@gmail.com>
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 10:22:53 -0000

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.

>>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?
[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 <mglt.ietf@gmail.com> wrote:

> 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 <jntupal@gmail.com> wrote:
> > 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
> >>>>>
> >>>>> 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
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>