Subject: [I2nsf] SKKU Comments on Framework Draft

From: John Strassner <[email-masked]>
Date: Sun, 2 Jul 2017 20:50:26 -0700

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 3 Jul 2017 21:54:23 +0000

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-masked]] On Behalf Of John Strassner
Sent: Sunday, July 02, 2017 10:50 PM
To: [email-masked]; John Strassner <[email-masked]>
Subject: [I2nsf] SKKU Comments on Framework Draft

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>

What are the lowest levels of assurance?
<jcs>
Described in section 4.1 of the remote-attestation draft. I changed as follows:

The only

NEW:

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"?

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

OLD: IDR

OLD: PCP

OLD: TRAM

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 3 Jul 2017 15:02:31 -0700

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-masked]>
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.
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, July 02, 2017 10:50 PM
> *To:* [email-masked]; John Strassner <[email-masked]>
> *Subject:* [I2nsf] SKKU Comments on Framework Draft
>
>
>
> 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

-- 
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 3 Jul 2017 22:44:27 +0000

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-masked]]
Sent: Monday, July 03, 2017 5:03 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> 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.

Linda

From: I2nsf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner
Sent: Sunday, July 02, 2017 10:50 PM
To: [email-masked]<mailto:[email-masked]>; John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: [I2nsf] SKKU Comments on Framework Draft

The only

NEW:

OLD: DOTS

OLD: IDR

OLD: PCP

OLD: TRAM

--
regards,
John

--
regards,
John

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 5 Jul 2017 21:00:05 +0000

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-masked]<mailto:[email-masked]>> wrote:

Thanks John.

Thanks,
Linda

From: John Strassner [mailto:[email-masked]]
Sent: Monday, July 03, 2017 5:03 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] SKKU Comments on Framework Draft

regards,
John

Linda

The only

NEW:

OLD: DOTS

OLD: IDR

OLD: PCP

OLD: TRAM

--
regards,
John

--
regards,
John
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
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-masked]
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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Jul 2017 21:19:59 +0000

Diego,

That would be great!

Linda

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Wednesday, July 05, 2017 4:00 PM
To: Linda Dunbar <[email-masked]>
Cc: John Strassner <[email-masked]>; [email-masked]
Subject: Re: [I2nsf] SKKU Comments on Framework Draft

Hi,

Be goode,

Thanks John.

Thanks,
Linda

regards,
John

Linda

The only

NEW:

OLD: DOTS

OLD: IDR

OLD: PCP

OLD: TRAM

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------