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

[[e-mail]]

Hi Alvaro, 

Apologies for not pointing explicitly to the specific parts from the threads I quoted.

Anyway, your observation is a valid one. OAM data is not specific and should fall under the considerations set in RFC9145. However, please note that the "required" part you quoted is conditioned by "In an SFC-enabled domain where the above attacks are possible,". Specifically, depending on how OAM data is conveyed in the NSH and specifics of an SFC-enabled domain, the other protections in NSH may or may not be sufficient (e.g., transport security). SHOULD is there to cover cases where the alternate 8300 protection mechanisms are sufficient. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Alvaro Retana <[e-mail]>
> Envoyé : jeudi 16 mars 2023 17:20
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : RE: Alvaro Retana's No Objection on draft-ietf-sfc-oam-
> packet-02: (with COMMENT)
> 
> On March 15, 2023 at 4:16:59 AM, [e-mail]
> wrote:
> 
> Med:
> 
> Hi!
> 
> I'm ok with your replies, but I do want to ask about #5 again:
> 
> 
> ...
> > > (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.
> 
> I remember that discussion, but I'm asking something different --
> at least trying to. ;-)
> 
> 
> Let me rephrase:
> 
> The text from §9/rfc9145 (pasted below) requires integrity
> protection when "NSH data is exposed to several threats".  But the
> text in this draft only recommends it.  Are OAM packets not
> exposed to the same threats?  If they are, why wouldn't the same
> requirement be applicable here?
> 
> I don't see a difference between OAM packets and any other
> packets, but I may be missing something.  Even if the use of
> rfc9145 is optional (as we discussed before), I would still like
> to understand the difference in criteria.
> 
> If those differences exist, it would help implementations when
> considering when it may be ok to not use integrity protection.
> 
> 
> Thanks!
> 
> Alvaro.
> 
> 
> > > =====
> > > 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.
> > > =====

_________________________________________________________________________________________________________________________

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.