Re: [Idr] [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

Robert Raszuk <rraszuk@gmail.com> Tue, 02 April 2019 08:31 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166E812009C; Tue, 2 Apr 2019 01:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IDcjnlegXfQz; Tue, 2 Apr 2019 01:31:46 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7671201E6; Tue, 2 Apr 2019 01:31:46 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id g12so5887412pll.11; Tue, 02 Apr 2019 01:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ITFRVKQj45tXvjcYljHAwmoUsQO4ac/eK65r8F1qk7Q=; b=e8rGVCBC0G52LRjnnIU94NDc3rjXOOtnNh5d5bBsMc7zSTzsH1GCk4fVxm7b7kBqzc vxuFqvrGtMGzjkiYT4bsbptOxksopzXccIH0Ew1hRbXerzCqB7W45oLckpCiX2Yj2waQ f1XNLcRpUlAULO2lAb0JiiE6yBLVe52qfTWHqnjiBiALBjpY5K7x70Y9Tv9WXO2fxvxS Y8XrnvMwkPhXD2dVB1R40Jg5yO9jbszISVuxT6pR3YBYImqVT6gwivwk7aeQJZukpfa7 RuNXsur9qUEH7aohZQsMvRnGy3VYB0nX0SiLDryIIU2gcvd4x0qlxPt7GDGhnU86wI6e RNiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ITFRVKQj45tXvjcYljHAwmoUsQO4ac/eK65r8F1qk7Q=; b=EYw3+4qJk9db65OArYEwUxPxzclHSwHGexx2oTecheGDtV1Igskl25mDwRLSmiQEcJ mpP/SN4WcBNzUnblFllzhmcBnokke2FEDrKAKKnkLK0nAEv0qvtty2u+WY+LCWFgGLUS tgTumIKX0CT7KFyHBMYXK69c9Yr5YoeqhavwF/6h38nBpYPKzUwk0eQb0Gfq0De3rYJa bOBmHSHirEVKXS6ljyJ1tTM31bouldUYPsYcVnM0y/KY/vWTDFsx2KMiBjURxUCEGjUm 5hxtAtm8S+wnbV6yk08jOJfzbjtWFPMEnguaMufsooajdDa4iofRwnt4zi8eM5cb0TXj L0Uw==
X-Gm-Message-State: APjAAAU0DaJ5rjBhG1ajGKSUtP6kFYhMhL+3OIZfPv7y0FdvMJTru822 REnKIz8m263/jJky5co0wz69x+mvc5r7Qb7hGKo=
X-Google-Smtp-Source: APXvYqyBIkoww0bCbR6zvYEn34Xo0Pb84EcnhtltuVgk+iT0YdmEjsf/obaNd3GggDe4vv8LEvFfBuel+/aukTxDfsk=
X-Received: by 2002:a17:902:ba85:: with SMTP id k5mr50895578pls.270.1554193905715; Tue, 02 Apr 2019 01:31:45 -0700 (PDT)
MIME-Version: 1.0
References: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@sjceml521-mbs.china.huawei.com> <CAB=gXc6aZ2D1K_q3MjVJMEYxEykJO_oxhoSkOEyytOOaa=_ouA@mail.gmail.com> <PR1PR07MB5755052B214EA1243DF2A7EE95550@PR1PR07MB5755.eurprd07.prod.outlook.com> <C02846B1344F344EB4FAA6FA7AF481F12CA424B2@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12CA424B2@dggemm511-mbx.china.huawei.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Tue, 02 Apr 2019 10:31:34 +0200
Message-ID: <CA+b+ERn16Z65zx1zhh1n2dYPVodUbqB55WCp=2FtFQcCtrF-vQ@mail.gmail.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
Cc: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>, Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>, Linda Dunbar <linda.dunbar@huawei.com>, Roman Danyliw <rdd@cert.org>, idr wg <idr@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Gabriel López Millán <gabilm@um.es>, Yoav Nir <ynir.ietf@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Rafa Marin Lopez <rafa@um.es>, Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="000000000000a9913b058587f781"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9BEjAd6pryMGK8eIhJv0TBdI_Zo>
X-Mailman-Approved-At: Tue, 02 Apr 2019 01:58:01 -0700
Subject: Re: [Idr] [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: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 08:31:51 -0000

Hi Frank,

This draft does not talk about distributing any security related
parameters. Maybe the name is a bit confusing as for some it means to be
IPSec related.

We have discussed the draft in Prague and agreed to also extend it with
other types of secure encap.

I have not discussed it with other authors but perhaps a much proper name
and clearly less controversial would be:
*draft-hujun-idr-encrypted-transport-autodiscovery* or *draft-hujun-idr-eta*
(for short) or something along those lines to reflect what this work is
really about and how it differs from other proposals.

Thx,
R.




On Tue, Apr 2, 2019 at 3:52 AM Xialiang (Frank, Network Standard & Patent
Dept) <frank.xialiang@huawei.com> wrote:

> Hi Jun,
>
> My personal view is no matter which use cases (SDN-based or BGP-based) you
> are for, the basic goal is to configure/distribute the IPSec parameters
> between the associated peers, for next step IKEv2 session negotiation. That
> is why all these related drafts should be aligned in certain way.
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人:* I2nsf [mailto:i2nsf-bounces@ietf.org] *代表 *Hu, Jun (Nokia -
> US/Mountain View)
> *发送时间:* 2019年4月2日 6:22
> *收件人:* Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>;
> Linda Dunbar <linda.dunbar@huawei.com>
> *抄送:* Roman Danyliw <rdd@cert.org>; idr wg <idr@ietf.org>;
> stephane.litkowski@orange.com; i2nsf@ietf.org; idr-chairs@ietf.org;
> Gabriel López Millán <gabilm@um.es>; Yoav Nir <ynir.ietf@gmail.com>;
> Alvaro Retana <aretana.ietf@gmail.com>; ipsec@ietf.org WG <ipsec@ietf.org>;
> Benjamin Kaduk <kaduk@mit.edu>; Rafa Marin Lopez <rafa@um.es>; Paul
> Wouters <paul@nohats.ca>
> *主题:* 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
>
>
>
> Again, Linda, as discussed with you multiple times, my draft is really
> about extending current draft-ietf-idr-tunnel-encaps
> <https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/> to cover
> IPsec tunnel and other encryption tunnel like DTLS in next revsion (based
> on the feedback I got from Prague);
>
> My draft is not intended to address SDN for IPsec use case and it does not
> require a central controller, and there are use cases where a central
> controller is not needed or can’t be used, my draft is intended for those
> cases;
>
>
>
> So I really don’t see any conflict here
>
>
>
> *From:* IPsec <ipsec-bounces@ietf.org> *On Behalf Of *Fernando Pere?íguez
> García
> *Sent:* Monday, April 1, 2019 3:05 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>
> *Cc:* Roman Danyliw <rdd@cert.org>; idr wg <idr@ietf.org>;
> stephane.litkowski@orange.com; i2nsf@ietf.org; idr-chairs@ietf.org;
> Gabriel López Millán <gabilm@um.es>; Yoav Nir <ynir.ietf@gmail.com>;
> Alvaro Retana <aretana.ietf@gmail.com>; ipsec@ietf.org WG <ipsec@ietf.org>;
> Benjamin Kaduk <kaduk@mit.edu>; Rafa Marin Lopez <rafa@um.es>; Paul
> Wouters <paul@nohats.ca>
> *Subject:* Re: [IPsec] using BGP signaling to achieve IPsec Tunnel
> configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the
> I2NSF's Controller facilitated IPsec configuration
>
>
>
> 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
>
> ------------------------------------------------------------------------------------------------------
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>