Subject: Re: [I2nsf] Mirja Kühlewind's Discuss on draft-ietf-i2nsf-framework-08: (with DISCUSS)

From: John Strassner <[email-masked]>
Date: Sun, 12 Nov 2017 07:04:25 -0800

Dear Mirja and Kathleen,

thank you for performing this review and the subsequent discussion.
The first set of issues will be addressed in a subsequent email, which
includes additional comments from Adrian.

The second issue concerning the lack of authentication will be handled
by adding a paragraph to sections 3, as follows:

   In general, all I2NSF interfaces should require at least mutual
   authentication and authorization for their use. Other security and
   privacy considerations are specified in Section 11.

These issues will be addressed in version 9 of this I-D, to be released
on Monday 11/13.

regards,
John

On Mon, Oct 16, 2017 at 11:22 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Hi Mirja,
>
> Thanks for your review.  The first seems simple enough, but I'll leave
> that to the editors, shepherd and WG.
>
> On Mon, Oct 16, 2017 at 11:45 AM, Mirja Kühlewind <[email-masked]>
> wrote:
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-i2nsf-framework-08: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have two points below:
> >
> > 1) The first one should be easy to address:
> > "Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the
> >    Stream Control Transmission Protocol (SCTP) will need to be evaluated
> >    for applicability. "
> > This sentence is not correct; MPTP and SCTP do not provide any redundancy
> > mechanisms; they simply just provide a reliable transport as TCP does.
> > Therefore I would just remove this sentence here.
> >
> > Further, on this paragraph, it is not clear to me why you say that
> reliable
> > transport is needed. Especially for some monitoring purposes, unreliable
> > transport might be acceptable as well. Or do you think that all
> communication
> > for security systems have always to be reliable? I don't think this
> document
> > discusses things in detail enough to make such an assessment.
> >
> > 2) This second is a very high level concern and I'm not sure if balloting
> > discuss on this is the right thing to do but I definitely would like to
> get
> > some feedback from the group to better understand this document before
> > publication:
> >
> > This document seem not very security specific to me. To say this in a
> somehow
> > sloppy way: I have the feeling that if you would just remove the word
> > "security" everywhere in the text, it would still be the same document. I
> > checked the charter and the charter is also not very concrete about what
> to
> > expect, besides motivating the needed interfaces with the need for
> in-network
> > security function. However, if there is nothing security specific about
> this,
> > what's the difference to the usually control plane architecture as
> usually
> > deployed with the use of NETCONF? And I am actually wondering if this is
> the
> > right wg to write such a document.
>
> I think right as you were becoming an AD as this work was in process
> of being chartered, so there may be a gap in knowledge.  This WG is a
> cross area WG between routing and security.  Many of the people in the
> WG are from the routing area.  Since the devices they were most
> concerned in provisioning were security devices (per the customers
> that helped bring the work to the IETF), the IESG decided to put this
> in the Security area.  Yes, the mechanisms are purposefully reusing
> existing technologies to accomplish the tasks, but all of the tasks
> are interacting with security provisioning services or security
> appliances.  An example of a draft that was just adopted is one that
> includes a YANG module to provision IPsec.  The security focus is
> important in that example (as well as others) since mistakes with
> provisioning of IPsec tunnels could have a large impact.  AN advantage
> of having this work as a cross area group in the Security area is that
> it not only caught the attention of the IPSecMe WG, but they had a
> joint interim call to improve the work and the go forward plan will
> involve assistance from people contributing to the IPSecME WG.
>
> I think this one is likely just a gap in background knowledge.
>
> >
> > Further, I would at least have expected that this framework mandates for
> high
> > control plan security given we are talking about the configuration and
> > deployment of security function. However, it does not. It does rarely
> provide
> > any concrete recommendation here, and basically leaves the door open to
> used
> > these interfaces without authentication which I think is not acceptable.
> >
>
> This is handled in the drafts that follow, so adding text here
> shouldn't be a problem.
>
> >
> >
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 12 Nov 2017 07:05:56 -0800

Dear Mirja, Adrial, and Kathleen,

thank you for performing this review, and the discussions that followed.
I hope that the following addresses the issues that you have raised.
This content will be published in version 9 of this I-D, to be released on
Monday 11/13.

POINT #1

<jcs>
DONE
</jcs>

