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

[Kathleen Moriarty <[e-mail]>]

On Thu, Sep 21, 2017 at 8:47 AM, Carlos Pignataro (cpignata)
<[e-mail]> wrote:
> 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.

Thank you.  I think this will be very helpful.  Perhaps a reference to
the diagram Med pointed out would fit somewhere in the introduction?
You don't need to include it again.  Having not looked at the update
yet, I am not sure if that is necessary.

Thanks,
Kathleen

>
> Thanks!
>
> —
> Carlos Pignataro, [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] 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]
> 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
>
>



-- 

Best regards,
Kathleen