[sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-packet-02: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-sfc-oam-packet-02: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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


The 4 initial comments are related to the NEW text in §3.

(1)
      Absent explicit configuration, SFFs, SFC-aware SFs, and
      SFC Proxies SHOULD discard any NSH packets with the O bit
      set and Next Protocol set to something that is not itself
      an OAM protocol. This includes discarding the packet when
      the O bit is set and the Next Protocol is set to 0x01
      (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).

When is it ok to not discard the packet?  IOW, why is this action recommended
and not required?

This question came up during the ART review [1], *and* text was added about
optional configuration.  However, the behavior (without explicit configuration)
is still only recommended -- I'd like to understand in which cases it is ok to
not discard by default.

The opinion in [2] also caught my attention: "I don't have an objection to
discard by default packets with O bit set and next protocol = IP/MPLS/Ethernet".

[1] https://mailarchive.ietf.org/arch/msg/sfc/xkzr-BWsTsHT7q6KznMxXveflBw/
[2] https://mailarchive.ietf.org/arch/msg/sfc/Or3IHPNEP7R-NTQlN4PymL0s8tk/

(2) On the flip side (but independent of the last answer), if packets are, in
fact, dropped (either by default or configuration), a rogue node can set the O
bit while any packet is in transit.  I realize that the document says that "The
O bit MUST NOT be modified along the SFP.", but this threat should be added to
the security considerations for completeness.

(3)
      The processing (including the order) of the SFC OAM data
      SHOULD be specified in the relevant OAM or Context Header
      specification.

Why is this action not required?  Where else would it be specified?

(4)

     SFC-aware SF/SFF/SFC Proxy/Classifier implementations that
     do not support SFC OAM procedures SHOULD discard packets
     with O bit set, but MAY support a configurable parameter
     to enable forwarding received NSH OAM packets unmodified
     to the next element in the chain.

When is it ok to not discard the packet?  IOW, why is this action recommended
and not required?

This point is related to #1 above, but in this case, the recommendation is
given for SFC data plane elements that do not support SFC OAM procedures. 
While this text seems unchanged from rfc8300, what are the odds that these
nodes will support anything related to OAM (including any specifications about
what to do with the O bit)?  I would say "relatively low" -- what types of
"unexpected outcomes for others" can result?  Should they be within what a
rogue node can exploit (either by setting the O bit or ignoring this
specification)?

(5) From §5:  "Any data included in an NSH OAM packet SHOULD be
integrity-protected [RFC9145]."

Why is this action recommended and not required?  §9/rfc9145 lists a series of
threats and then requires integrity protection:

=====
   NSH data is exposed to several threats:

   *  An on-path attacker modifying the NSH data.

   *  An attacker spoofing the NSH data.

   *  An attacker capturing and replaying the NSH data.

   *  Data carried in Context Headers revealing privacy-sensitive
      information to attackers.

   *  An attacker replacing the packet on which the NSH is imposed with
      a modified or bogus packet.

   In an SFC-enabled domain where the above attacks are possible, (1)
   NSH data MUST be integrity protected and replay protected, and (2)
   privacy-sensitive NSH metadata MUST be encrypted for confidentiality
   preservation purposes.  The Base and Service Path Headers are not
   encrypted.
=====

Why isn't that same requirement applicable in the NSH OAM case?