Re: [sfc] Early review draft-ietf-sfc-nsh

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Med,

I fully agree with you. However, I did go through the whole document making sure we were always using “transport encapsulation”. Frankly, I did find a few places where normalizing and cleaning the terminology helped a lot. I’ll post those changes before next week (I want to make some updates to the security considerations as well, and then release).

I also agree that, in theory, we do not need to re-describe the layering and all the pieces exist in RFC 7665 and in the NSH spec. I do not mind erring on the side of extra clarity for the uninitiated reader.

I will ask you to check out the forthcoming revision -22.

Thanks!

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Sep 21, 2017, at 3:05 AM, [e-mail]<mailto:[e-mail]> wrote:

Jim, all,

I do understand the confusion that is induced by "transport" in the NSH document. Using another term would fix this, sure.

But, we need to keep in mind that NSH spec is referring to RFC7665 which uses "transport" extensively. IMHO, the following figure from RFC7665 is very helpful to understand the SFC layering, including the notion of outer-transport encapsulation.

         +----------------+                        +----------------+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------+
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

Ideally, we don't even need to re-describe the layering in the NSH spec given that the draft delimits its scope clearly:

The NSH is the SFC encapsulation required to support
       ^^^^^^^^^^^^^^^^^^^^^^^^
  the Service Function Chaining (SFC) architecture (defined in
  RFC7665).

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:[e-mail]] De la part de James N Guichard
Envoyé : mercredi 20 septembre 2017 18:38
À : Kathleen Moriarty; Carlos Pignataro (cpignata)
Cc : Paul Quinn (paulq); [e-mail]<mailto:[e-mail]>
Objet : Re: [sfc] Early review draft-ietf-sfc-nsh

Hi Kathleen,

I am not quite clear as to exactly what is confusing with the existing
text (-21 version). Quoting from section 1:

  The Network Service Header (NSH) specification defines a new protocol
  and associated encapsulation for the creation of dynamic service
  chains, operating at the service plane.  The NSH is designed to
  encapsulate an original packet or frame, and in turn be encapsulated
  by an outer transport (which is used to deliver the NSH to NSH-aware
  network elements), as shown in Figure 1:

                    +------------------------------+
                    |    Transport Encapsulation   |
                    +------------------------------+
                    | Network Service Header (NSH) |
                    +------------------------------+
                    |    Original Packet / Frame   |
                    +------------------------------+

             Figure 1: Network Service Header Encapsulation

This states that the NSH is designed to encapsulate the original
packet/frame (read IP packet or Ethernet frame) and then in turn be
carried by an outer transport. The figure clearly shows that the outer
transport in this context is "Transport Encapsulation". The draft then
goes on to describe what NSH is and then in section 4 more detail is
provided on the transport encapsulation. Now reading section 4 it starts
by saying:

Once the NSH is added to a packet, an outer encapsulation is used to
  forward the original packet and the associated metadata to the start
  of a service chain.

Is the confusion caused by section 1 & 4 text saying "outer encapsulation"
or "outer transport" rather than "Transport Encapsulation" ? If so that is
easily fixed :-)

Thanks!

Jim

-----Original Message-----
From: sfc [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, September 20, 2017 12:22 PM
To: Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>>
Cc: Paul Quinn (paulq) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] Early review draft-ietf-sfc-nsh

Hi Carlos,

Please look at the text in the current document.  It only says transport
in the text I quoted.  The diagram also only says transport.
Drafts need to be clearly written to be broadly understood and the way the
text is now, it is not.  I think cleaning it up a bit will lift some of
the security concerns as some are addressed prior to NSH seeing the IP
packet or frame.

Your response helps, but please take the time to look through the document
to see how it can be clarified so one does not have the questions I and
others have raised.

Thank you,
Kathleen

On Wed, Sep 20, 2017 at 11:59 AM, Carlos Pignataro (cpignata)
<[e-mail]<mailto:[e-mail]>> wrote:
Hi, Kathleen,

Thank you for asking explicitly. This document used to have explicit
“NSH Encapsulation Examples”, but were taken out (at the AD’s request)
based on the argument that “everyone would like to have their
encapsulation”. We can always bring them back if desired, even within a
non-normative appendix.

As I follow your questions, I will try my best to answer and clarify.

I am not sure which “bunny trail” took the conversation here, but
perhaps a couple of top-post clarifications might help:

1. “Original Packet/Frame” -> the terminology Packet/Frame, as commonly
used, denotes an IP packet or an Ethernet frame.
2. The outer "Transport Encapsulation” does *not* mean TCP. It uses the
word “Transport” as transport profile, an encapsulation that transports,
not as TCP. GRE is one example of a transport encapsulation, not TCP as a
“L4 Transport Layer protocol”.

In point #2, GRE is the Transport that NSH uses between SFFs/SFs. And
further, since NSH is Transport Encapsulation agnostic, we are talking
about potentially a broad set of protocols… I’d encourage us to not
attempt to classify them in OSI Layers.

