Subject: [sfc] Benjamin Kaduk's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 06 May 2020 16:06:22 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sfc-oam-framework-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

I'm not sure that I understand why a node in the underlay network (the
"VM2" one) doesn't line up with a node in the link layer, in Figure 1.

Section 3

       classifiers, controllers, other service nodes).  Testing an SF
       may not be restricted to connectivity to the SF, but also whether

nit(?) perhaps "may be more expansive than just checking connectivity to
the SF", to avoid questions about what the "not" binds to.

   3.  Classifier component: OAM functions applicable at this component
       includes testing the validity of the classification rules and
       detecting any incoherence among the rules installed in different
       classifiers.

It seems important to include both positive and negative tests of
classification functionality (i.e., that traffic that should not match
in fact does not match).  Section 3.3 might be a good place to mention
this.

Section 3.1.1

   service function is available?.  On one end of the spectrum, one
   might argue that an SF is sufficiently available if the service node
   (physical or virtual) hosting the SF is available and is functional.
   On the other end of the spectrum, one might argue that the SF's
   availability can only be concluded if the packet, after passing

I agree with the other reviewers that the first "end" of the spectrum
seems surprising.

   firewall).  The cost of this approach is that the OAM mechanism for
   some SF will need to be continuously modified in order to "keep up"
   with new functionality being introduced: lack of extendibility.

nit: the grammar doesn't seem right around "lack of extendibility"
(also, is "extendibility" preferred or "extensibility"?).

   The SF availability can be performed using a generalized approach
   (i.e., an adequate granularity to provide a basic SF service).  More

nit: I think it's an availability *check* that can be performed.

Section 3.2.2

Mandating the ability to measure every arbitrary segment of SFs within
an SFC seems like it might be over-constraining.

Section 4

   to perform OAM functionality at different layers.  In order to apply
   such OAM functions at the service layer, they need to be enhanced to
   operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
   multiple SFCs.

I don't understand what "operate a single SFF to multiple SFs/SFFs"
means.

Section 4.1

   o  Verify any packet re-ordering and corruption.

nit: this wording doesn't really make sense.  Do we want to verify the
absence of such things, or that it is within configured tolerances, or
something else?  Just noting any occurrences and verifying that the
noted occurrences are as noted doesn't seem useful...

   o  Verify the policy of an SFC or SF.

nit: similarly, is this to verify the configuration, or to verify that
operation matches the expected configuration?

Section 4.2

   Continuity is a model where OAM messages are sent periodically to
   validate or verify the reachability to a given SF within an SFC or

nit: while it's "connectivity to", I think it's "reachability of".

   o  Notifying the detected failures to other OAM functions or
      applications to take appropriate action.

nit: the subject of a notification is the entity receiving notification,
not the content of the notification.  So "notifying other OAM functions
or applications of the detected failures so they can take appropriate
action", or "Sending notifications of the detected failures to other
[...]".

Section 4.4

   delay [RFC7679] is important.  In order to measure one-way delay,
   time synchronization MUST be supported by means such as NTP, PTP,
   GPS, etc.

I think (informational) references are in order for these.  (PTP is not
listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt , though the
other two are.)

   One-way delay variation [RFC3393] could also be calculated by sending
   OAM packets and measuring the jitter between the packets passing
   through an SFC.

