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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 18 Sep 2017 16:15:59 -0400

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?

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.

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?

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.

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Sep 2017 19:03:26 -0400

Let me answer a couple fo the easy questions, and ask one somewhat more 
complex one:

The easy one is that this work is, per charter, completely agnostic on 
transports.  It does not have a preferred transport.  In order to reduce 
contention about appearing to prefer some transports, examples of 
specific transport approaches were removed from the draft.

As I result, I am not sure what we can say about your comment on Section 
2, 3rd sentence.  We are not placing any security requirements on the 
transports.  (There have been drafts on transport proposals.  The 
Ethernet proposals did not call for 802.1x.  The MPLS proposals did not 
add any security to MPLS.)

You refer to multi-tenancy.  There seem to be at least two different 
meanings for multi-tenancy in this context.
The most common usage of the term is when the service function chaining 
is used by an operator to provide services to a number of tenants (many 
subscribers, residential, corporate, whatever.)  That does not seem to 
lead to any security requirements.
Another meaning is where a tenant is using a data center for hosting 
their own service function chaining either for their own traffic or for 
traffic for their customers.  The tenant presumably needs to use 
appropriate mechanisms to provide appropriate confidentiality and 
integrity protection for tehir traffic, as they judge relevant to 
isolate themselves from the seller of the service.  That does not seem 
to require any additional NSH text, as it is a general data center 
tenancy issue.

So can you please elaborate on what multi-tenancy case you are 
interested in, and what issues you feel NSH needs to address?

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 19 Sep 2017 00:24:49 +0000

Thank you Kathleen for your early review of draft-ietf-sfc-nsh!

Really appreciate you taking the time, since you understand some historical context.

> On Sep 18, 2017, at 4:15 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 
> At Alia's request, I did an early review of draft-ietf-sfc-nsh.

We are almost at one fourth of the IESG early-reviewing this draft :-)

>  Here

Joel already commented on this. I am happy to add Introductory context but I am also not sure of the relevance. 

Perhaps the easiest place is:

OLD:
For example, a
   network administrative domain can include a single data center, or an
   overlay domain using virtual connections and tunnels.

NEW:
For example, a
   network administrative domain can include a single data center, a 
   multi-tenancy enabled virtualized network, or an
   overlay domain using virtual connections and tunnels.

What do you think? Can you propose some textual specifics otherwise?

> transport security protocol?

If there were, it would not really be transport agnostic :-)

Consequently...

> JOSE produced a similar function with JSON, but it would be slightly larger.

… I am very hesitant to adding anything that is transport dependent here.

> of or in addition to the 5-tuple?

Good point! Added (in addition to).

>   are a matter for the documents that define metadata format.

It seems quite hard to move or replicate some of these considerations earlier in the document, since there’s significant context that needs to be understood of the NSH before describing them. 

That paragraph is not referring to session/application-level encryption.

I may be misunderstanding the comment though...

> security environment draft, section 4 should be referenced:

That individual draft concerns itself with control, data, and management planes considerations. It is much beyond the scope of the NSH. It cannot be understood without control-plane and management-plane, and consequently should follow (and not precede) those documents as a whole complete SFC-scoped document (and not NSH-scoped).

> but helps a lot.  I need to finish reading the security environment

Thanks,

— Carlos.

> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 19 Sep 2017 14:13:59 -0400

Joel:

> On Sep 18, 2017, at 7:03 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Let me answer a couple fo the easy questions, and ask one somewhat more complex one:
> 
> The easy one is that this work is, per charter, completely agnostic on transports.  It does not have a preferred transport.  In order to reduce contention about appearing to prefer some transports, examples of specific transport approaches were removed from the draft.
> 
> As I result, I am not sure what we can say about your comment on Section 2, 3rd sentence.  We are not placing any security requirements on the transports.  (There have been drafts on transport proposals.  The Ethernet proposals did not call for 802.1x.  The MPLS proposals did not add any security to MPLS.)

TOM: I was thinking precisely the same thing when I scanned over the initial request.  The MPLS protocol documents are structured
exactly that way, so I see no need to require them here as NSH is very much analogous to the way MPLS functions.  With that
said, I am not saying security is unimportant or useful for NSH, just that its orthogonal to this context.

> You refer to multi-tenancy.  There seem to be at least two different meanings for multi-tenancy in this context.
> The most common usage of the term is when the service function chaining is used by an operator to provide services to a number of tenants (many subscribers, residential, corporate, whatever.)  That does not seem to lead to any security requirements.
> Another meaning is where a tenant is using a data center for hosting their own service function chaining either for their own traffic or for traffic for their customers.  The tenant presumably needs to use appropriate mechanisms to provide appropriate confidentiality and integrity protection for tehir traffic, as they judge relevant to isolate themselves from the seller of the service.  That does not seem to require any additional NSH text, as it is a general data center tenancy issue.
> 
> So can you please elaborate on what multi-tenancy case you are interested in, and what issues you feel NSH needs to address?

TOM: I agree with you again; I do not see how this applies to NSH any more than it did to MPLS.

	—Tom

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 19 Sep 2017 19:22:31 +0000

Hi,

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

Paul

> On Sep 18, 2017, at 4:15 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 

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.

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

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

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 19 Sep 2017 15:38:31 -0400

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

-- 

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 19 Sep 2017 20:53:25 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kathleen

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

