Re: [Teas] Roman Danyliw's Discuss on draft-ietf-teas-ietf-network-slices-23: (with DISCUSS and COMMENT)

[Adrian Farrel <[e-mail]>]

Hi Roman,

Nice to have your review comments.

I'll reply in haste in the hope that you can see and digest my reply before the telechat.

> DISCUSS:
>
> I appreciate that this document is not a protocol specification, but a few
> basic security principles should be cleaned up in an abstract way in Section 10.
>
> -- The need for a strong authentication model is noted.  However, this would
>    need to be paired with an authorization framework too.

I think I understand what an authorization framework is: it is a mechanism by which one party may grant another party access to its protected resources. Right?

How might this apply in this case?

An application (or more likely a tool used by a customer) makes a request for a service. That request is directed to a Network Slice Controller owned/operated by the network operator. Clearly the user must be authenticated as it makes the requests. Perhaps in, this sense, the customer must also be authorised to make those requests. Is that what you mean?

The NSC goes on to orchestrate the network and assign resources to the slice (gross simplification), but since the NSC is part of the operator's network, presumably authorization is not needed (although their may well be a load of policy going on).

But this paragraph talks about "NSC authentication" which (I think) simply means, "Is the box sending the network control messages really the operator's NSC?" I think that is truly authentication, and I doubt that different NSCs will exist with different permissions to do stuff.

> -- Data integrity is described as follows:
>
>   Data Integrity of an IETF Network Slice:  A customer wanting to
>   secure their data and keep it private will be responsible for
>   applying appropriate security measures to their traffic and not
>   depending on the network operator that provides the IETF Network
>   Slice.
>    ...
>   It is expected that for data integrity, a customer is
>   responsible for end-to-end encryption of its own traffic.
>
> It isn’t clear to me what security property is being referenced.  The bullet is
> named “data integrity” but the explanation opens with a discussion on the
> keeping data private which is typically framed as confidentiality.

Yeah, perhaps the text is sloppy in trying to bundle together freedom from viewing and protection against tampering.
Maybe the paragraph could be "Data Privacy and Integrity...." and no other change needed?

> Is “end-to-end encryption” the mechanism to provide integrity?

Yes and no!
Where is the "end"?
Certainly host-to-host encryption would do the job.
But so would (e.g.) CE-to-CE encryption.
Hence, "it is the customer's responsibility."

> COMMENT:
>
> I share the concerns raised in the IESG discussion on how the "_IETF_" modifier
> to network slices could cause issues.

Proposal for a solution? You may have noticed that the WG is vexed by not being able to find a better approach.

> ** Section 4.
>   IETF Network Slices are created to meet specific requirements,
>   typically expressed as bandwidth, latency, latency variation, and
>   other desired or required characteristics.
>
> Given that Section 5.1.* mentions security properties as a characteristic of a
> slice, should security be mentioned here?

Hmmm, nope!
You have to get into the difference between an SLO (measurable, must be met to the level specified) and an SLE ("hey guys, would be cool if you did this, but who knows if you really did it").
5.1 mentions security only in 5.1.2.1 on SLEs. Expressing a desire for security in a slice is not a core requirement, and calling it out as such in section 4 would be misleading.

> ** Section 6.2 and 6.3.  This is not my area so I had trouble understanding the
> framing suggested in this section.
>
> -- I was under the impression that this text would describe how to manifest
>  _IETF_ network slices using _IETF_ technology.  The text says “There are
>  several IETF-defined mechanisms for expressing the need for a desired logical
>  network.”  However, all of these examples seem hypothetical – NETCONF/RESTCONF
>  are cited but there are no associated models; openconfig-rtgwg-gnmi-spec is an
>  expired, un-adopted document whose details don’t seem to provide a means to
>  express “connectivity intents” (and also not an IETF-defined mechanism); and
>  PCEP is tangible, but I didn’t follow how the TLVs were supposed to be reused
>  in the network slice interface?

No, this document should not (must not) say how to manifest network slices using UETF technology. It gives a common framework for doing so, but is supposed to steer clear of specific protocol solutions (which are legion).

