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) <[email protected]> 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:[email protected]] *代表 *Hu, Jun (Nokia - > US/Mountain View) > *发送时间:* 2019年4月2日 6:22 > *收件人:* Fernando Pereñíguez García <[email protected]>; > Linda Dunbar <[email protected]> > *抄送:* Roman Danyliw <[email protected]>; idr wg <[email protected]>; > [email protected]; [email protected]; [email protected]; > Gabriel López Millán <[email protected]>; Yoav Nir <[email protected]>; > Alvaro Retana <[email protected]>; [email protected] WG <[email protected]>; > Benjamin Kaduk <[email protected]>; Rafa Marin Lopez <[email protected]>; Paul > Wouters <[email protected]> > *主题:* 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 <[email protected]> *On Behalf Of *Fernando Pere?íguez > García > *Sent:* Monday, April 1, 2019 3:05 PM > *To:* Linda Dunbar <[email protected]> > *Cc:* Roman Danyliw <[email protected]>; idr wg <[email protected]>; > [email protected]; [email protected]; [email protected]; > Gabriel López Millán <[email protected]>; Yoav Nir <[email protected]>; > Alvaro Retana <[email protected]>; [email protected] WG <[email protected]>; > Benjamin Kaduk <[email protected]>; Rafa Marin Lopez <[email protected]>; Paul > Wouters <[email protected]> > *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 (<[email protected]>) > 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 > [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
