Hi John, thanks for your edits! They look good to me. Sorry for my late reply but I’ve seen you have find a resolution for your one remaining question below.
Mirja > Am 12.11.2017 um 23:05 schrieb John Strassner <straz...@gmail.com>: > > Dear Mirja, Adrial, and Kathleen, > > thank you for performing this review, and the discussions that followed. > I hope that the following addresses the issues that you have raised. > This content will be published in version 9 of this I-D, to be released on > Monday 11/13. > > POINT #1 > 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. > <jcs> > DONE > </jcs> > > 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. > <jcs> > I believe that we need reliable transport for critical management-based > operations, but NOT for other mechanisms (e.g., monitoring). The following > text is proposed: > > Therefore, the transport mechanism used to carry management data and > information must be secure. It does not have to be a reliable > transport; rather, a transport-independent reliable messaging > mechanism is required, where communication can be performed reliably > (e.g., by establishing end-to-end communication sessions and by > introducing explicit acknowledgement of messages into the > communication flow). Latency requirements for control message > delivery must also be evaluated. Note that monitoring does not > reliable transport. > </jcs> > > POINT 2 > 2a - Adrian's suggested text is implemented, but all normative language > (in UPPER CASE) is changed to informative language (in lower case) > since we are now using RFC8174 boilerplate. > > 2b - end of section 4: > "The above threats may be mitigated by requiring the use of an AAA > framework for all users to access the I2NSF environment. This could > be further enhanced by requiring attestation to be used to detect > changes to the I2NSF environment by authorized parties.“ > <jcs> > That is the present text; what would you suggest to strengthen it? > </jcs> > > > 2c - sec 6.1: > „ Given the role of the I2NSF > Controller, a mutual authentication of users and the I2NSF > Controller may be required.“ > Why not „is required“? > <jcs> > DONE > </jcs> > > > 2c - And I’m also uncertain about this part in sec 6.2: > "The network connection between the I2NSF Controller and NSFs can > rely either on: > > o Closed environments, where there is only one administrative > domain. Less restrictive access control and simpler validation > can be used inside the domain because of the protected nature of > a closed environment.“ > <jcs> > This text was changed to: > > o Closed environments, where there is only one administrative > domain. Such environments provide a more **isolated** > environment, but still communicate over the same set of I2NSF > interfaces present in open environments (see above). Hence, the > security control and access requirements for closed environments > are the same as those for open environments. > </jcs> > > best regards, > John > > On Mon, Oct 23, 2017 at 8:15 AM, Mirja Kuehlewind (IETF) > <i...@kuehlewind.net> wrote: > Hi Adrian, > > see below. > > > Am 23.10.2017 um 17:00 schrieb Adrian Farrel <adr...@olddog.co.uk>: > > > > <hat style="shepherd"> > > > > Trying to extract actions for the authors from this interesting Discussion. > > I think that the first point is closed with Mirja still surprised, but no > > action needed. > > Yes... > > > The second point needs reinforcement of the need for strong security in the > > management (not control) plane used in the architecture: in particular, > > that the messages that configure network security functions must, > > themselves, else the security functions are vulnerable and so the whole > > network at risk. > > > > Section 11 currently reads... > > > > 11. Security Considerations > > > > NSF control and monitoring demand trustworthy, robust, and fully > > secured access. Therefore, proper secure communication channels > > have to be carefully specified for carrying the controlling and > > monitoring information between the NSFs and their management > > entity or entities. This has been discussed in Section 4. > > > > This framework is intended for enterprise users, with or without > > cloud service offerings. Privacy of users should be provided by > > using existing standard mechanisms, such as encryption; > > anonymization of data should also be done (if possible depending > > on the transport used). Such mechanisms require confidentiality > > and integrity. > > > > ... I suggest that this is enhanced to read... > > > > 11. Security Considerations > > > > The configuration, control, and monitoring of NSFs provide access to > > and information about security functions that are critical for > > delivering network security and for protecting end-to-end traffic. > > Therefore, it is important that the messages that are exchanged > > within this architecture utilize a trustworthy, robust, and fully > > secure communication channel. The mechanisms adopted within the > > solution space MUST include proper secure communication channels > > that are carefully specified for carrying the controlling and > > monitoring information between the NSFs and their management entity > > or entities. The threats associated with remotely managed NSFs are > > discussed in Section 4, and solutions MUST address those concerns. > > > > This framework is intended for enterprise users, with or without > > cloud service offerings. Privacy of users should be provided by > > using existing standard mechanisms, such as encryption; > > anonymization of data should also be done (if possible depending > > on the transport used). Such mechanisms require confidentiality > > and integrity. > > END > > > Thanks that’s much better from my point of view. Maybe also > s/Privacy of users should be provided by/Privacy of users MUST be provided > by/ ? > > > There are a few more cases that could potentially be strengthened as well: > > end of section 4: > "The above threats may be mitigated by requiring the use of an AAA > framework for all users to access the I2NSF environment. This could > be further enhanced by requiring attestation to be used to detect > changes to the I2NSF environment by authorized parties.“ > > > sec 6.1: > „ Given the role of the I2NSF > Controller, a mutual authentication of users and the I2NSF > Controller may be required.“ > Why not „is required“? > > And I’m also uncertain about this part in sec 6.2: > "The network connection between the I2NSF Controller and NSFs can > rely either on: > > o Closed environments, where there is only one administrative > domain. Less restrictive access control and simpler validation > can be used inside the domain because of the protected nature of > a closed environment.“ > > Maybe you can have another look at these cases? Also not sure I’ve caught > very just now… > > Thanks, > Mirja > > > > > > > > > > > >> -----Original Message----- > >> From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net] > >> Sent: 23 October 2017 12:10 > >> To: Kathleen Moriarty > >> Cc: draft-ietf-i2nsf-framew...@ietf.org; i2nsf@ietf.org; Yoav Nir; The > >> IESG; i2nsf- > >> cha...@ietf.org; Adrian Farrel > >> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-i2nsf-framework-08: > >> (with > >> DISCUSS) > >> > >> Hi Kathleen, > >> > >> see below. > >> > >>> Am 16.10.2017 um 20:22 schrieb Kathleen Moriarty > >> <kathleen.moriarty.i...@gmail.com>: > >>> > >>> 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. > >> > >> 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 > 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
