Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

I am attaching the latest draft which I could not upload.

Thanks
Rakesh

From: I2nsf > on behalf 
of Rakesh Kumar >
Date: Monday, July 3, 2017 at 5:46 PM
To: "Mr. Jaehoon Paul Jeong" 
>
Cc: "i2nsf@ietf.org" 
>, 
"internet-dra...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi,

I did not realize that time has passed for IETF upload. I think it was end of 
business day PST but it looks like UTC :-(.

I will upload once it opens.

Thanks
Rakesh


From: I2nsf > on behalf 
of Rakesh Kumar >
Date: Monday, July 3, 2017 at 3:09 PM
To: "Mr. Jaehoon Paul Jeong" 
>
Cc: "i2nsf@ietf.org" 
>, 
"internet-dra...@ietf.org" 
>, 
"i-d-annou...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar >
Cc: "internet-dra...@ietf.org" 
>, 
"i2nsf@ietf.org" 
>, 
"i-d-annou...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org" 
 on behalf of 
internet-dra...@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

Hi,

I did not realize that time has passed for IETF upload. I think it was end of 
business day PST but it looks like UTC :-(.

I will upload once it opens.

Thanks
Rakesh


From: I2nsf > on behalf 
of Rakesh Kumar >
Date: Monday, July 3, 2017 at 3:09 PM
To: "Mr. Jaehoon Paul Jeong" 
>
Cc: "i2nsf@ietf.org" 
>, 
"internet-dra...@ietf.org" 
>, 
"i-d-annou...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar >
Cc: "internet-dra...@ietf.org" 
>, 
"i2nsf@ietf.org" 
>, 
"i-d-annou...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org" 
 on behalf of 
internet-dra...@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] SKKU Comments on Framework Draft

[Linda Dunbar]

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

[I2nsf] I-D Action: draft-ietf-i2nsf-terminology-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions of the 
IETF.

Title   : Interface to Network Security Functions (I2NSF) 
Terminology
Authors : Susan Hares
  John Strassner
  Diego R. Lopez
  Liang Xia
  Henk Birkholz
Filename: draft-ietf-i2nsf-terminology-04.txt
Pages   : 13
Date: 2017-07-03

Abstract:
   This document defines a set of terms that are used for the Interface
   to Network Security Functions (I2NSF) effort.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-terminology/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-terminology-04
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-terminology-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-terminology-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar >
Cc: "internet-dra...@ietf.org" 
>, 
"i2nsf@ietf.org" 
>, 
"i-d-annou...@ietf.org" 
>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org" 
 on behalf of 
internet-dra...@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Mr. Jaehoon Paul Jeong]

Hi Rakesh,
when you will post your updated  information model later, I will update our
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 님이 작성:

Hi,

I updated number of sections based on past feedback and added/updated few
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of internet-dra...@ietf.org" <
i2nsf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Interface to Network Security Functions
of the IETF.
>
>Title   : Requirements for Client-Facing Interface to
Security Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-
facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-
facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-
client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-
facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of
submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] SKKU Comments on Framework Draft

[John Strassner]

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

[Linda Dunbar]

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] I-D Action: draft-xibassnez-i2nsf-capability-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions of the 
IETF.

Title   : Information Model of NSFs Capabilities
Authors : Liang Xia
  John Strassner
  Cataldo Basile
  Diego R. Lopez
Filename: draft-xibassnez-i2nsf-capability-02.txt
Pages   : 57
Date: 2017-07-03

Abstract:
   This document defines the concept of an NSF (Network Security
   Function) Capability, as well as its information model. Capabilities
   are a set of features that are available from a managed entity, and
   are represented as data that unambiguously characterizes an NSF.
   Capabilities enable management entities to determine the set offer
   features from available NSFs that will be used, and simplify the
   management of NSFs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-xibassnez-i2nsf-capability-02
https://datatracker.ietf.org/doc/html/draft-xibassnez-i2nsf-capability-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-xibassnez-i2nsf-capability-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf