Re: [I2nsf] AD review of draft-ietf-i2nsf-framework
Hi Kathleen, thank you for your comments, and sorry for the delay. I have addressed all of them, and tried to remove other examples of home user usage. I added a brief privacy statement to the security section. best regards, John On Tue, Oct 10, 2017 at 1:13 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hello, > > I had placed this on the telechat in a little over 2 weeks. If there > is no response and update today, I will have to move it until after > Singapore as the IETF last call takes 2 weeks and I'd like a couple of > days after that completes prior to the telechat. Please let me know > the status so I can adjust telechat dates or start the IETF last call. > > Thank you, > Kathleen > > On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty > wrote: > > Hello, > > > > Thank you for your work on this document! I know it underwent many > > revisions and it can be difficult to merge text pulling together ideas > > from numerous contributors. The draft is well written and easy to > > understand, thank you for all your hard work, it shows! > > > > Now to a few comments I'd like to see if we can clear up before > > starting last call. > > > > Section 5 begins with the following text: > > > >An important concept underlying this framework is the fact that > >attackers do not have standards as to how to attack networks, so it > >is equally important to not constrain NSF developers to offering a > >limited set of security functions. In other words, the introduction > >of I2NSF standards should not make it easier for attackers to > >compromise the network. > > > > I think the first sentence could be safely dropped and the second > > sentence altered to something like the following: > > > >A basic tenet in the introduction > >of I2NSF standards is that he standards should not make it easier > > for attackers to > >compromise the network. > > > > You may get comments on the following point, also in section 5: > > > >o Be seen as endorsing a best common practice for the implementation > > of NSFs > > > > But, I am not going to suggest a change yet. I could see further > > explanation being needed for the text. > > > > Section 7.1 > > > > I'd suggest using a different example for the time constraints, a > > business one would be better. The one listed for a home user could > > have the reader jump to censorship concerns if this is targeted to > > home users. How about an ERP system is allowed to be accessed from > > the corporate network only during business hours for a high privileged > > class of users? Outside of the times could indicate an attack and > > you'd want that access approved if there was an extenuating > > circumstance. > > > > Do you plan to allow for rule setting to be extended to home users? I > > think that will raise concern as I thought scope was limited to > > enterprises with cloud service offerings. > > > > Section 8: > > s/I2NSF system can explose/I2NSF system can expose/ > > > > Section 11. > > > > Since this is the framework, the security considerations are fine, but > > you do need to add a privacy considerations section. I can see a few > > possible privacy concerns and there may be more that I am missing. > > > > Privacy of end users with the reporting options. If all of the fields > > described in section 10 could be used in reports, you have a lot of > > interesting tracking information that is now easily accessible with > > quick reports. The ability to leave out identifying information will > > be important as will having ways to protect that data at rest as well > > as in transit. > > > > I2NSF could also be used in targeted ways toward individuals in attack > > scenarios, both an invasion of privacy and a security consideration > > for the attack possibilities. If home use is not out-of-scope, you'll > > have real issues here and it will be really hard to tackle the > > security and privacy concerns. > > > > The I2NSF user information could be sensitive too - meaning the person > > doing provisioning. What protects their account information (I think > > you have this covered), you may want to state it for privacy reasons. > > > > Thanks! > > -- > > > > Best regards, > > Kathleen > > > > -- > > 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
Re: [I2nsf] AD review of draft-ietf-i2nsf-framework
Hi Kathleen, I will do the edits that you request, and try and submit later this afternoon. best regards, John On Tue, Oct 10, 2017 at 1:13 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hello, > > I had placed this on the telechat in a little over 2 weeks. If there > is no response and update today, I will have to move it until after > Singapore as the IETF last call takes 2 weeks and I'd like a couple of > days after that completes prior to the telechat. Please let me know > the status so I can adjust telechat dates or start the IETF last call. > > Thank you, > Kathleen > > On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty > wrote: > > Hello, > > > > Thank you for your work on this document! I know it underwent many > > revisions and it can be difficult to merge text pulling together ideas > > from numerous contributors. The draft is well written and easy to > > understand, thank you for all your hard work, it shows! > > > > Now to a few comments I'd like to see if we can clear up before > > starting last call. > > > > Section 5 begins with the following text: > > > >An important concept underlying this framework is the fact that > >attackers do not have standards as to how to attack networks, so it > >is equally important to not constrain NSF developers to offering a > >limited set of security functions. In other words, the introduction > >of I2NSF standards should not make it easier for attackers to > >compromise the network. > > > > I think the first sentence could be safely dropped and the second > > sentence altered to something like the following: > > > >A basic tenet in the introduction > >of I2NSF standards is that he standards should not make it easier > > for attackers to > >compromise the network. > > > > You may get comments on the following point, also in section 5: > > > >o Be seen as endorsing a best common practice for the implementation > > of NSFs > > > > But, I am not going to suggest a change yet. I could see further > > explanation being needed for the text. > > > > Section 7.1 > > > > I'd suggest using a different example for the time constraints, a > > business one would be better. The one listed for a home user could > > have the reader jump to censorship concerns if this is targeted to > > home users. How about an ERP system is allowed to be accessed from > > the corporate network only during business hours for a high privileged > > class of users? Outside of the times could indicate an attack and > > you'd want that access approved if there was an extenuating > > circumstance. > > > > Do you plan to allow for rule setting to be extended to home users? I > > think that will raise concern as I thought scope was limited to > > enterprises with cloud service offerings. > > > > Section 8: > > s/I2NSF system can explose/I2NSF system can expose/ > > > > Section 11. > > > > Since this is the framework, the security considerations are fine, but > > you do need to add a privacy considerations section. I can see a few > > possible privacy concerns and there may be more that I am missing. > > > > Privacy of end users with the reporting options. If all of the fields > > described in section 10 could be used in reports, you have a lot of > > interesting tracking information that is now easily accessible with > > quick reports. The ability to leave out identifying information will > > be important as will having ways to protect that data at rest as well > > as in transit. > > > > I2NSF could also be used in targeted ways toward individuals in attack > > scenarios, both an invasion of privacy and a security consideration > > for the attack possibilities. If home use is not out-of-scope, you'll > > have real issues here and it will be really hard to tackle the > > security and privacy concerns. > > > > The I2NSF user information could be sensitive too - meaning the person > > doing provisioning. What protects their account information (I think > > you have this covered), you may want to state it for privacy reasons. > > > > Thanks! > > -- > > > > Best regards, > > Kathleen > > > > -- > > 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
Re: [I2nsf] AD review of draft-ietf-i2nsf-framework
Hello, I had placed this on the telechat in a little over 2 weeks. If there is no response and update today, I will have to move it until after Singapore as the IETF last call takes 2 weeks and I'd like a couple of days after that completes prior to the telechat. Please let me know the status so I can adjust telechat dates or start the IETF last call. Thank you, Kathleen On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty wrote: > Hello, > > Thank you for your work on this document! I know it underwent many > revisions and it can be difficult to merge text pulling together ideas > from numerous contributors. The draft is well written and easy to > understand, thank you for all your hard work, it shows! > > Now to a few comments I'd like to see if we can clear up before > starting last call. > > Section 5 begins with the following text: > >An important concept underlying this framework is the fact that >attackers do not have standards as to how to attack networks, so it >is equally important to not constrain NSF developers to offering a >limited set of security functions. In other words, the introduction >of I2NSF standards should not make it easier for attackers to >compromise the network. > > I think the first sentence could be safely dropped and the second > sentence altered to something like the following: > >A basic tenet in the introduction >of I2NSF standards is that he standards should not make it easier > for attackers to >compromise the network. > > You may get comments on the following point, also in section 5: > >o Be seen as endorsing a best common practice for the implementation > of NSFs > > But, I am not going to suggest a change yet. I could see further > explanation being needed for the text. > > Section 7.1 > > I'd suggest using a different example for the time constraints, a > business one would be better. The one listed for a home user could > have the reader jump to censorship concerns if this is targeted to > home users. How about an ERP system is allowed to be accessed from > the corporate network only during business hours for a high privileged > class of users? Outside of the times could indicate an attack and > you'd want that access approved if there was an extenuating > circumstance. > > Do you plan to allow for rule setting to be extended to home users? I > think that will raise concern as I thought scope was limited to > enterprises with cloud service offerings. > > Section 8: > s/I2NSF system can explose/I2NSF system can expose/ > > Section 11. > > Since this is the framework, the security considerations are fine, but > you do need to add a privacy considerations section. I can see a few > possible privacy concerns and there may be more that I am missing. > > Privacy of end users with the reporting options. If all of the fields > described in section 10 could be used in reports, you have a lot of > interesting tracking information that is now easily accessible with > quick reports. The ability to leave out identifying information will > be important as will having ways to protect that data at rest as well > as in transit. > > I2NSF could also be used in targeted ways toward individuals in attack > scenarios, both an invasion of privacy and a security consideration > for the attack possibilities. If home use is not out-of-scope, you'll > have real issues here and it will be really hard to tackle the > security and privacy concerns. > > The I2NSF user information could be sensitive too - meaning the person > doing provisioning. What protects their account information (I think > you have this covered), you may want to state it for privacy reasons. > > Thanks! > -- > > Best regards, > Kathleen -- Best regards, Kathleen ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