Paul

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

Hello,

Section 1 -

Section 1.4 -

Section 2, 3rd sentence:
 Subsequently, an

Section 7.1:

Section 7.1

Other comments:

I’d like to see;

--

Best regards,
Kathleen

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

--

Best regards,
Kathleen

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Sep 2017 11:21:30 -0400

Hi Carlos,

It's a start, but should be more specific.  What are the original
packets/frame - is this link layer or network or both?  It seems like
both from the diagram, but is that really the case?

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

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:

Normally, the higher layers are encapsulated, 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).  NHS encapsulates that, and then is encapsulated by a transport
layer 3/4?  If you can clarify this text or make it clear that you
really intended to do this odd encapsulation, that would help a lot.
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

On Tue, Sep 19, 2017 at 4:53 PM, Carlos Pignataro (cpignata)
<[email-masked]> wrote:
> On Sep 19, 2017, at 3:38 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>
> On Sep 18, 2017, at 4:15 PM, Kathleen Moriarty
> <[email-masked]> wrote:
>
> Hello,
>
> 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
> 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.
>
>
> 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
>
> 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;

-- 

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Sep 2017 15:59:10 +0000

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 <[email-masked]> 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

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?

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

Hopefully my explanation helps.

> applied?  Or is it addressed by a prior 3/4 encapsulation by the

—
Carlos Pignataro, [email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Sep 2017 12:22:20 -0400

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

-- 

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Sep 2017 16:35:24 +0000

Kathleen,

Sure, we will take an Editorial pass and look over it and all the mentions of specific keywords. As I mentioned, we will also go over the security considerations text to make the text flow and categorization more clear.

All those Editorials will clarify further.

so one does not have the

However: others have raised similar question in rev -18. The changes between -18 and -21 resolved all those questions. Everyone (except you) who had raised even a small concern about that specific confusion, already acknowledge that the current version addresses those.

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

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

On Sep 20, 2017, at 12:22 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Thank you,
Kathleen

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

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

Hi Carlos,

What are the original

It seems like

but this wording

No.

Thanks,
Kathleen

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

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

Regarding:

Like this?

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
<[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kathleen

Hi,

Paul

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

Hello,

Section 1 -

Section 1.4 -

Section 2, 3rd sentence:
Subsequently, an

Section 7.1:

Section 7.1

Other comments:

I’d like to see;

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

--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: James N Guichard <[email-masked]>
Date: Wed, 20 Sep 2017 16:38:20 +0000

Hi Kathleen,

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

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:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, September 20, 2017 12:22 PM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: Paul Quinn (paulq) <[email-masked]>; [email-masked]
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) <[email-masked]> wrote:
>>  NHS encapsulates that, and then is encapsulated by a transport layer 
>> 3/4?
>
> No.
>
> And to be clear: many RFCs use “Transport Encapsulation” or a 
> variation of that (Encapsulation for Transport, Transport-independent 
> Encapsulation, etc.)
>
>>  If you can clarify this text or make it clear that you really 
>> intended to do this odd encapsulation, that would help a lot.
>
>>> is that the layering needs to be specifically stated to clearly
>>>
>>>
>>> Like this?

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Sep 2017 12:48:31 -0400

>    network elements), as shown in Figure 1:

Jim, this would help.  It's hard when you are in the weeds of
something to look at it from a new comers view.  The email responses
are extensive, so you may have cleared some of the questions up from
other reviewers in email rather than the draft.  Making the text clear
as to what is happening is very important.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Thu, 21 Sep 2017 07:05:34 +0000

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:[email-masked]] De la part de James N Guichard
> Envoyé : mercredi 20 septembre 2017 18:38
> À : Kathleen Moriarty; Carlos Pignataro (cpignata)
> Cc : Paul Quinn (paulq); [email-masked]
> 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:
> 
> 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:
> 
> 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
> 
> 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
> 
> > 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.
> >
> > 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.
> >
> >> On Sep 20, 2017, at 11:21 AM, Kathleen Moriarty
> > These are the packets or frames incoming into a classifier, original,
> then NSH is imposed, then a transport encapsulation is imposed.
> >
> >>  It seems like
> > 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?
> >
> >>
> > 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.
> >
> >>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 21 Sep 2017 12:47:28 +0000

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!

—

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

Jim, all,

Cheers,
Med

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

Hi Kathleen,

Thanks!

Jim

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

Hi Carlos,

Thank you,
Kathleen

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

Hi Carlos,

What are the original

It seems like

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

but this wording

No.

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

Thanks,
Kathleen

—

Regarding:

Like this?

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

—
Carlos Pignataro.

Thanks,
Kathleen

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

Hi,

Paul

Hello,

Section 1 -

Section 1.4 -

Section 2, 3rd sentence:
Subsequently, an

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.

JOSE produced a similar function with JSON, but it would be slightly
larger.

Section 7.1:

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

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;

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

--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Sep 2017 09:25:32 -0400

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

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

> On Sep 21, 2017, at 3:05 AM, [email-masked] 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.
>
> Ideally, we don't even need to re-describe the layering in the NSH spec
> given that the draft delimits its scope clearly:
>
> On Tue, Sep 19, 2017 at 3:22 PM, Paul Quinn (paulq) <[email-masked]>
>
> wrote:
>
>
> Hi,
>

-- 

Best regards,
Kathleen