As such, and as Editor, I should have been glad to drop the examples, although once the door has been opened with "There are several..." it seems incumbent on the document to give examples.

*I* would be happy with 
OLD
   There are several IETF-defined mechanisms for expressing the need for
   a desired logical network.  The IETF Network Slice Service Interface
   carries data either in a protocol-defined format, or in a formalism
   associated with a modeling language.

   For instance:

   *  The Path Computation Element (PCE) Communication Protocol (PCEP)
      [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE
      [RFC4208] use a TLV-based binary encoding to transmit data.

   *  The Network Configuration Protocol (NETCONF) [RFC6241] and
      RESTCONF Protocol [RFC8040] use XML and JSON encoding.

   *  gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
      programmable interface.  ProtoBufs can be used to model gRPC and
      GNMI data.

   *  For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to
      model configuration and other data for NETCONF, RESTCONF, and
      GNMI, among others.

   While several generic formats and data models for specific purposes
   exist, it is expected that IETF Network Slice management may require
   enhancement or augmentation of existing data models.  Further, it is
   possible that mechanisms will be needed to determine the feasibility
   of service requests before they are actually made.
NEW
   The IETF Network Slice Service Interface
   carries data either in a protocol-defined format, or in a formalism
   associated with a modeling language.

   While several generic formats and data models for specific purposes
   exist, it is expected that IETF Network Slice management may require
   enhancement or augmentation of existing data models.  Further, it is
   possible that mechanisms will be needed to determine the feasibility
   of service requests before they are actually made.
END

But I cannot speak for whether the WG would be happy with such a change. I think we ended up with these examples because people felt it important to include them. Before I wake the WG up, can you say how strongly you feel about this?

> -- How are these technologies any different than provisioning a network that
>  isn’t a slice?  Where are the “slice-specific” requirements and needs?

This text is not about provisioning a slice in its entirety, but commentary on the building blocks (perhaps see Figure 3?).
The final paragraph suggests additional work may be needed.
Later sections may explain in more detail the specific requirements and operational steps.

> -- What makes this described architecture different than a generic SDN/NVF
> architecture?

Well, I think this shows up in the later subsections of Section 6 and is the essence of Section 7.

> ** Section 7.6.
>   A customer may request an IETF Network Slice Service that involves a
>   set of service functions (SFs)
>
> I might be misunderstanding the level of abstraction at which the SLA/SLI/etc
> will describe the slice.  I thought SFC would be an implementation detail.  I
> didn’t see a discussion of SFC in the SLI/SLO/SLE discussion in Section 5.1.

It very much depends.
It is true that the service might be delivered by the operator invoking SFs that are dotted around the network or not. And in this case, the fact that SFCs are used is no body's business but the operator.
On the other hand, the customer may be specifically constructing a service that requires the traffic to be routed through a set of nodes to provide SFs (IOW the SFC is under the customer's control). The connectivity matrix here is more complex: in one case (where the SFs are located at customer sites) this may just need some careful thought about connectivity, but in another case (where the SFs are located at nodes embedded in the operator's network) there is the need to include "ancillary CEs" in the connectivity matrix.
You may find the example in A.2 helpful to understand this further.

> ** Section 10.
>      The nature of conformance to isolation
>      requests means that it should not be possible to attack an IETF
>      Network Slice Service by varying the traffic on other services or
>      slices carried by the same underlay network.
>
> I’m not able to understand the security property described by the text.  Is
> this text trying to say that traffic in one slice is isolated from the other
> and attack traffic can't move from one slice from one to the other?  That a
> volumetric attack in one slice can’t affect another?

You may need to go back to Section 8 for the discussion of isolation.
But, yes. The volumetric attack is a good example. Although, "attack" may be too direct because "mistake" is also in scope here.
Of course, conformance to SLOs may be all the surety a customer needs (and if they get their service then their service is fine).
What isolation does, however, is give the customer some feeling of safety that they are not vulnerable to this sort of event.

Any suggestion to clarify the wording would be welcome.

Cheers,
Adrian