On Thu, Jul 28, 2016 at 6:12 AM, Rafa Marin Lopez <[email protected]> wrote:
>> 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. While it would certainly be good to evaluate route-based vs policy-based flow-selectors for the tunnel, it seems a bit inappropriate to do this using a routing protocol, because IPsec flow selectors can easily be richer than just end-point addresses. As rfc 5406 points out, the routing protocol itself may be a candidate for IPsec. --Sowmini _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
