Hi Kathleen, see below.
> Am 16.10.2017 um 20:22 schrieb Kathleen Moriarty > <[email protected]>: > > 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 <[email protected]> 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. I was just step up when this was charter but I got the background that this is somewhere between SEC and RTG. I was still very much surprised how few security focus there is in this document. > >> >> 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. I think making some stronger recommendations about how to secure the control plan communication for security-relevant configurations would address my discuss sufficiently to move to ‚No Objection‘. Thanks, Mirja > >> >> >> > > > > -- > > Best regards, > Kathleen > _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
