Hi Sue and co-authors, Thanks for your warm-welcoming me as a coauthor :-) I will give you my comments in a couple of days.
Sue, Do you want me to prepare a new use-case (or implementation) draft with the previous sections 4.4 and 4.5 in Version 04 below in addition to our I2NSF Problem Statement and Use cases draft? Version 04 (https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and- use-cases-04): 4.4. I2NSF Preventing Distributed DoS in Overlay Networks 4.5. Software-Defined Networks Or do you want me to revise a SDN Network section for Version 06 for WGLC? Thanks. Paul On Tue, Dec 6, 2016 at 11:13 PM, Susan Hares <[email protected]> wrote: > Rakesh: > > > > Are you taking the editing token to resolve Christian’s comments from > section 2, 3.4, 4.4, and 4.5? I agree with Christians comments on 2, 3.4, > 4.4 and 4.5. I would like to see Paul create a use case document with 4.4 > and 4.5’s original text. > > > > Sue Hares > > > > *From:* I2nsf [mailto:[email protected]] *On Behalf Of * > [email protected] > *Sent:* Tuesday, December 6, 2016 3:37 AM > *To:* Rakesh Kumar; Linda Dunbar; Susan Hares; 'Diego R. Lopez' > *Cc:* [email protected]; 'Myo Zarny' > *Subject:* Re: [I2nsf] Suggested updaste from Paul Jeong > > > > Dear all, > > > > Thanks to Rakesh for posting this new version. I have several comments but > let me first reiterate I’m fine with welcoming Paul as a co-author. > > > > 1. Section 2: > > · I fail to understand the need for the discussion about > centralized and distributed functions, besides the fact the proposed text > does not belong to a terminology function per se. I think this primarily > relates to (service provider-specific) design considerations, as a function > of the nature of the service to be delivered, how a security policy is > defined/enforced, etc. If there is consensus to keep this text in the > document, I think it should rather belong to some kind of “deployment > considerations” section. > > · I don’t quite understand the rationale either: why large > traffic should rather encourage a centralized design instead of a > distributed design? > > · I don’t understand what “consistent mechanism” means – the same > protocol regardless of the nature of the security policy to be enforced, > and the nature/location of the NSFs? Else? > > · Finally, I would avoid qualitative appreciations about the > potential complexity of such and such design or the simplification brought > by another design: I don’t think this makes sense, especially because this > is so dependent on the nature of the security policy to be enforced. So, I > guess I would delete the whole paragraph. > > 2. Section 3.4: > > · I have a concern with this section too, which looks out of the > scope of the draft. I also fail to understand the key message of this > section: that SDN techniques raise additional security issues and may > distort how “legacy” security policies are enforced? If so, I think I would > elaborate in terms of (SDN-inferred) specific requirements, e.g., make sure > a controller is entitled to access/configure/invoke participating NSFs, > make sure NSFs are entitled to talk to a SDN controller (to send a > notification that may affect decision-making process handled by the SDN > computation logic), etc. > > · Several typos in the paragraph – here’s a rewording proposal: > “Software-Defined Networks (SDN) have changed the landscape of data center > designs by introducing overlay networks deployed over ToR switches that > connect to a hypervisor. SDN techniques are meant to improve the > flexibility of workload management without affecting applications and how > they work. Workload can thus be easily and seamlessly managed across > private and public clouds. SDN techniques optimize resource usage and are > now being deployed in various networking environments, besides cloud > infrastructures. Yet, such SDN-inferred agility may raise specific security > issues: a security admin must for example make sure that any security > policy can be enforced regardless of the location of the involved NSFs, > thereby raising concerns about the ability of making sure the SDN > computation logic is entitled to send security policy-provisioning > information to the participating NSFs, for example. NSF migration to a > public cloud infrastructure may also raise additional complexity.” > > 3. Section 4.4: > > · I would rephrase part of the new text. For example: > > o Similarly, a network could be exposed to malware attacks and become > an attack vector to jeopardize the operation of other networks, by means of > remote commands for example. > > o Voice over packet networks (VoIP/VoLTE) are also exposed to such > attacks. (I would delete the last part of the sentence which is a kind of > tautology that is not specific to VoIP-targeted networks). > > o In order for organizations to better secure their networks against > this kind of attacks, the I2NSF framework should provide client-side > interfaces that are use case-independent and technology-agnostic. For > example, such I2NSF interface could be used to provision security policy > configuration information that looks for specific malware signatures. > > 4. Section 4.5: > > · s/security/security (in the title) > > · I also have a few rewording proposals: > > o Organizations are not only supposed to protect their networks > against attacks, but they should also adhere to various industry > regulations: any organization that falls under a specific regulation like > PCI-DSS (payment industry) or HIPPA (healthcare industry) must be able to > isolate various kinds of traffic. They must also show records of their > security policies whenever audited. > > o s/violations/violation > > o this information can be provided in the event of an audit as a proof > that traffic is isolated between specific endpoints, in full compliance > with the required regulation. > > > > Cheers, > > > > Christian. > > > > *De :* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Envoyé :* lundi 5 décembre 2016 23:08 > *À :* Linda Dunbar; Susan Hares; 'Diego R. Lopez' > *Cc :* 'Myo Zarny'; JACQUENET Christian IMT/OLN; [email protected] > *Objet :* Re: Suggested updaste from Paul Jeong > > > > HI Linda, > > > > I just uploaded the version -05 with the updates listed below in this > thread. > > > > Thanks > > Rakesh > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 1:44 PM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh, > > > > I would think uploading soon (ASAP), so we can get over the WGLC by end of > the year. > > > > Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年12月5日 15:41 > *To:* Linda Dunbar <[email protected]>; Susan Hares <[email protected]>; > 'Diego R. Lopez' <[email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected] > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Linda, > > > > Let me know when do you want me to upload this version. > > > > Thanks > > Rakesh > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 11:37 AM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Is there anyone objecting adding Paul as co-author? > > If not, please go ahead adding his name and upload the draft. So that we > can start the WGLC. > > > > Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年12月5日 13:19 > *To:* Linda Dunbar <[email protected]>; Susan Hares <[email protected]>; > 'Diego R. Lopez' <[email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected]; Rakesh Kumar <[email protected]> > *Subject:* Re: Suggested updaste from Paul Jeong > > > > HI Linda, > > > > I think, we should add Paul’s name. > > We can put his name as contributing author or as a co-author as others > feel appropriate. > > > > Thanks > > Rakesh > > > > *From: *Linda Dunbar <[email protected]> > *Date: *Monday, December 5, 2016 at 10:03 AM > *To: *Rakesh Kumar <[email protected]>, Susan Hares <[email protected]>, > "'Diego R. Lopez'" <[email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Sue, Rakesh, Diego, et al, > > > > Do you think the version updated by Rakesh is good enough for WGLC? > > We are hoping to get the process started & finished by 2017. > > > > Thanks, Linda > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* 2016年11月30日 13:59 > *To:* Susan Hares <[email protected]>; 'Diego R. Lopez' < > [email protected]> > *Cc:* 'Myo Zarny' <[email protected]>; [email protected]; > [email protected]; Linda Dunbar <[email protected]>; > Rakesh Kumar <[email protected]> > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Susan and all, > > > > I took as much as possible from Pau’l contributions and added one section > on “Regulatory and compliance” which I wanted to add. > > > > Please find the attached “xml” document. I added following to the document > sent by Diego. I don’t know how to diff between Diego’s version and mine. > > > > 1. Section 3.1.1, Added a new item “*Centralized or Distributed > security functions*:” > > 2. Section 3.4, Added a new section *“Software-Defined Networks”* > > 3. Section 4.4, Added section “*Preventing Distributed DoS, Malware > and Botnet attacks*” > > 4. Section 4.5, Added section “*Regulatory and compliance security > policies*” > > 5. In my opinion, we should add Paul’s name back. I have not done in > the attached document but I feel we should. > > > > Thanks > > Rakesh > > *From: *Susan Hares <[email protected]> > *Date: *Tuesday, November 29, 2016 at 5:49 PM > *To: *Rakesh Kumar <[email protected]>, "'Diego R. Lopez'" < > [email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh: > > > > Thank you for letting me know. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, November 29, 2016 11:42 AM > *To:* Susan Hares; 'Diego R. Lopez' > *Cc:* 'Myo Zarny'; [email protected]; [email protected]; > 'Linda Dunbar' > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Susan, > > > > I will send you the changes in next couple of days. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Monday, November 28, 2016 at 1:28 AM > *To: *"'Diego R. Lopez'" <[email protected]>, Rakesh Kumar < > [email protected]> > *Cc: *'Myo Zarny' <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Diego and Rakesh: > > > Let me know who has the token. If Rakesh wants to send changes, I will > update to this work. > > > > Wi will unavailable via email during normal hours (8am-5pm ET) due to jury > duty in the US. I will be working 5pm (2pm PT) to 12pm ET, and 6-7 ET > (am). > > > > Sue > > > > *From:* Diego R. Lopez [mailto:[email protected] > <[email protected]>] > *Sent:* Sunday, November 27, 2016 5:22 PM > *To:* Rakesh Kumar > *Cc:* Susan Hares; Myo Zarny; [email protected]; > [email protected]; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Rakesh, > > > > Good! I am attaching the latest version Sue shared with us. > > > > Be goode, > > > > > > On 27 Nov 2016, at 21:41 , Rakesh Kumar <[email protected]> wrote: > > > > I will do it. > > > > Please send me the latest copy otherwise I will take the latest version > from IETF website. > > > > Regards > > Rakesh > > Sent from my iPhone > > > On Nov 27, 2016, at 12:12 PM, Diego R. Lopez <[email protected]> > wrote: > > Hi Sue, > > > > Trying to sort out a token deadlock we seemed to have… > > > > Be goode, > > > > On 26 Nov 2016, at 22:45 , Susan Hares <[email protected]> wrote: > > > > Rakesh, Diego, Myo, and Christian: > > > > Any updates on this document? If you want me to edit in the changes, > please let me know. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected] <[email protected]>] > *Sent:* Wednesday, November 23, 2016 1:45 PM > *To:* Diego R. Lopez > *Cc:* Susan Hares; Myo Zarny; [email protected]; chris > [email protected]; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Diego, > > > > I wanted to take a stab at Paul's comment but it looks like you are > planning for the same. I will let you handle in that case. > > > > I wanted to add use-case listing how I2NSF would be useful for regulatory > and compliance policy. > > > > Let me know if anything you would like me to do. I am fine with you taking > the lead. > > > > Regards > > Rakesh > > > > Sent from my iPhone > > > > On Nov 22, 2016, at 6:21 AM, Diego R. Lopez <[email protected]> > wrote: > > > > Hi Rakesh, > > > > I am happy if you take the editorial token before I do. Just tell me when > you are ready. I was thinking to deal with most of Paul's contribution as > an annex exemplifying an implementation pattern using SDN, pointing to the > annex from the main text. > > > > What I am not sure is about including anything about regulation in an > RFC-to-be. Regulation is outside of IETF’s scope… > > > > Be goode, > > > > On 21 Nov 2016, at 21:44 , Rakesh Kumar <[email protected]> wrote: > > > > Hi Susan & others, > > > > I have already given suggestions regarding how to incorporate changes from > Paul’s contributions in this thread. > > Basically it’s a mix of problem space and use-case as mentioned earlier. > > > > I can make the changes if we want to incorporate Paul’s suggestions based > on my thinking. Let me know. I can also add a use-case for regulatory and > compliance. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Sunday, November 20, 2016 at 1:59 PM > *To: *'Myo Zarny' <[email protected]>, Rakesh Kumar <[email protected] > > > *Cc: *"[email protected]" <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]>, 'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Myo, Deigo, Rakesh, and Christian: > > > > Thanks for the input. I’ve removed sections 4.4 and 4.5 to a > implementation draft. Do you want me to remove Paul as a co-author at > this point or leave him on? I’ve edited a version 5. > > > > Diego – do you have the editing token at this point? > > > > Sue > > > > *From:* Myo Zarny [mailto:[email protected] <[email protected]>] > *Sent:* Saturday, November 19, 2016 3:36 PM > *To:* Rakesh Kumar > *Cc:* Susan Hares; [email protected]; Diego R. Lopez; christian.jacquenet@ > orange.com; Linda Dunbar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hello Sue and team, > > > > My initial reaction was pretty much the same as Rakesh's. Sections 4.4 and > 4.5 by themselves can be an implementation draft. Now, SDN implementations > could certainly benefit from I2NSF, and the draft should contain a section > on SDN. Such a section would complement NFV use cases. > > > > The text as it stands now--sections 4.5.1 to 4.5.3--describes how SDN > could be used to solve certain network security use cases but doesn't > mention not where/how I2NSF fits in. Let's update the text to illustrate > I2NSF's value to make it relevant to the purpose of the draft. > > > > Diego, thanks for volunteering to make editorial changes. > > > > Cheers, > > > > > > On Sun, Nov 13, 2016 at 6:58 PM, Rakesh Kumar <[email protected]> wrote: > > Hi Sue, > > > > On a different topic; you asked me about if there is anything else we need > to take fromhttps://tools.ietf.org/html/draft-kumar-i2nsf- > controller-use-cases-00 into consideration. > > After looking at it again, I see you did a great job in incorporating most > of the stuff. The only small thing left out is “Regulatory and Compliance:” > related use-case. > > > > Are you open to adding one use-case regarding this ““Regulatory and > Compliance”? I will let you decide on the text what you want to put. I am > also fine if you are not comfortable with this. > > > > Thanks & Regards, > > Rakesh > > > > > > *From: *Rakesh Kumar <[email protected]> > *Date: *Sunday, November 13, 2016 at 1:46 PM > > > *To: *Susan Hares <[email protected]>, "[email protected]" <[email protected]>, > 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]>, Rakesh Kumar < > [email protected]> > *Subject: *Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > Sure, let us meet. > > > > You are absolutely right. Paul pointed out a good use-case of VoIP/VoLTE > and how I2NSF can help. I forgot to mention this earlier; my apologies for > this. > > > > Thanks & Regards, > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Sunday, November 13, 2016 at 12:19 PM > *To: *Rakesh Kumar <[email protected]>, "[email protected]" < > [email protected]>, 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]> > *Subject: *RE: Suggested updaste from Paul Jeong > > > > Rakesh: > > > > Let’s talk in person today. Could we chat right after I2NSF? I think > Paul’s sections actually talked about a user perspective. > > > > Sue > > > > *From:* Rakesh Kumar [mailto:[email protected]] > *Sent:* Sunday, November 13, 2016 6:30 AM > *To:* Susan Hares; [email protected]; 'Myo Zarny'; 'Diego R. Lopez'; > [email protected] > *Cc:* 'Linda Dunbar'; Rakesh Kumar > *Subject:* Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > After having a talk with you today, I thought about it some more about > this. I feel, section 4.0 describes the various use-cases (from security > admin/user perspective). The use-case don’t care about a specific > implementation (SDN/non-SDN/Centralized/distributed) approach; rather it > shouldn’t be a matter of concern for the security admin as long its > use-case can be implemented. > > > > If we want to preserve the new contents, I was wondering whether you would > be open to moving around the new additions. Here are my thoughts, let me > what you think. > > > > 1. Move section (“Software-Defined Networks”) under section 3.0 as > a problem, SDN is making security provisioning a complex task. Basically > security policy in the SDN networks cannot deployed the same way as in > legacy networks. > > 2. Combine sections (“Centralized Firewall System), section > (“Centralized DDoS-attack Mitigation System”) and section (“Centralized > VoIP/VoLTE Security System) into two sub-sections under section 3.0 as a > problem, the NSF implementation pose a challenge in deploying security > policies since security admin need to be aware whether a specific NSF is > centralized or distributed in order for security policy to be effectively > enforced. > > > > The I2NSF client interface would definitely address both of the above > concerns/problems. > > > > What do you think? > > > > Thanks > > Rakesh > > > > *From: *Rakesh Kumar <[email protected]> > *Date: *Saturday, November 12, 2016 at 10:49 PM > *To: *Susan Hares <[email protected]>, "[email protected]" <[email protected]>, > 'Myo Zarny' <[email protected]>, "'Diego R. Lopez'" < > [email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]>, Rakesh Kumar < > [email protected]> > *Subject: *Re: Suggested updaste from Paul Jeong > > > > Hi Sue, > > > > Thanks for sending the changes. > > > > I looked at the contents in section 4.5 (it looks to me from the diffs > that this has been added). In my opinion, SDN is just a way to create > orchestrate network path for application hosting and of course connecting > these application to the eco-system. This is a means to solve a problem > where undelay network does not provide this flexibility or hard to achieve. > > Having said, I don’t think this belongs to problem and use-case draft > since as far as I know the purpose of this draft is to highlight problem > and use-cases in the security area, irrespective of how the networks are > designed. All I am trying to say is that this draft should care about > solutions (SDN/non-SDN/Legacy/Distributed/Centralized). This could go in > some other draft (may be NSF-facing interface). > > > > It is possible that I am not reading it properly but this is how I see it. > I am open to discussions. > > > > Thanks > > Rakesh > > > > *From: *Susan Hares <[email protected]> > *Date: *Saturday, November 12, 2016 at 2:08 PM > *To: *"[email protected]" <[email protected]>, 'Myo Zarny' < > [email protected]>, "'Diego R. Lopez'" <[email protected]>, > Rakesh Kumar <[email protected]>, "[email protected]" < > [email protected]> > *Cc: *'Linda Dunbar' <[email protected]> > *Subject: *Suggested updaste from Paul Jeong > > > > Myo, Diego, Rakesh, and Christian: > > > > I suggest that we include Paul’s addition in section 4.4 and include Paul > on the author list. Please provide me feedback on this change. Could you > review the text and answer the following: > > > > a) Do you think the text in section 4.4 makes sense to add, > > b) Do you thinking adding Paul as a co-author makes sense, > > c) Do you see any editorial changes in Paul’s section 4.4? > > > > Sue Hares > > > > > > -- > > Regards, > Myo > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