I can see that some of this might not be totally clear if scanning
through the document, but it is clear for an implementor.

See Table 1 and Table 3 for examples (Transport column)

I hope this helps set clarifying context, see inline for more specific
details...

On Sep 20, 2017, at 11:21 AM, Kathleen Moriarty
<[e-mail]<mailto:[e-mail]>> wrote:

Hi Carlos,

It's a start, but should be more specific.

The specifics are in the document, even examples as per Tables 1 and 3.

What are the original
packets/frame - is this link layer or network or both?

These are the packets or frames incoming into a classifier, original,
then NSH is imposed, then a transport encapsulation is imposed.

It seems like
both from the diagram, but is that really the case?

Yes, it is both. Really the case.


Then for the transport encapsulation, is this layer 3 or 4?

I believe it is a source of headache and confusion to think about OSI
layers… what layer is IP-in-IP? And an MPLS Pseudowire transporting
Ethernet? Or an IPv6/L2TPv3 pseudowire transporting TDM?


The wording that precedes this is a bit confusing (here for reference):

 The Network Service Header (NSH) specification defines a new protocol
 and associated encapsulation for the creation of dynamic service
 chains, operating at the service plane.  The NSH is designed to
 encapsulate an original packet or frame, and in turn be encapsulated
 by an outer transport (which is used to deliver the NSH to NSH-aware
 network elements), as shown in Figure 1:

Does the explanation above help? I am not sure how to best answer…
because I do not find it confusing. This text is the result of reviewers
asking for clarity, and then acknowledging that the paragraph above
brought that clarity.


Normally, the higher layers are encapsulated,

What is higher and lower? And for what definition of “Normally”? What’s
a Tunnel?

but this wording
describes just the opposite.  It says the packet/frame at layer 2/3
(just going from the normal uses of packet and frame to assume layer
3/2).

Correct. IP packet, Ethernet Frame.

NHS encapsulates that, and then is encapsulated by a transport layer
3/4?

No.

Where does it say “Transport Layer”?

Note that “Network Transport”, and “Transport Encapsulation” are terms
coming from RFC 7665.

And to be clear: many RFCs use “Transport Encapsulation” or a
variation of that (Encapsulation for Transport, Transport-independent
Encapsulation, etc.)

See Table 1 and Table 3, Transport column, for examples.


If you can clarify this text or make it clear that you really
intended to do this odd encapsulation, that would help a lot.

Hopefully my explanation helps.

Understanding the layers this all happens at is very important.  If
NSH is the trigger for the layer 3/4 transport, how can security be
applied?  Or is it addressed by a prior 3/4 encapsulation by the
original packet/frame?

Thanks,
Kathleen



—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>



On Tue, Sep 19, 2017 at 4:53 PM, Carlos Pignataro (cpignata)
<[e-mail]<mailto:[e-mail]>> wrote:
Hi, Kathleen,

Thanks for the clarification.

Regarding:

is that the layering needs to be specifically stated to clearly


Like this?
https://tools.ietf.org/html/draft-ietf-sfc-nsh-21#section-1

                   +------------------------------+
                   |    Transport Encapsulation   |
                   +------------------------------+
                   | Network Service Header (NSH) |
                   +------------------------------+
                   |    Original Packet / Frame   |
                   +------------------------------+

            Figure 1: Network Service Header Encapsulation

I think if you laid this out
nicely and clearly showed where transport security is addressed at
another layer (out-of-scope), it would go a long way.


Hopefully the above (existing) figure and text is clear. In that case:

One idea is to categorize the paragraphs in the Security
Considerations to
make those relations more clear.

—
Carlos Pignataro.


On Sep 19, 2017, at 3:38 PM, Kathleen Moriarty
<[e-mail]<mailto:[e-mail]>> wrote:

Thanks for the responses.  I'm going to top post as I thin the main
point of my review is that the layering needs to be specifically
stated to clearly scope the problem space for NSH security
considerations.  The draft as-written is not clear and as a result,
security reviews are very difficult.  I think if you laid this out
nicely and clearly showed where transport security is addressed at
another layer (out-of-scope), it would go a long way.  Although the
draft improved a bit from the previous version, I think a careful
review and edit pass would do a lot of good, specifically around
clarity of the problem space and solution.  The questions I asked were
a result of lack of clarity in the draft.

Thanks,
Kathleen

On Tue, Sep 19, 2017 at 3:22 PM, Paul Quinn (paulq) <[e-mail]<mailto:[e-mail]>>
wrote:

Hi,

Thank you for the review.  Please see some comments inline below.

Paul

On Sep 18, 2017, at 4:15 PM, Kathleen Moriarty
<[e-mail]<mailto:[e-mail]>> wrote:

Hello,

At Alia's request, I did an early review of draft-ietf-sfc-nsh.  Here
are some initial comments and I may have more when the draft is
revised and is in for IESG review.  I appreciate your efforts
addressing the comments received to date.  I hope you find these
suggestions as helpful improvements to the document and clarity of NSH
security concerns.


