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. 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. 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. 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. Regards, Yoav _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
