Re: [I2nsf] [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es> Mon, 01 April 2019 22:05 UTC

Return-Path: <fernando.pereniguez@cud.upct.es>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83BA120047; Mon, 1 Apr 2019 15:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 4JpAryz1Wgw8; Mon, 1 Apr 2019 15:05:14 -0700 (PDT)
Received: from mx01.puc.rediris.es (outbound1mad.lav.puc.rediris.es [130.206.19.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F5120021; Mon, 1 Apr 2019 15:05:12 -0700 (PDT)
Received: from relay2.si.upct.es (mail.upct.es [212.128.20.254]) by mx01.puc.rediris.es with ESMTP id x31M58Uo029778-x31M58Uq029778 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 2 Apr 2019 00:05:08 +0200
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay2.si.upct.es (Postfix) with ESMTPSA id ED361472F9; Tue, 2 Apr 2019 00:05:02 +0200 (CEST)
Received: by mail-io1-f50.google.com with SMTP id b6so9204163iog.0; Mon, 01 Apr 2019 15:05:02 -0700 (PDT)
X-Gm-Message-State: APjAAAWvCG0u4AJiqYZx4zQGL2J8ZJNupTgQW/U0rTHJ4yHQkHYYTeMc VWoRL39YBNLRE1CDxC1bj9ykAv3AD9KUTP0KcYc=
X-Google-Smtp-Source: APXvYqxQVk64kR2skfHhG5v18fbaGcqRCErls94F80FJtOEc9cjsnAYkvFfZhIuuo8GoyGsYOBtdDad0o0Qs86YcKBk=
X-Received: by 2002:a6b:3c05:: with SMTP id k5mr15330595iob.270.1554156291489; Mon, 01 Apr 2019 15:04:51 -0700 (PDT)
MIME-Version: 1.0
References: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@sjceml521-mbs.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@sjceml521-mbs.china.huawei.com>
From: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= <fernando.pereniguez@cud.upct.es>
Date: Tue, 2 Apr 2019 00:04:41 +0200
X-Gmail-Original-Message-ID: <CAB=gXc6aZ2D1K_q3MjVJMEYxEykJO_oxhoSkOEyytOOaa=_ouA@mail.gmail.com>
Message-ID: <CAB=gXc6aZ2D1K_q3MjVJMEYxEykJO_oxhoSkOEyytOOaa=_ouA@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: idr wg <idr@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Yoav Nir <ynir.ietf@gmail.com>, Roman Danyliw <rdd@cert.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Paul Wouters <paul@nohats.ca>, Rafa Marin Lopez <rafa@um.es>, =?UTF-8?Q?Gabriel_L=C3=B3pez_Mill=C3=A1n?= <gabilm@um.es>
Content-Type: multipart/alternative; boundary="000000000000ae085e05857f3575"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/Ftgo1RnPTBZWMr0k1LlO3ae-zx8>
Subject: Re: [I2nsf] [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 22:05:18 -0000

Hi Linda,

We have revised draft-hujun-idr-bgp-ipsec and, to the best of our
understanding, we do not see any conflict with our draft being discussed in
I2NSF. The IPsec attributes configured through BGP are only the peer’s
tunnel address and local/remote subnet prefixes (that are used for the
traffic selectors).  The rest of the IPsec configuration (AH/ESP,
cryptographic algorithms, keys, etc.) are obtained via a “color mapping”,
which is something not covered by the draft since it assumes routers are
somehow pre-provisioned with this information.

Thus, we do not see this draft is also facing the task of formalizing the
complete configuration of an IPsec device. We appreciate any clarification
in case we are wrong.

Best regards,
Fernando.

El jue., 28 mar. 2019 a las 16:01, Linda Dunbar (<linda.dunbar@huawei.com>)
escribió:

>
>
> Just to reiterate the concerns and issues I raised during IDR Thurs
> session discussion on using BGP signaling to achieve IPsec Tunnel
> configuration (draft-hujun-idr-bgp-ipsec).
>
> Copy I2NSF WG because there is similar discussion for over a year.
>
> Copy IPsecme WG as the group has many experts on the IPsec configuration.
>
>
>
> 1.      I2NSF WG has an on-going discussion on Controller facilitated
> IPsec configuration which has been discussed for over a year.  Even though
> the I2NSF’s  IPsec Configuration is between Controller and devices, whereas
> the BGP signaling IPsec Configuration proposed by draft-hujun-idr-bgp-ipsec
> is between peers, the configuration parameters to the devices are for the
> same purpose, therefore, should be aligned to avoid future conflicts to the
> industry.
>
>
>
> 2.      When using IPsec Tunnel between two peers, usually they are
> separated by untrusted domain. If Router “A” is allowed to  gets the IPsec
> tunnel configurations from peers across untrusted domain (instead of the
> today’s practice of from administrators), then many issues come up, for
> example:
>
>
>
> How can a router “A” trust the Traffic Selection policy from a remote peer
> B? If the router “A” already has its Traffic Selection policy configured
> for a specific IPsec tunnel, but different from the Traffic Selection
> policy from remote peer B, which policy should Route A enforce for the
> IPsec Tunnel?  If the router “A” doesn’t have Traffic Selection policy
> specified, there are two remote nodes B & C signaling the “A” with
> different Traffic Selection policy, what should A do?
>
>
>
> 3.      RFC5566 only specifies a simple indication of IPsec Encap, but
> doesn’t do any of the IPsec configuration portion.
>
>
>
>
>
> As indicated by BESS WG chair, there are multiple drafts addressing IPsec
> in BESS, IDR, and WGs in Security Area, involved Chairs and ADs may need to
> agree where is the home for continuing the discussion to avoid future
> conflicts.
>
>
>
>
>
> Cheers,
>
> Linda Dunbar
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhD
Department of Sciences and Informatics
University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT
C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 968 189 970
------------------------------------------------------------------------------------------------------