Hi Paul, Tero >> >> “For security reasons, a NSF MUST NOT allow any traffic unless the Security >> Controller mandates so. In other words, since the NSF needs IPsec >> information coming from the SC, if that information is not in place yet the >> safest option is DISCARD (drop) packets." > > I assume there are two types of deployment, "cleartext but encrypt when > possible" and "encryption mandatory". So I feel the MUST NOT is a bit > too strong. Perhaps limit it to say "if encryption is mandatory for > all traffic of an NSF, its default policy MUST be to drop packets to > prevent cleartext packet leaks". > > But then you also do not need per-tunnel "drop" policies, so the SC does > not have to instruct the NSF for anything.
[Authors] Indeed the NSF should have this policy without contacting with the SC. The NSF should know beforehand (before SC can say anything to the NSF) that the whole deployment policy will be "cleartext but encrypt when possible” or “encryption mandatory”. We should be able to use our interface to include a default policy "cleartext but encrypt when possible” or "“encryption mandatory” in the NSF’s startup config. In this case, this startup config is not set by the Security Controller but by some other entity during the NSF “bootstrapping" (before it is deployed in the network). This initial startup config would include what Tero mentioned about different policies that allow this NSF to contact the SC once the NSF has been deployed. Moreover, we should allow to change between "cleartext but encrypt when possible” and “encryption mandatory” if the administrator requires so. This change could be performed by the SC. Perhaps we could add the following text: “For security reasons, if encryption is mandatory for all traffic of a NSF, its default policy MUST be to drop (DISCARD) packets to prevent cleartext packet leaks. This default policy MUST be in the startup configuration datastore in the NSF before the NSF contacts with the Security Controller. Moreover, the startup configuration datastore MUST be pre-configured with the required ALLOW policies that allow to communicate the NSF with the Security Controller once the NSF is deployed. This pre-configuration step is not carried out by the Security Controller but by some other entity before the NSF deployment. In this manner, when the NSF reboots, it will always apply first the configuration in the startup configuration before contacting the Security Controller." > >>> > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa 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
