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

[[e-mail]]

Hi Alvaro, 

Thank you for the careful review.  Appreciated as usual!

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alvaro Retana via Datatracker <[e-mail]>
> Envoyé : mardi 14 mars 2023 19:35
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Alvaro Retana's No Objection on draft-ietf-sfc-oam-packet-
> 02: (with COMMENT)
> 
> 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?

[Med] When there is a local configuration. 

  IOW, why is this action
> recommended
> and not required?

[Med] The discard action is required but only when there is no instruction to do otherwise. We are not using MUST here as I was convinced in the past that constructs such as "MUST xx, except ..." are not correct and this should be "SHOULD". 

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

[Med] That part was already in RFC8300, and thus this is not listed as a new issue. We point to Section 8 of 8300, which already have the following: 

      Operators SHOULD regularly monitor (i.e.,
      continuously audit) these devices to help ensure compliant
      behavior.

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

[Med] Because there is already a default behavior in RFC8300:

   If no instructions are
   provided and the SFC-aware SF will make use of or modify the specific
   Context Header, then the SFC-aware SF MUST process these Context
   Headers in the order they appear in an NSH packet.


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

[Med] This text uses "SHOULD .., but MAY" construct rather than "MUST..., but MAY" as in #1. FWIW, we specifically discussed this with Adrian here https://mailarchive.ietf.org/arch/msg/sfc/TeVgb9eNf0-7W9hU7pOMaN6Mmic/.

  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,

[Med] I confirm that it is inherited 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)?

[Med] We had lengthy discussion in the WG during the development of RFC8300 before we agreed to disable by default when an entity does not support the O bit + leave the assessment out of scope. I don't think we need to reopen this. Thanks.  

> 
> (5) From §5:  "Any data included in an NSH OAM packet SHOULD be
> integrity-protected [RFC9145]."
> 
> Why is this action recommended and not required?

[Med] I remember we discussed this point with you here: https://mailarchive.ietf.org/arch/msg/sfc/rPsqPUisDj3lILJk-CVF-ejBrVg/. Please see also https://mailarchive.ietf.org/arch/msg/sfc/yC-3dN6jvyxZNZY9EYz3XIUlJMs/. The wording in the spec is consistent with the positions expressed there. Thanks.


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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.