Section 1 -

The intended scope in the introduction should also include mention of
multi-tenancy.  This changes the security requirements and is very
important to note.

Section 1.4 -

5.  Transport Agnostic: The NSH is encapsulation-independent, meaning
   it can be transported by a variety of protocols.  An appropriate
   (for a given deployment) encapsulation protocol can be used to
   carry NSH-encapsulated traffic.  This transport may form an
   overlay network and if an existing overlay topology provides the
   required service path connectivity, that existing overlay may be
   used.

Is there a preferred transport so you could specify a recommended
transport security protocol?


PQ> There is not.  In fact at the AD’s request sample transports were
removed to ensure that there was no implied preference.  Therefore, an
operator can select their preferred transports, including — as per the
security considerations section — ones that provide encryption.


Section 2, 3rd sentence:
Subsequently, an
outer encapsulation is imposed on the NSH, which is used for network
forwarding.

Knowing more about this would help to understand options or if there
is another draft that addresses this outer encapsulation that is
imposed and the transport security requirements that go along with it.


PQ> Since NSH defines no preferred transport(s), the security of the
selected transport is left to the transport standard.   So, for
example, if
an operator elects to use the NVO3 defined protocol, then the operator
has
explicitly selected that overlay.


Transport may be hop to hop, and there might not be encryption of this
header if the application uses an encrypted transport encapsulated in
this layer.  In any case, it seems integrity protection is a
requirement for a multi-tenant environment.  Could the COSE MAC
function fit the bill since it is intended for concise formats?
https://datatracker.ietf.org/doc/rfc8152
JOSE produced a similar function with JSON, but it would be slightly
larger.

Section 7.1:

The following paragraph implies that anything less than a 5-tuple
isn’t useful and that you intend to use traffic content when
available.  This is concerning.  Can’t you use a 2-tuple?  What if
IPsec transport mode were in use, is this solution dead in the water?

Regardless of the source, metadata reflects the "result" of
classification.  The granularity of classification may vary.  For
example, a network switch, acting as a classifier, might only be able
to classify based on a 5-tuple, while a service function may be able
to inspect application information.  Regardless of granularity, the
classification information can be represented in the NSH.

If a 2-tuple is possible, could you add that in as an example instead
of or in addition to the 5-tuple?


PQ>  The 5-tuple was used only as an example that is commonly
understood in
the context of network device classification.  The sentence: "The
granularity of classification may vary.” addresses 2, 3, 4, n-tuple
classification.  Further, that point is reinforced: “Regardless of
granularity, the classification information can be represented in the
NSH."




Section 7.1

This text comes too late in the draft and I recommend making a clear
statement in the introduction that session encryption to protect the
data in transit relies on the application/service sending/receiving
the data and not the SFC.  I made this point previously and am glad to
see some text, but think it would be much better to state this early
in the draft.  Touching upon protections for data streams versus meta
data would both be important (layers for traffic and associated
protections).  If it’s meta data, do they need to rely on IPsec and
having a 2-tuple be the minimum?  When is that applied?  Is there meta
data that could be sensitive if TLS was in place and a 5-tuple is
visible (perhaps the existence of communication is sensitive).  Are
there other considerations for metadata and data that need to be
stated up front and put out-of-scope for SFC?  I’m asking these
questions as providing these answers could show that the risk is
constrained.

Depending on the information carried in the metadata, data privacy
considerations may need to be considered.  For example, if the
metadata conveys tenant information, that information may need to be
authenticated and/or encrypted between the originator and the
intended recipients (which may include intended SFs only).  The NSH
itself does not provide privacy functions, rather it relies on the
transport/overlay layer.  An operator can select the appropriate
transport to ensure confidentiality (and other security)
considerations are met.  Metadata privacy and security considerations
are a matter for the documents that define metadata format.



PQ>  Are you suggesting that application layer confidentially be
addressed
in this draft?   NSH “plays nicely” with standard encryption
transports,
therefore allowing operators to “secure” the path.  Going up the stack
from
that seems to be outside the scope of NSH and inconsistent with other
protocol requirements.


Other comments:

I’d like to see;
https://tools.ietf.org/html/draft-mglt-sfc-security-environment-req-02
Published before this document and then have that as a reference.  One
of the comments I made previously was to list out the layering and
protections expected on data and NSH.  This has been done in the
security environment draft, section 4 should be referenced:

Section 4 provides an overall description of the SFC environment with
the introduction of the different planes (SFC Control Plane, the SFC
Management Plane, the Tenant's user Plane and the SFC Data Plane).



PQ>  As I mentioned on another thread: a secure environment draft is
not
related to NSH per se.




This is a very important point for anyone reviewing for security as
are the environment security requirements.  The security environment
requirements draft still needs a little more work from a quick read,
but helps a lot.  I need to finish reading the security environment
draft.

--

Best regards,
Kathleen

_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc





--

Best regards,
Kathleen

_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc





--

Best regards,
Kathleen




--

Best regards,
Kathleen

_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc