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

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 16 Oct 2017 08:45:36 -0700

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.

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Oct 2017 14:22:44 -0400

Hi Mirja,

Thanks for your review.  The first seems simple enough, but I'll leave
that to the editors, shepherd and WG.

> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/

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.

> 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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 23 Oct 2017 13:10:11 +0200

Hi Kathleen,

see below.

> Am 16.10.2017 um 20:22 schrieb Kathleen Moriarty <[email-masked]>:
> 
> Hi Mirja,
> 

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.

> This is handled in the drafts that follow, so adding text here

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 23 Oct 2017 16:00:24 +0100

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

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