Hi, So that implies we use the term “controller”, referring to the terminology to clarify what are the functions of such a controller in the I2NSF remit, without precluding it to support other functions out of the scope of the I2NSF documents. Are we all in agreement on this?
Be goode, On 4 Jul 2017, at 24:44 , Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Thanks John. You are correct that “I2NSF Controller” is really just a component of “Security Controller” or a component of generic “Controller”. Thanks, Linda From: John Strassner [mailto:[email protected]] Sent: Monday, July 03, 2017 5:03 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [I2nsf] SKKU Comments on Framework Draft That is exactly my point. The vast majority of controllers are not limited to performing **just** security functions. I left text in that said "security controller" to elicit more opinions. regards, John On Mon, Jul 3, 2017 at 2:54 PM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: To many people’s mind, a generic “Controller” can include other functions currently not in the scope of the I2NSF charter, like controlling the “routes”, “routing protocols”, “devices”, etc. How to restrict the scope of the “Controller” if we don’t use “I2NSF Controller” in documents? Linda From: I2nsf [mailto:[email protected]<mailto:[email protected]>] On Behalf Of John Strassner Sent: Sunday, July 02, 2017 10:50 PM To: [email protected]<mailto:[email protected]>; John Strassner <[email protected]<mailto:[email protected]>> Subject: [I2nsf] SKKU Comments on Framework Draft Here is my proposed resolution: The following terms need to be unified in the whole text. OLD: I2NSF Controller (or controller) NEW: Security Controller OLD: Customer-Facing Interface NEW: Consumer-Facing Interface <jcs> The terminology document defines "Controller". We want to stay aligned with SACM, and SACM also uses Controller. The term "Security Controller" implies a dedicated function that only does security; such entities are being replaced by "Controllers". I propose to change I2NSF Controller to Controller, and reference the terminology document on first use. </jcs> The following phrase in Section 6.1 is not clear: ... as described in [I-D.pastor-i2nsf-nsf-remote-attestation], with the only possible exception of the application of the lowest levels of assurance, in which case the user MUST be made aware of this circumstance. What are the lowest levels of assurance? <jcs> Described in section 4.1 of the remote-attestation draft. I changed as follows: The only possible exception is when the required level of assurance is lower, (see Section 4.1 of [I-D.pastor-i2nsf-remote-attestation], in which case the user must be made aware of this circumstance. </jcs> In Section 7.1, the following example of ECA policy needs to be corrected by swapping the phrases of Event and Condition because User belongs to Event and Traffic type belongs to Condition in ECA paradigm: OLD: An Event can be "traffic of type X detected" A Condition can be a "user identifier is Z" and/or "traffic from domain-A to domain-B" NEW: An Event can be a "user identifier is Z" A Condition can be "traffic of type X detected" and/or "traffic from domain-A to domain-B" <jcs> I disagree. No action will be taken. An event is defined as a significant occurrence in time. The given event (traffic of type X detected) is a significant occurrence in time (e.g., a packet arrival). It is incorrect to say that just because a user is referenced, it must be an event. Similarly, a condition is defined as something that can be compared with a known value. There is no reason why a user-identifier cannot be compared with a known value. Furthermore, why is a user-identifier a "significant occurrence in time"? Please reread the terminology draft definitions. </jcs> In Section 9.1, attack mitigation needs to be added as follows: o An attack mitigator detects DDoS attacks (e.g., DNS reflection attack and TCP SYNC flood) and Single-packet attacks (e.g., IP sweep, port scanning, ping of death, and oversized ICMP). <jcs> Yes, it could be added, but so could 100 other things. This section is simply trying to explain, at a high conceptual level, different types of flows. Attack mitigation is typically included as part of a higher level package, not as a stand-alone function. Finally, you provided a limited description (which is part of the problem of including it). Hence, no action will be taken. </jcs> Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in Network Event Logging (SYSLOG) <jcs> Syslog was defined as SYStem Log. I have no idea what your expansion is (SINEL?). Rejected. </jcs> OLD: DOTS NEW: DDoS Open Threat Signaling (DOTS) <jcs> fixed in Section 3.2, does not appear here </jcs> OLD: IDR NEW: Inter-Domain Routing (IDR) <jcs> This is in Section 9.2. OLD: PCP NEW: Port Control Protocol (PCP) OLD: TRAM NEW: TURN Revised and Modernized (TRAM) <jcs> OK on the two above </jcs> -- regards, John -- regards, John _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- "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 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
