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 >
- [Idr] using BGP signaling to achieve IPsec Tunnel… Linda Dunbar
- Re: [Idr] [IPsec] using BGP signaling to achieve … Fernando Pereñíguez García
- Re: [Idr] [IPsec] using BGP signaling to achieve … Hu, Jun (Nokia - US/Mountain View)
- [Idr] 答复: [IPsec] using BGP signaling to achieve … Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Idr] [I2nsf] 答复: [IPsec] using BGP signaling… Robert Raszuk
- Re: [Idr] 答复: [I2nsf] 答复: [IPsec] using BGP signa… Alvaro Retana
- [Idr] 答复: [I2nsf] 答复: [IPsec] using BGP signaling… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Idr] [I2nsf] 答复: [IPsec] using BGP signaling… Hu, Jun (Nokia - US/Mountain View)
- Re: [Idr] [IPsec] using BGP signaling to achieve … Linda Dunbar
- Re: [Idr] [IPsec] using BGP signaling to achieve … Linda Dunbar
- Re: [Idr] [IPsec] using BGP signaling to achieve … Hu, Jun (Nokia - US/Mountain View)
- Re: [Idr] 答复: [I2nsf] 答复: [IPsec] using BGP signa… Susan Hares
- Re: [Idr] 答复: [I2nsf] 答复: [IPsec] using BGP signa… russ
- Re: [Idr] [bess] 答复: [I2nsf] 答复: [IPsec] using BG… Susan Hares