Re: [I2nsf] SKKU Comments on Framework Draft
Diego, That would be great! Linda From: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] Sent: Wednesday, July 05, 2017 4:00 PM To: Linda Dunbar Cc: John Strassner ; i2nsf@ietf.org Subject: Re: [I2nsf] SKKU Comments on Framework Draft 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 mailto:linda.dun...@huawei.com>> 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:straz...@gmail.com] Sent: Monday, July 03, 2017 5:03 PM To: Linda Dunbar mailto:linda.dun...@huawei.com>> Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org> 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 mailto:linda.dun...@huawei.com>> 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:i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>] On Behalf Of John Strassner Sent: Sunday, July 02, 2017 10:50 PM To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; John Strassner mailto:straz...@gmail.com>> 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 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. 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? 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. 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" 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. 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). 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. Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in
Re: [I2nsf] SKKU Comments on Framework Draft
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 mailto:linda.dun...@huawei.com>> 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:straz...@gmail.com] Sent: Monday, July 03, 2017 5:03 PM To: Linda Dunbar mailto:linda.dun...@huawei.com>> Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org> 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 mailto:linda.dun...@huawei.com>> 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:i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>] On Behalf Of John Strassner Sent: Sunday, July 02, 2017 10:50 PM To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; John Strassner mailto:straz...@gmail.com>> 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 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. 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? 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. 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" 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. 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). 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. Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in Network Event Logging (SYSLOG) Syslog was defined as SYStem Log. I have no idea what your expansion is (SINEL?). Rejected. OLD: DOTS NEW: DDoS Open Threat Signaling (DOTS) fixed in Section 3.2, does not appear here OLD: IDR NEW: Inter-Do
Re: [I2nsf] SKKU Comments on Framework Draft
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:straz...@gmail.com] Sent: Monday, July 03, 2017 5:03 PM To: Linda Dunbar Cc: i2nsf@ietf.org 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 mailto:linda.dun...@huawei.com>> 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:i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>] On Behalf Of John Strassner Sent: Sunday, July 02, 2017 10:50 PM To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; John Strassner mailto:straz...@gmail.com>> 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 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. 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? 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. 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" 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. 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). 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. Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in Network Event Logging (SYSLOG) Syslog was defined as SYStem Log. I have no idea what your expansion is (SINEL?). Rejected. OLD: DOTS NEW: DDoS Open Threat Signaling (DOTS) fixed in Section 3.2, does not appear here OLD: IDR NEW: Inter-Domain Routing (IDR) This is in Section 9.2. OLD: PCP NEW: Port Control Protocol (PCP) OLD: TRAM NEW: TURN Revised and Modernized (TRAM) OK on the two above -- regards, John -- regards, John ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
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 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:i2nsf-boun...@ietf.org] *On Behalf Of *John > Strassner > *Sent:* Sunday, July 02, 2017 10:50 PM > *To:* i2nsf@ietf.org; John Strassner > *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 > > > > 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. > > > > > > 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? > > > > 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. > > > > > > 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" > > > > 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. > > > > > > 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). > > > > 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. > > > > > > Some acronyms need to be expanded: > OLD: SYSLOG > NEW: Security Issues in Network Event Logging (SYSLOG) > > > > Syslog was defined as SYStem Log. I have no idea what your expansion is > (SINEL?). > > Rejected. > > > > OLD: DOTS > NEW: DDoS Open Threat Signaling (DOTS) > > > fixed in Section 3.2, does not appear here > > > > > OLD: IDR > NEW: Inter-Domain Routing (IDR) > > > > This is in Section 9.2. > > OLD: PCP > NEW: Port Control Protocol (PCP) > > OLD: TRAM > NEW: TURN Revised and Modernized (TRAM) > > > OK on the two above > > > > -- > > regards, > > John > -- regards, John ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] SKKU Comments on Framework Draft
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:i2nsf-boun...@ietf.org] On Behalf Of John Strassner Sent: Sunday, July 02, 2017 10:50 PM To: i2nsf@ietf.org; John Strassner 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 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. 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? 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. 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" 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. 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). 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. Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in Network Event Logging (SYSLOG) Syslog was defined as SYStem Log. I have no idea what your expansion is (SINEL?). Rejected. OLD: DOTS NEW: DDoS Open Threat Signaling (DOTS) fixed in Section 3.2, does not appear here OLD: IDR NEW: Inter-Domain Routing (IDR) This is in Section 9.2. OLD: PCP NEW: Port Control Protocol (PCP) OLD: TRAM NEW: TURN Revised and Modernized (TRAM) OK on the two above -- regards, John ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[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 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. 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? 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. 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" 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. 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). 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. Some acronyms need to be expanded: OLD: SYSLOG NEW: Security Issues in Network Event Logging (SYSLOG) Syslog was defined as SYStem Log. I have no idea what your expansion is (SINEL?). Rejected. OLD: DOTS NEW: DDoS Open Threat Signaling (DOTS) fixed in Section 3.2, does not appear here OLD: IDR NEW: Inter-Domain Routing (IDR) This is in Section 9.2. OLD: PCP NEW: Port Control Protocol (PCP) OLD: TRAM NEW: TURN Revised and Modernized (TRAM) OK on the two above -- regards, John ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