Further, on this paragraph, it is not clear to me why you say that reliable
transport is needed. Especially for some monitoring purposes, unreliable
transport might be acceptable as well. Or do you think that all
communication
for security systems have always to be reliable? I don't think this document
discusses things in detail enough to make such an assessment.
<jcs>
I believe that we need reliable transport for critical management-based
operations, but NOT for other mechanisms (e.g., monitoring). The following
text is proposed:

   Therefore, the transport mechanism used to carry management data and
   information must be secure. It does not have to be a reliable
   transport; rather, a transport-independent reliable messaging
   mechanism is required, where communication can be performed reliably
   (e.g., by establishing end-to-end communication sessions and by
   introducing explicit acknowledgement of messages into the
   communication flow). Latency requirements for control message
   delivery must also be evaluated. Note that monitoring does not
   reliable transport.
</jcs>

POINT 2
2a - Adrian's suggested text is implemented, but all normative language
(in UPPER CASE) is changed to informative language (in lower case)
since we are now using RFC8174 boilerplate.

2b - end of section 4:
"The above threats may be mitigated by requiring the use of an AAA
   framework for all users to access the I2NSF environment. This could
   be further enhanced by requiring attestation to be used to detect
   changes to the I2NSF environment by authorized parties.“
<jcs>
That is the present text; what would you suggest to strengthen it?
</jcs>

2c - sec 6.1:
„ Given the role of the I2NSF
   Controller, a mutual authentication of users and the I2NSF
   Controller may be required.“
Why not „is required“?
<jcs>
DONE
</jcs>

2c - And I’m also uncertain about this part in sec 6.2:
"The network connection between the I2NSF Controller and NSFs can
   rely either on:

   o  Closed environments, where there is only one administrative
      domain.  Less restrictive access control and simpler validation
      can be used inside the domain because of the protected nature of
      a closed environment.“
<jcs>
This text was changed to:

   o  Closed environments, where there is only one administrative
      domain.  Such environments provide a more **isolated**
      environment, but still communicate over the same set of I2NSF
      interfaces present in open environments (see above). Hence, the
      security control and access requirements for closed environments
      are the same as those for open environments.
</jcs>

best regards,
John

On Mon, Oct 23, 2017 at 8:15 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi Adrian,
>
> see below.
>
> > Am 23.10.2017 um 17:00 schrieb Adrian Farrel <[email-masked]>:
> >
> > <hat style="shepherd">
> >
> > Trying to extract actions for the authors from this interesting
> Discussion. I think that the first point is closed with Mirja still
> surprised, but no action needed.
>
> Yes...
>
> > The second point needs reinforcement of the need for strong security in
> the management (not control) plane used in the architecture: in particular,
> that the messages that configure network security functions must,
> themselves, else the security functions are vulnerable and so the whole
> network at risk.
> >
> > Section 11 currently reads...
> >
> > 11.  Security Considerations
> >
> >   NSF control and monitoring demand trustworthy, robust, and fully
> >   secured access.  Therefore, proper secure communication channels
> >   have to be carefully specified for carrying the controlling and
> >   monitoring information between the NSFs and their management
> >   entity or entities. This has been discussed in Section 4.
> >
> >   This framework is intended for enterprise users, with or without
> >   cloud service offerings. Privacy of users should be provided by
> >   using existing standard mechanisms, such as encryption;
> >   anonymization of data should also be done (if possible depending
> >   on the transport used). Such mechanisms require confidentiality
> >   and integrity.
> >
> > ... I suggest that this is enhanced to read...
> >
> > 11.  Security Considerations
> >
> >   The configuration, control, and monitoring of NSFs provide access to
> >   and information about security functions that are critical for
> >   delivering network security and for protecting end-to-end traffic.
> >   Therefore, it is important that the messages that are exchanged
> >   within this architecture utilize a trustworthy, robust, and fully
> >   secure communication channel.  The mechanisms adopted within the
> >   solution space MUST include proper secure communication channels
> >   that are carefully specified for carrying the controlling and
> >   monitoring information between the NSFs and their management entity
> >   or entities. The threats associated with remotely managed NSFs are
> >   discussed in Section 4, and solutions MUST address those concerns.
> >
> >   This framework is intended for enterprise users, with or without
> >   cloud service offerings. Privacy of users should be provided by
> >   using existing standard mechanisms, such as encryption;
> >   anonymization of data should also be done (if possible depending
> >   on the transport used). Such mechanisms require confidentiality
> >   and integrity.
> > END
> >
> Thanks that’s much better from my point of view. Maybe also
> s/Privacy of users should be provided by/Privacy of users MUST be provided
> by/ ?
>
>
> There are a few more cases that could potentially be strengthened as well:
>
> end of section 4:
> "The above threats may be mitigated by requiring the use of an AAA
>    framework for all users to access the I2NSF environment. This could
>    be further enhanced by requiring attestation to be used to detect
>    changes to the I2NSF environment by authorized parties.“
>
>
> sec 6.1:
> „ Given the role of the I2NSF
>    Controller, a mutual authentication of users and the I2NSF
>    Controller may be required.“
> Why not „is required“?
>
> And I’m also uncertain about this part in sec 6.2:
> "The network connection between the I2NSF Controller and NSFs can
>    rely either on:
>
>    o  Closed environments, where there is only one administrative
>       domain.  Less restrictive access control and simpler validation
>       can be used inside the domain because of the protected nature of
>       a closed environment.“
>
> Maybe you can have another look at these cases? Also not sure I’ve caught
> very just now…
>
> Thanks,
> Mirja
>
>
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> >> Sent: 23 October 2017 12:10
> >> To: Kathleen Moriarty
> >> Cc: [email-masked]; [email-masked]; Yoav Nir; The
> IESG; i2nsf-
> >> [email-masked]; Adrian Farrel
> >> Subject: Re: Mirja Kühlewind's Discuss on
> draft-ietf-i2nsf-framework-08: (with
> >> DISCUSS)
> >>
> >> Hi Kathleen,
> >>
> >> see below.
> >>
> >>> Am 16.10.2017 um 20:22 schrieb Kathleen Moriarty
> >> <[email-masked]>:
> >>>
> >>> Hi Mirja,
> >>>
> >>> On Mon, Oct 16, 2017 at 11:45 AM, Mirja Kühlewind <[email-masked]
> >
> >> wrote:
> >>>> discuss on this is the right thing to do but I definitely would like
> to get
> >>>> checked the charter and the charter is also not very concrete about
> what to
> >>>> expect, besides motivating the needed interfaces with the need for in-
> >> network
> >>>> security function. However, if there is nothing security specific
> about this,
> >>>> deployed with the use of NETCONF? And I am actually wondering if this
> is the
> >> I was just step up when this was charter but I got the background that
> this is
> >> somewhere between SEC and RTG. I was still very much surprised how few
> >> security focus there is in this document.
> >>
> >>>
> >>>>
> >>>> Further, I would at least have expected that this framework mandates
> for high
> >> I think making some stronger recommendations about how to secure the
> control
> >> plan communication for security-relevant configurations would address my
> >> discuss sufficiently to move to ‚No Objection‘.
> >>
> >> Thanks,
> >> Mirja
> >>
> >>
> >>
> >>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Best regards,
> >>> Kathleen
> >>>
> >
>

