IETF Logo Mail Archive

Re: [IPsec] Simultaneous Child SA Creation tigger from both the side.

Praveen Sathyanarayan <praveenys@juniper.net> Mon, 05 May 2014 20:54 UTC

Return-Path: <praveenys@juniper.net>
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 94B8D1A0640 for <ipsec@ietfa.amsl.com>; Mon, 5 May 2014 13:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 0fVb3U5IRxN2 for <ipsec@ietfa.amsl.com>; Mon, 5 May 2014 13:54:21 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id DBB231A064A for <ipsec@ietf.org>; Mon, 5 May 2014 13:54:20 -0700 (PDT)
Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 5 May 2014 20:54:16 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0929.001; Mon, 5 May 2014 20:54:16 +0000
From: Praveen Sathyanarayan <praveenys@juniper.net>
To: Paul Wouters <paul@nohats.ca>, Syed Ajim Hussain <syedah@huawei.com>
Thread-Topic: [IPsec] Simultaneous Child SA Creation tigger from both the side.
Thread-Index: AQHPaKQso6QgWQM1tketdY4mgGHdpw==
Date: Mon, 05 May 2014 20:54:15 +0000
Message-ID: <CF8D27E8.5381E%praveenys@juniper.net>
References: <mailman.101.1398884441.30377.ipsec@ietf.org> <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <DE8FB8A9-23C6-4828-9129-2B70542F96ED@gmail.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> <alpine.LFD.2.10.1405050905330.7632@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1405050905330.7632@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [66.129.239.10]
x-forefront-prvs: 0202D21D2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(51704005)(52044002)(164054003)(189002)(199002)(479174003)(377454003)(92566001)(92726001)(15975445006)(20776003)(87936001)(99286001)(77982001)(2656002)(77096999)(83506001)(101416001)(46102001)(36756003)(99396002)(81342001)(85852003)(86362001)(31966008)(4396001)(54356999)(80022001)(74502001)(74662001)(83322001)(83072002)(81542001)(66066001)(76176999)(79102001)(76482001)(19580395003)(19580405001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB666; H:CO2PR05MB665.namprd05.prod.outlook.com; FPR:7ED6F9B1.ACD014C5.F1D23B7A.48E5DFF3.202D6; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7164F07A1E2F48469F6147A63CB42D9D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9ufOjOpp5g2Uvc50tk0aFjLgjVg
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>
Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side.
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, 05 May 2014 20:54:23 -0000

I agree, it is a corner case. Example, out of 5000 tunnels, may be we will
see 10 to 15 tunnels end up in this scenario. So memory/resource is not a
concern. But question is, how do we handle once we are in that state. For
example, which phase1/phase2 SA we should continue to hold (Rekey) and
which one we need drop it, etc.

This is where the confusion comes. Each vendor may end up choosing
different way to handle it and it may cause confusion with other vendor.
If there is a clear description on how to handle (which one to choose and
which one to drop), will help.

Thanks,
Praveen

On 5/5/14, 6:09 AM, "Paul Wouters" <paul@nohats.ca> wrote:

On Mon, 5 May 2014, Syed Ajim Hussain wrote:

>       Thanks for your reply, This problem happened in real scenario,
>problem is-  both the Tunnel end points are different vendor,
>       They handle it differently.
>
>       We can defined this behavior in RFC,
>
>       Also we have some other scenarios, it will be better if we define
>these extreme case behavior also in RFC,
>       to make inter-op smooth.

In libreswan (openswan) the daemon processes one packet at a time, so by
definition one of the child SA's finishes before the other, no matter
how close the timing is. It also has a feature "uniqueids" that would
(dis)allow identical Child SA's, so the latter one establishing replaces
the previous one established.

I'm not convinced your issue is a protocol issue. It seems more like an
implementation issue? If any of your endpoints involved
libreswan/openswan, feel free to contact me.

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email