Looking at jitter between (measurement) packets to ascertain delay
variation seems to require foreknowledge of the (e.g., periodic) pacing
of the initial packet transmission.  If, on the other hand, the idea is
to look at the jitter across the measured delay of each packet, then
that works fine (but that's not what the current text says).

   o  Ability to measure the packet loss [RFC7680] within an SF or an
      SFP bound to a given SFC.

nit(?): packet loss "within an SF" (as opposed to between two SFs) is
not something I would have expected to need measuring, on first thought.
Though on further reflection it is less surprising; still, I wanted to
check that this is indeed as intended.

Section 5.2

   As shown in Table 3, there are no standards-based tools available for
   the verification of SFs and SFCs.

Some note about "at the time of this writing" or similar seems advised;
otherwise this statement is unlikely to age well.

Section 6.2

   An SFF may choose not to forward the OAM packet to an SF if the SF
   does not support OAM or if the policy does not allow to forward OAM
   packet to an SF.  The SFF may choose to skip the SF, modify the
   header and forward to next SFC node in the chain.  It should be noted
   that skipping an SF might have implication on some OAM functions
   (e.g. the delay measurement may not be accurate).  The method by

This behavior was initially surprising to me, and "might have
implication on" feels like weaker text than is merited.  While I can
perhaps imagine that not forwarding an OAM packet to an SF that will
choke on it instead of doing something useful, it seems like it's rather
divergent from the OAM expectations to silently bypass a given SF and is
quite likely to affect the accuracy of the resulting OAM results.

   process OAM packets is outside the scope of this document.  It could
   be a configuration parameter instructed by the controller or it can
   be done by dynamic negotiation between the SF and SFF.

(Is there an existing mechanism for dynamic negotation between SF and
SFF?)

Section 6.3

   As described in Section 4, there are different OAM functions that may
   require different OAM solutions.  While the presence of the OAM
   marker in the overlay header (e.g., O bit in the NSH header)
   indicates it as OAM packet, it is not sufficient to indicate what OAM
   function the packet is intended for.  The Next Protocol field in NSH
   header may be used to indicate what OAM function is intended to or
   what toolset is used.

Elsewhere in the document we make reference to what would be required of
a non-NSH encapsulation header; is it appropriate to also do so here?

Section 6.4.2

   BFD or S-BFD could be leveraged to perform continuity function for SF
   or SFC.  An initiator could generate a BFD control packet and set the
   "Your Discriminator" value as last SFF in the control packet.  Upon

nit: I think this "your discriminator" would be the address or
identifier of the last SFF, not just "the last SFF" itself, right?
Or be set "to indicate" the last SFF, or similar.
(Also occurs a few sentences later.)

   with relevant DIAG code.  The TTL field in the NSH header could be
   used to perform partial SFC availability.  For example, the initiator

nit: availability checks/checking

Section 6.4.4

   [I-D.penno-sfc-trace] defines a protocol that checks for path
   liveliness and traces the service hops in any SFP.  Section 3 of
   [I-D.penno-sfc-trace] defines the SFC trace packet format while
   Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF
   and SFF respectively.  While [I-D.penno-sfc-trace] has expired, the
   proposal is implemented in Open Daylight and available.

Why is draft-penno-sfc-trace not progressing towards publication?

Section 7

I think this table really needs more lead-in to what it's communicating.

   As depicted in Table 4, information and data models are needed for
   configuration, manageability and orchestration for SFC.  With

I don't see where that is actually indicated by the table.

Section 8

OAM information (though most usefully as summary statistics), if leaked,
could also be used by an attacker to gauge the efficacy of an ongoing
attack.

   Any security consideration defined in [RFC7665] and [RFC8300] are
   applicable for this document.

The rest of the document implies that NSH is not mandatory, so I'd
suggest rewording this reference to clarify what from RFC 8300 is (or is
not) applicable to the whole of the document.

   The mapping and the rules information at the classifier component may
   reveal the traffic rules and the traffic mapped to the SFC.  The SFC
   information collected at an SFC component may reveal the SF
   associated within each chain and this information together with

nit: s/the SF/the SFs/

   To address the above concerns, SFC and SF OAM may provide mechanism
   for:

(1) The crucial missing word that Roman notes is indeed crucial!
(2) Can we say something stronger than "may"?

   The documents proposing the OAM solution for any service layer
   components should consider some form of message filtering to prevent
   leaking any internal service layer information outside the
   administrative domain.

"should consider" is fairly weak guidance; would "should provide" be
appropriate?

Also, is it worth mentioning that this filtering would include dropping
OAM-marked messages from outside the domain (at least by default)?

Section 12.1

The only citation to RFC 8300 that appears to require a normative
reference is the bit in the security considerations that I noted was
unclear about its scope of applicability.

Section 12.2

RFC 6291 is a BCP, so we should probably cite it as such.  Also, given
its content, perhaps it ought to be normative?

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 14 May 2020 13:40:13 +0000

Hi Benjamin,

Thank you for the comments. Please see inline for more response.

    
    
    Section 2

<Nagendra>Am I assuming right that the question is about the misalignment between the nodes on Link layer and underlay layer?. If so, it was a typo and we fixed it. If I misunderstood the question, please let me know.

    Section 3

  
<Nagendra> Yes. Your suggested text seems to make it easy to parse the statement. Please check the below text:

OLD:
Testing an SF
       may not be restricted to connectivity to the SF, but also whether
       the SF is providing its intended service.

NEW:
Testing an SF
       may be more expansive than just checking connectivity to the SF
       such as checking if the SF is providing its intended service.

    
<Nagendra> The below text in Section 3.3 is intended to cover such misclassification:

" The SFC OAM must be able to validate the classification
   rules by assessing whether a flow is appropriately mapped to the
   relevant SFC."

If the above is not clear, we can update the same as:

NEW:
The SFC OAM must be able to validate the classification
   rules by assessing whether a flow is appropriately mapped to the
   relevant SFC and detect any misclassification.

    Section 3.1.1

    

 <Nagendra> We have this changed to extensibility.

 
<Nagendra> Good catch (. Fixed it.

    Section 3.2.2

<Nagendra>This is not a normative statement but intended to detect and isolate performance issue within the SFC.

    Section 4

 
<Nagendra> We got similar comments from other reviewers highlighting the ambiguity. We changed it as below:

OLD:
In order to apply

NEW:
In order to apply such OAM functions at the service layer, they need to be enhanced 
to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.

    Section 4.1

   
<Nagendra> We changed this as "detect" instead of "verify".

    
<Nagendra> This section is about connectivity function and so it is intended to verify the operation based on the configuration.

    Section 4.2

    
<Nagendra> Changed it.

    
<Nagendra> The former one looks more appropriate. 

    Section 4.4

    
<Nagendra> Based on my understanding on the above cited document, I expanded PTP and left the other two as it is. Let me know if the other two should be expanded.

    
<Nagendra> Agreed. The measurement may need time synchronization and additional negotiation such as probe pace etc. But I think that this should be clarified in the solution documents.

    
<Nagendra> The ability to measure packet loss within an SFP helps detect such loss while the ability to measure packet loss within an SF helps isolate the issue. 

    Section 5.2

    
<Nagendra> That make sense. Please find the updated text below:

OLD:

NEW:
As shown in Table 3, there are no standards-based tools available at the 
time of this writing for the verification of SFs and SFCs.

    Section 6.2

    
<Nagendra> Forwarding the OAM packet to an SF that does not support (or the policy config does not allow) OAM may result in packet drops depending on the type of SF. For example, a FW may drop the OAM packet while other SF such as pkt-capture-sf may simply pass it through. It may be difficult to differentiate if the drop is due to the lack of feature support or some forwarding/processing issue. Such inaccuracy on the OAM function is highlighted in this section.

    
<Nagendra>Not that I know of. If it vitiates the section or sentence, we can remove it.

    Section 6.3

    
<Nagendra> Does the below modified text looks better?:

OLD:
The Next Protocol field in NSH
   header may be used to indicate what OAM function is intended to or
   what toolset is used.

NEW:
The Next Protocol field in NSH
   header may be used to indicate what OAM function is intended to or
   what toolset is used. Any other overlay encapsulations used at the service 
layer must have a similar way to indicate the intended OAM function.

    Section 6.4.2

    
<Nagendra> Yes, good catch (. Modified the same in the relevant sentences.

    
<Nagendra> Fixed.

    Section 6.4.4

    
<Nagendra> I will let the authors of penno-sfc-trace to comment on the plans to move it towards publication.

    Section 7

    
    
<Nagendra> The data models required for config/orchestration of any SFC elements (such as classifier/SF/SFF) is not available today. We can clarify this in the section. Please see if the below text clarifies:

OLD:
As depicted in Table 4, information and data models are needed for
   configuration, manageability and orchestration for SFC.

NEW:
While the NETCONF capabilities are readily available as depicted in Table 4, the information and data models are needed for
   configuration, manageability and orchestration for SFC.

    Section 8

<Nagendra> Section 8 already defines the below:

"The documents proposing the OAM solution for any service layer components should consider some form of message filtering to prevent leaking any internal service layer information outside the administrative domain."

I believe this covers the point you raised. Please let us know if it doesn’t. 

    
<Nagendra> While not mandatory, NSH is one of the overlay headers that could be used for encapsulating the OAM packets. So, any security considerations defined in RFC8300 is applicable when the OAM solutions are using NSH as overlay header. 

    nit: s/the SF/the SFs/
    
<Nagendra> Fixed.

    
<Nagendra> This is changed to "should" based on the SecDir comments.

    
<Nagendra> Changed the same as "should provide".

<Nagendra> I checked the section and didn’t see any specifics about incoming OAM packets. Does the below text clarify?

OLD:
Rate-limiting may be applied at the SFF or the SF

NEW:
Rate-limiting may be applied at the Classifier, SFF or the SF

    Section 12.1

<Nagendra> We updated the document to avoid using normative statements. Let me check with my co-authors to see if we should move all the references as Informative.

    Section 12.2

<Nagendra> Same as above.

Once again, thanks a lot for the great comments. 

Thanks,
Nagendra

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 May 2020 16:18:26 -0700

Hi Nagendra,

>     https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

Yes, that was the question, and thanks for the fix!

>    relevant SFC and detect any misclassification.

I'd suggest making the update.  The original is probably clear to most
people, but maybe not to everyone.

> to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.

I think I'm failing to see the difference, unfortunately.

> <Nagendra> This section is about connectivity function and so it is intended to verify the operation based on the configuration.

Perhaps "verify that an SFC or SF is applying the expected policy"?

> <Nagendra> Based on my understanding on the above cited document, I expanded PTP and left the other two as it is. Let me know if the other two should be expanded.

The other two don't need to be expanded.  In addition to expanding PTP, I
was wondering whether to reference the RFCs for each protocol mentioned.
Perhaps it is not worth the extra effort at this time.

> <Nagendra> Agreed. The measurement may need time synchronization and additional negotiation such as probe pace etc. But I think that this should be clarified in the solution documents.

I agree that the details should be in other documents.  Would you be
willing to have this text be "measuring packet jitter for traffic passing
through an SFC"?

> <Nagendra>Not that I know of. If it vitiates the section or sentence, we can remove it.

No need to remove it.  I'd consider adding "(the details of which are out
of scope for this document)" since there's no other document to reference,
but it's not necessary.

> layer must have a similar way to indicate the intended OAM function.

That does look better, thanks!

>    configuration, manageability and orchestration for SFC.

That looks better, yes.

> I believe this covers the point you raised. Please let us know if it doesn’t. 

The text you refer to describes an appropriate mitigation to take, but does
not discuss the potential consequences when the mitigation is not taken.  I
was hoping to see a mention of how the data could be misused if the
operator failed to apply the recommended protective measures (as a way to
incentive proper use of protective measures).

> Rate-limiting may be applied at the Classifier, SFF or the SF

My remark was about the "filtering to prevent leaking any internal service
information outside the administrative domain", so rate-limiting at the
classifier would not really be the appropriate mechanism.  Rather, the
classifier should reject/discard incoming traffic with unexpected OAM
markings.

> <Nagendra> We updated the document to avoid using normative statements. Let me check with my co-authors to see if we should move all the references as Informative.

I think you should not blanket move all references to Informative; there
can still be need for normative references even without BCP 14 keywords.

> Once again, thanks a lot for the great comments. 

And thank you for the updates!

-Ben

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sat, 23 May 2020 12:43:24 +0000

Hi Benjamin,

Thank you for the response. Please see inline for <Nagendra>2

On 5/22/20, 7:18 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi Nagendra,

<Nagendra2> Done.

<Nagendra2> It was a copy paste error. Below is the updated text:

In order to apply such OAM functions at the service layer, they need to be enhanced to 
operate a single SF/SFF to multiple SFs/SFFs spanning across one or more SFCs.

<Nagendra2> I will leave it as it is now. 

<Nagendra2> Looks better. Done.

<Nagendra2> We have this emphasized in the section already.

    That looks better, yes.

<Nagendra2> Some info around the potential misuse of such data is in the  same section (as below):

The mapping and the rules information at the classifier component may reveal the traffic rules and the traffic mapped to the SFC. The SFC information collected at an SFC component may reveal the SFs associated within each chain and this information together with classifier rules may be used to manipulate the header of synthetic attack packets that may be used to bypass the SFC and trigger any internal attacks.

The SF information at the SF component may be used by a malicious user to trigger Denial of Service (DoS) attack by overloading any specific SF using rogue OAM traffic.

<Nagendra2> AFAIK, the OAM marking in the header classifies a packet as OAM probe/packet and must be rate-limited based on the above. I am not sure I understand what is unexpected OAM marking.

    -Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 May 2020 11:02:29 -0700

Hi Nagendra,

Generally this all looks good; just a couple final notes inline.

> operate a single SF/SFF to multiple SFs/SFFs spanning across one or more SFCs.

Ah, thanks, this looks better.

> <Nagendra2> AFAIK, the OAM marking in the header classifies a packet as OAM probe/packet and must be rate-limited based on the above. I am not sure I understand what is unexpected OAM marking.

I had in mind a scenario where a classifier might receive traffic from a
given source that is allowed to supply data-plane packets to a SFC but is
not allowed (by policy or contract) to send OAM probes.  In that case (if
such a case exists), the classifier would need to act as a firewall,
dropping OAM-marked packets from that source entirely, instead of just
rate-limiting them.

Thanks for all the updates,

Ben

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sun, 24 May 2020 02:11:42 +0000

Hi Benjamin,

Thank you for the response. 

<Nagendra> Oh ok. I think this still could be achieved by configuring the classifier to rate-limit at a rate of 0 packets (. If this does not satisfy the criteria, we can consider the below: 

NEW:
The documents proposing the OAM solution for any service layer components should consider some form of message filtering to control OAM messages entering the administrative domain or to prevent leaking any internal service layer information outside the administrative domain.

Thanks,
Nagendra

On 5/23/20, 2:03 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi Nagendra,

    Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 May 2020 20:49:58 -0700

> <Nagendra> Oh ok. I think this still could be achieved by configuring the classifier to rate-limit at a rate of 0 packets (. If this does not satisfy the criteria, we can consider the below: 

Ah, I take your point -- a rate of 0 packets would achieve the firewall
effect.  I just don't normally expect a rate-limiting function to use a
rate of 0, so...

> The documents proposing the OAM solution for any service layer components should consider some form of message filtering to control OAM messages entering the administrative domain or to prevent lea…

... I would prefer this text, which is nicely written.

Thanks,

Ben