Dear Mirja and Kathleen, thank you for performing this review and the subsequent discussion. The first set of issues will be addressed in a subsequent email, which includes additional comments from Adrian.
The second issue concerning the lack of authentication will be handled by adding a paragraph to sections 3, as follows: In general, all I2NSF interfaces should require at least mutual authentication and authorization for their use. Other security and privacy considerations are specified in Section 11. These issues will be addressed in version 9 of this I-D, to be released on Monday 11/13. regards, John On Mon, Oct 16, 2017 at 11:22 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hi Mirja, > > Thanks for your review. The first seems simple enough, but I'll leave > that to the editors, shepherd and WG. > > On Mon, Oct 16, 2017 at 11:45 AM, Mirja Kühlewind <i...@kuehlewind.net> > wrote: > > Mirja Kühlewind has entered the following ballot position for > > draft-ietf-i2nsf-framework-08: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have two points below: > > > > 1) The first one should be easy to address: > > "Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the > > Stream Control Transmission Protocol (SCTP) will need to be evaluated > > for applicability. " > > This sentence is not correct; MPTP and SCTP do not provide any redundancy > > mechanisms; they simply just provide a reliable transport as TCP does. > > Therefore I would just remove this sentence here. > > > > Further, on this paragraph, it is not clear to me why you say that > reliable > > transport is needed. Especially for some monitoring purposes, unreliable > > transport might be acceptable as well. Or do you think that all > communication > > for security systems have always to be reliable? I don't think this > document > > discusses things in detail enough to make such an assessment. > > > > 2) This second is a very high level concern and I'm not sure if balloting > > discuss on this is the right thing to do but I definitely would like to > get > > some feedback from the group to better understand this document before > > publication: > > > > This document seem not very security specific to me. To say this in a > somehow > > sloppy way: I have the feeling that if you would just remove the word > > "security" everywhere in the text, it would still be the same document. I > > checked the charter and the charter is also not very concrete about what > to > > expect, besides motivating the needed interfaces with the need for > in-network > > security function. However, if there is nothing security specific about > this, > > what's the difference to the usually control plane architecture as > usually > > deployed with the use of NETCONF? And I am actually wondering if this is > the > > right wg to write such a document. > > I think right as you were becoming an AD as this work was in process > of being chartered, so there may be a gap in knowledge. This WG is a > cross area WG between routing and security. Many of the people in the > WG are from the routing area. Since the devices they were most > concerned in provisioning were security devices (per the customers > that helped bring the work to the IETF), the IESG decided to put this > in the Security area. Yes, the mechanisms are purposefully reusing > existing technologies to accomplish the tasks, but all of the tasks > are interacting with security provisioning services or security > appliances. An example of a draft that was just adopted is one that > includes a YANG module to provision IPsec. The security focus is > important in that example (as well as others) since mistakes with > provisioning of IPsec tunnels could have a large impact. AN advantage > of having this work as a cross area group in the Security area is that > it not only caught the attention of the IPSecMe WG, but they had a > joint interim call to improve the work and the go forward plan will > involve assistance from people contributing to the IPSecME WG. > > I think this one is likely just a gap in background knowledge. > > > > > Further, I would at least have expected that this framework mandates for > high > > control plan security given we are talking about the configuration and > > deployment of security function. However, it does not. It does rarely > provide > > any concrete recommendation here, and basically leaves the door open to > used > > these interfaces without authentication which I think is not acceptable. > > > > This is handled in the drafts that follow, so adding text here > shouldn't be a problem. > > > > > > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
