Hi Yoav: > El 27 jul 2016, a las 17:26, Yoav Nir <[email protected]> escribió: > > Hi, Dave. > > On 22 Jul 2016, at 1:02 PM, David Carrel <[email protected]> wrote: > >> I am quite interested in the notion of integrating IKE (or IKE-like) >> security and functionality into the SD-WAN controller messaging. My company >> does this now, though not in a standard way. All IPSEC key management comes >> from the SD-WAN controller. It is tricky to do this right, but it can be >> done and will continue to be done. It can be highly scalable. I'd like to >> see us work on doing this in a standard way and I'm happy to help out. >> >> Several concerns were raised in the meeting, and unfortunately there wasn't >> time for all comments then. While I think the concerns raised are good >> concerns, I also believe they are demonstrably addressable. Yes, this needs >> to be done carefully!! >> >> Additionally to Yoav's point, yes there is additional information that >> SD-WAN controllers need to send. Some of this will be proprietary. Yet >> much of it will become standard over time. I don't think we can enumerate >> all of this now or even soon. It seems there are efforts underway to do >> this. But we can start with a flexible way to add this incrementally over >> time. > > So I will be glad to start a conversation on this list about what the IETF > can do about defining IPsec from a controller.
[Rafa] That would be great. > > > I think the first question is “who’s tunnel is it anyway”. The use cases in > section 9 of draft-abad (except 9.3) see the IPsec tunnel as a service > provided by the ISP. With the two architectures they propose (key exchange > protocol on the controller vs key exchange protocol on the NSF) either the > keys or credentials are provided by the ISP. This is one way to do this, but > the more common case (at least for me) is that the organization (or > “Enterprise”) that provides the VPN, while the ISP is the entirely > replaceable “middle”. Many enterprises (medical, financial, others) cannot > let the ISP see their cleartext, so both the controller function and the NSF > function should (IMO) be owned by the enterprise. [Rafa] That is fine. Section 9 are just possible uses cases (examples) that can be extended or modified. In the end, the idea of the I-D is to show that there is controller providing IPsec information to the NSF. > > Another question raised at the meeting is about whether the controller > provides configuration and credentials (SPD+PAD) and lets the NSF negotiate > keys, or whether the controller provides the actual keys. I like the former > better for some of the reasons mentioned at the meeting, but also for forward > secrecy. If the controller never gets access to traffic keys, it cannot leak > them. It’s usually better to not transmit secret keys over the network. [Rafa] Two comments here. 1) I see the controller as a trusted entity, otherwise it should not be trusted to any operation (not only IPsec-related). Thus, providing keying material should not be a problem. Even in case the NSFs negotiate keys, IKE credentials may be provided by the controller. Moreover, with the right permissions, the controller could access to the SAD state and observe keys there. 2) Distributing key material will be performed over a secure channel between the controller and the NSF, so no secret keys in clear are transmitted over the network. Btw, with my comments I am not trying to move forward case 1 or case 2, I am just trying to highlight that both models will have advantages and disadvantages and it would be worthy studying both. > > A third question that is worth considering is route-based vs policy-based (or > domain-based) IPsec. Generally there are two modes of configuring IPsec. One > is where the NSFs are pre-configured with each other’s protected domain, so > they know what flows to encrypt and what flows not to encrypt. The other mode > sets up a tunnel and allows a routing protocol running over said tunnel > decide what does and what does not go through the tunnel. The draft mentions > only domain-based VPN, which is a fine decision to make, but if this group > would like to work on controlling IPsec, it should at least acknowledge that > both modes exist, and pick one explicitly. [Rafa] Agree. In any case, the I-D is flexible in this sense, so we should definitely add this to the I-D. In fact, we paid more attention to the structures/databases in IPsec that the controller needs to handle in the NSF. As I see it, in the I-D we reflected a configuration step “Flow Protection Policies (1)” done by the administrator with the northbound interface. The controller can decide to do route-based or policy-based IPsec and, in the end, apply what it is required in the NFSs involved. What do you think? Best Regards. > > Regards, > > Yoav > > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
