Hi, Thanks for reading the doc, comments in line ...
> El 13 abr 2017, a las 23:42, Yoav Nir <ynir.i...@gmail.com> escribió: > >> > > >>> - I2NSF has a proposal on using Controller to manager all the IPSec >>> tunnels: >>> https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection >>> >>> <https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection>. >>> What kind of issues do you see with the proposed approach? >> >> I didn't read it. > > I did. They have two cases. In case #1 the controller provisions credentials > for IKE and entries in PAD and SPD. In case #2 you forego IKE and have the > controller provision the SAs (including keys). > > I especially didn’t like case #2. Sharing a secret key among three entities > is a bad idea. A shared authentication credential can also be misused, but > that’s a hard attack to mount. A shared traffic key makes the controller a > very attractive target. Well, we are talking about key distribution, not key sharing. The controller is acting a trusted key distribution center. The same problem arises in KDCs or IdPs. In any case, we propose two cases to cover different scenarios, if case#2 does not fit, for whatever reason, in this particular scenario, case#1 could be used. > > More in general, SDN was born in the data center. In a data center an > all-knowing controller makes sense. This is true for routing as it is for > NSFs such as firewalls, IDPs and IDSs. VPN extends the reach of the private > network to all corners of the Internet. Think of a store chain with a CPE in > every one of thousands of branches. Or a bank. The problem there is that > there is no central administrative function. Local branches may switch ISP > and renumber their network without bothering to tell the IT people. So the > model where the controller knows everything is tough to deploy in practice. > > It is probably necessary to have two-way communications, where the CPE tells > the controller about its topology (how it partitions the Internet to “in” vs > “out”) so that the controller can set up the appropriate SPDs. > > There have been several attempts at this. RFC 7018 describes requirements, > but the WG ultimately failed to publish a solution document. There are also > more recent commercial solutions sold today under the marketing name of > “SD-WAN”, which is sort of like SDN if you squint hard enough. All of these > have some interaction between CPE and controllers (or hubs) which draft-abad > does not. The doc does not preclude this communication between the CPE and the Controller in order to allow the latter to be aware of configuration details about the former. In fact, Netconf/yang (proposed as an example of southbound interface in the draft) or SNMP could be used for that. We should clarify this point in the next version (we are currently working on it). Thanks again for you comments. Regards, Gabi. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> ----------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gab...@um.es <mailto:gab...@um.es>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
