Hi I2NSF Chairs and I2NSFers, My SKKU team and I support this draft as a WG draft even though our chair Yoav has approved it as a WG draft. :-)
Especially, when an NSF (e.g., DPI) is provided by the third party according to the Service Function Chaining (SFC) (e.g., a sequence of Firewall and DPI), another NSF (e.g., Firewall) in a site needs to encrypt packets with IPsec in order to protect them from an adversary outside. The idea that Security Controller plays a role of a coordinator for IKEv2 and IPsec seems a right direction in terms of efficiency. I recommend that the authors explicitly address the importance in a scenario where the third-party NSFs are used for security services in Section 7.2 in the draft. There is a small typo in Page 20: OLD: Figure 5 describes case 1 when two Security Controllers are involved in the process. NEW: Figure 6 describes case 2 when two Security Controllers are involved in the process. Thanks. Best Regards, Paul On Tue, Oct 3, 2017 at 6:58 AM, Yoav Nir <[email protected]> wrote: > Hi all. > > Thank you all for chiming in. The response was mostly positive, and we > judge that there is consensus to adopt this draft. > > Authors: please re-submit as draft-ietf-i2nsf-ipsec-flow-00 . > > During the call for adoption there was a suggestion to split the draft in > two. Because “case 2” (where the controller installs SAs with traffic > keys) is controversial whereas “case 1” (where the controller only installs > credentials and PAD entries) is not, it was suggested to make case 2 a > separate document. This could well be a decision we will make in the > future, but for now Linda and I believe that this is not a good idea. If > the document is split, it means we also have to split the YANG models, > creating two separate languages to perform the same task. There would be > little point in having an SAD model in the case 1 document, and each > document would need different versions of the PAD model. > > For the time being, let’s have a single document. If the security posture > is different, this can be covered in the text itself. Note again that this > decision is not final or binding and the group may decide to change it > before we finish with this document. > > Thanks again. > > Yoav > > On 15 Sep 2017, at 11:09, Yoav Nir <[email protected]> wrote: > > Hi all > > This starts a two-week call for adoption of > draft-abad-i2nsf-sdn-ipsec-flow-protection. > Please send in your comments both for and against adopting this as a > working group document by EOD Monday, October 2nd. As always, adoption by > the working group does not require consensus on the details, and the group > will have plenty of time to discuss the contents and modify them as > appropriate. > > This draft was proposed a while ago, and the interim meeting earlier this > month was dedicated to discussing its issues. For more information: > > - The draft: https://datatracker.ietf.org/doc/draft-abad-i2nsf- > sdn-ipsec-flow-protection/ > - The minutes of the interim meeting: https://datatracker. > ietf.org/meeting/interim-2017-i2nsf-01/materials/minutes- > interim-2017-i2nsf-01-201709061600/ > > <https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/materials/minutes-interim-2017-i2nsf-01-201709061600/> > > > Thanks > > Yoav > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
