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]> Cc: [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] https://www.ietf.org/mailman/listinfo/i2nsf
