Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
Hi Ben, I will put your comments on the trust for the NSFs in Security Considerations Section in the Capability Data Model Draft. Thanks. Best Regards, Paul On Fri, Sep 25, 2020 at 11:37 AM Benjamin Kaduk wrote: > Hi Linda, > > Thank you for the reference to RFC 8329 (especially Section 4, which I > definitely did not look at previously). To be clear, I agree with what is > in the framework document and that we do not want to duplicate its content > in every data model. That said, the main privacy consideration that I > wanted to raise is that (at least some of) the NSFs themselves have access > to the users' private data -- no matter what mechanisms we put in place to > encrypt/anonymize that data inside and at the boundary of the i2nsf > protocols, the NSFs themselves have to be trusted to behave properly. I > don't think that aspect is covered in Sections 4 or 11 of RFC 8329, so it > may be appropriate to mention here. > > Thanks, > > Ben > > On Thu, Sep 24, 2020 at 03:54:18PM +, Linda Dunbar wrote: > > Ben, > > > > Thank you very much for the detailed comments. > > > > As a co-chair, I just want to address your comments on "“not see any > discussion of privacy considerations”. The draft authors will address your > detailed comments & suggestions on the document. > > > > There are suite of Data Models from I2NSF WG. All of them are branch out > from the I2NSF Framework RFC8329. The Security and privacy description > from RFC 8329 are applicable to all of them. RFC8329 states that > > 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 Section 4 of RFC 8329 specifies the Threats Associated with > Externally Provided NSFs. > > > > Therefore, the WG doesn’t think it is necessary to repeat in every Data > Model draft of the Security and Privacy described in the I2NSF framework > RFC8329. > > > > Best Regards, > > > > Linda Dunbar > > > > > > -Original Message- > > From: Benjamin Kaduk via Datatracker > > Sent: Wednesday, September 23, 2020 12:12 AM > > To: The IESG > > Cc: draft-ietf-i2nsf-capability-data-mo...@ietf.org; > i2nsf-cha...@ietf.org; i2nsf@ietf.org; Linda Dunbar ; > dunbar...@gmail.com > > Subject: Benjamin Kaduk's Discuss on > draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-i2nsf-capability-data-model-12: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3Dreserved=0 > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3Dreserved=0 > > > > > > > > -- > > DISCUSS: > > -- > > > > There are many elements of the YANG module whose semantics seem > underspecified to me. I noted quite a few in the COMMENT section, and I > hope that those aspects of my comments are clear (as it would be > substantial effort to partition the comments and move the questions of > unclear semantics into the discuss section), but I am happy to assist in > the classification if needed. > > > > I think that the data nodes of this module as written are probably not > reflecting the intent -- it seems that the only elements of the 'nsf' > > list are the string nsf-name; there is no "uses nsf-capabilities" stanza > to bring in the grouping that contains all the interesting parts. > > Specifically, I do not see how the tree diagram reflects the current > module. > > > > I'm surprised to not see any discussion of privacy considerations -- > some of the features that we define capability indicators for are highly > sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE audio > to identify individuals, web filtering) that inherently require access to > individuals' private data. Not only should we note that private
Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
Hi Linda, Thank you for the reference to RFC 8329 (especially Section 4, which I definitely did not look at previously). To be clear, I agree with what is in the framework document and that we do not want to duplicate its content in every data model. That said, the main privacy consideration that I wanted to raise is that (at least some of) the NSFs themselves have access to the users' private data -- no matter what mechanisms we put in place to encrypt/anonymize that data inside and at the boundary of the i2nsf protocols, the NSFs themselves have to be trusted to behave properly. I don't think that aspect is covered in Sections 4 or 11 of RFC 8329, so it may be appropriate to mention here. Thanks, Ben On Thu, Sep 24, 2020 at 03:54:18PM +, Linda Dunbar wrote: > Ben, > > Thank you very much for the detailed comments. > > As a co-chair, I just want to address your comments on "“not see any > discussion of privacy considerations”. The draft authors will address your > detailed comments & suggestions on the document. > > There are suite of Data Models from I2NSF WG. All of them are branch out from > the I2NSF Framework RFC8329. The Security and privacy description from RFC > 8329 are applicable to all of them. RFC8329 states that > 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 Section 4 of RFC 8329 specifies the Threats Associated with Externally > Provided NSFs. > > Therefore, the WG doesn’t think it is necessary to repeat in every Data Model > draft of the Security and Privacy described in the I2NSF framework RFC8329. > > Best Regards, > > Linda Dunbar > > > -Original Message- > From: Benjamin Kaduk via Datatracker > Sent: Wednesday, September 23, 2020 12:12 AM > To: The IESG > Cc: draft-ietf-i2nsf-capability-data-mo...@ietf.org; i2nsf-cha...@ietf.org; > i2nsf@ietf.org; Linda Dunbar ; dunbar...@gmail.com > Subject: Benjamin Kaduk's Discuss on > draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-i2nsf-capability-data-model-12: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3Dreserved=0 > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3Dreserved=0 > > > > -- > DISCUSS: > -- > > There are many elements of the YANG module whose semantics seem > underspecified to me. I noted quite a few in the COMMENT section, and I hope > that those aspects of my comments are clear (as it would be substantial > effort to partition the comments and move the questions of unclear semantics > into the discuss section), but I am happy to assist in the classification if > needed. > > I think that the data nodes of this module as written are probably not > reflecting the intent -- it seems that the only elements of the 'nsf' > list are the string nsf-name; there is no "uses nsf-capabilities" stanza to > bring in the grouping that contains all the interesting parts. > Specifically, I do not see how the tree diagram reflects the current module. > > I'm surprised to not see any discussion of privacy considerations -- some of > the features that we define capability indicators for are highly sensitive > and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify > individuals, web filtering) that inherently require access to individuals' > private data. Not only should we note that private information is made > accessible in this manner, but we should also reiterate that the > nodes/entities given access to this data need to be tightly secured and > monitored, to prevent leakage or other unauthorized disclosure of private > data. > > I also think we need to mention that authentication and proper
Re: [I2nsf] Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT)
Ben, Thank you very much for the detailed comments. As a co-chair, I just want to address your comments on "“not see any discussion of privacy considerations”. The draft authors will address your detailed comments & suggestions on the document. There are suite of Data Models from I2NSF WG. All of them are branch out from the I2NSF Framework RFC8329. The Security and privacy description from RFC 8329 are applicable to all of them. RFC8329 states that 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 Section 4 of RFC 8329 specifies the Threats Associated with Externally Provided NSFs. Therefore, the WG doesn’t think it is necessary to repeat in every Data Model draft of the Security and Privacy described in the I2NSF framework RFC8329. Best Regards, Linda Dunbar -Original Message- From: Benjamin Kaduk via Datatracker Sent: Wednesday, September 23, 2020 12:12 AM To: The IESG Cc: draft-ietf-i2nsf-capability-data-mo...@ietf.org; i2nsf-cha...@ietf.org; i2nsf@ietf.org; Linda Dunbar ; dunbar...@gmail.com Subject: Benjamin Kaduk's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3Dreserved=0 for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3Dreserved=0 -- DISCUSS: -- There are many elements of the YANG module whose semantics seem underspecified to me. I noted quite a few in the COMMENT section, and I hope that those aspects of my comments are clear (as it would be substantial effort to partition the comments and move the questions of unclear semantics into the discuss section), but I am happy to assist in the classification if needed. I think that the data nodes of this module as written are probably not reflecting the intent -- it seems that the only elements of the 'nsf' list are the string nsf-name; there is no "uses nsf-capabilities" stanza to bring in the grouping that contains all the interesting parts. Specifically, I do not see how the tree diagram reflects the current module. I'm surprised to not see any discussion of privacy considerations -- some of the features that we define capability indicators for are highly sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify individuals, web filtering) that inherently require access to individuals' private data. Not only should we note that private information is made accessible in this manner, but we should also reiterate that the nodes/entities given access to this data need to be tightly secured and monitored, to prevent leakage or other unauthorized disclosure of private data. I also think we need to mention that authentication and proper authorization will be needed to register as an NSF providing these capabilities. The examples do not seem to conform to the current module structure (e.g., exact-fourth-layer-port-num and range-fourth-layer-port-num). I worry a little bit that even the structure of the tree risks "imposing functional requirements or constraints" upon NSF developers (in the words of the framework). How would, for example, SCTP capabilities be indicated, let alone QUIC? (With an augmentation, clearly, but is that undue burden?) While the classification into ingress/egress/log is natural, it also may be found limiting; consider, for example, a setup involving port mirroring -- is that an ingress action or egress? If traffic is dropped as part of a different ingress filtering capability, does it still get sent to the port mirror? -- COMMENT:
[I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS)
Magnus Westerlund has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: 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-capability-data-model/ -- DISCUSS: -- I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack the semantics to understand if they do map to protocol values. This discuss is more a place holder to be aware that this document needs to re-reviewed after having addressed by transport people. ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Murray Kucherawy's No Objection on draft-ietf-i2nsf-capability-data-model-12: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: No Objection 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-capability-data-model/ -- COMMENT: -- I support Eric's DISCUSS position about the information model vs. data model publications. The smashed-together list of references at the top of Section 5 could use some formatting. I tripped over several of the editorial points Barry found. Here's one more. In Section 3: o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Block malicious users "for" IPv6 traffic? I don't understand. Perhaps "block IPv6 traffic from malicious users"? ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