-- 
regards,
John

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 14 Nov 2017 14:42:19 +0800

Hi John,

thanks for your edits! They look good to me. Sorry for my late reply but I’ve seen you have find a resolution for your one remaining question below.

Mirja

> Am 12.11.2017 um 23:05 schrieb John Strassner <[email-masked]>:
> 
> transport might be acceptable as well. Or do you think that all communication
> On Mon, Oct 23, 2017 at 8:15 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> Hi Adrian,
> 
> see below.
> 
> > Trying to extract actions for the authors from this interesting Discussion. I think that the first point is closed with Mirja still surprised, but no action needed.
> 
> Yes...
> 
> > The second point needs reinforcement of the need for strong security in the management (not control) plane used in the architecture: in particular, that the messages that configure network security functions must, themselves, else the security functions are vulnerable and so the whole network at risk.
> >
> s/Privacy of users should be provided by/Privacy of users MUST be provided by/ ?
> 
> 
> Maybe you can have another look at these cases? Also not sure I’ve caught very just now…
> 
> Thanks,
> Mirja
> 
> 
> >
> >
> >
> >
> >> Cc: [email-masked]; [email-masked]; Yoav Nir; The IESG; i2nsf-
> >> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-i2nsf-framework-08: (with
> >> DISCUSS)
> >>
> >> Hi Kathleen,
> >>
> >> see below.
> >>
> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>> transport might be acceptable as well. Or do you think that all communication
> >>>> discuss on this is the right thing to do but I definitely would like to get
> >>>> This document seem not very security specific to me. To say this in a somehow
> >>>> checked the charter and the charter is also not very concrete about what to
> >>>> security function. However, if there is nothing security specific about this,
> >>>> what's the difference to the usually control plane architecture as usually
> >>>> deployed with the use of NETCONF? And I am actually wondering if this is the
> >> I was just step up when this was charter but I got the background that this is
> >>>> Further, I would at least have expected that this framework mandates for high
> >>>> deployment of security function. However, it does not. It does rarely provide
> >> I think making some stronger recommendations about how to secure the control