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

[<[e-mail]>]

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]
> 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]>
> Cc: Paul Quinn (paulq) <[e-mail]>; [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]> 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]> 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]
> >
> >
> >>
> >> On Tue, Sep 19, 2017 at 4:53 PM, Carlos Pignataro (cpignata)
> >> <[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]> 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]>
> 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]> 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]
> >>> 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]
> https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc