Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt

[Greg Mirsky <[e-mail]>]

Hi Med,
I much appreciate your quick response to my questions. I've updated the
Authentication section in the draft. Please let me know if you agree with
the proposed text:
5.2.  Authentication in Echo Request/Reply

   Authentication can be used to protect the integrity of the
   information in SFC Echo Request and/or Echo Reply.  In the
   [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has
   been defined to protect the integrity of the NSH and the payload.
   The header can also be used for the optional encryption of the
   sensitive metadata.  MAC#1 Context Header is more suitable for the
   integrity protection of active SFC OAM, particularly of the defined
   in this document SFC Echo Request and Echo Reply.  On the other hand,
   using MAC#2 Context Header allows the detection of mishandling of the
   O-bit by a transient SFC element.

And I've accordingly updated draft-ao-sfc-oam-return-path specified and
draft-ao-sfc-oam-path-consistency also to refer to the
draft-ietf-sfc-nsh-integrity.
A couple of new notes logged in-line tagged GIM>>.

Regards,
Greg

On Tue, Jan 19, 2021 at 6:18 AM <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:[e-mail]]
> *Envoyé :* lundi 18 janvier 2021 18:04
> *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> *Cc :* Service Function Chaining IETF list <[e-mail]>;
> [e-mail]
> *Objet :* Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
>
>
>
> Hi Med,
>
> many thanks for your review and comments. I agree that the new
> Authentication TLV is not necessary.
>
> [Med] Glad to see that we are in agreement.
>
>
>
> You are right in pointing that an active SFC OAM protocol, e.g., SFP Echo
> Request/Reply defined in draft-ietf-sfc-multi-layer-oam, must use a MAC
> Header, as defined in draft-ietf-sfc-nsh-integrity. I have some questions
> about the draft-ietf-sfc-nsh-integrity:
>
>    - I think that the scope of the MAC#1 Context Header is more suitable
>    for the active OAM over an SFP.
>
> [Med] Actually, as the “payload” is modified by SFFs, MAC#2 would be more
> appropriate here. It also allows to detect misbehaving nodes that may unset
> the O-bit while they shouldn’t.
>
GIM>> Thank you for pointing that out. I agree that is beneficial and the
choice can be left up to an operator.

> At the same time, it appears that such use is not considered in the draft. For
> example, in Section 5.1 is noted that:
>
>    It does
>    not require to re-compute the MAC by each SFF because of TTL
>    processing.
>
>
>    - Also, I understand that encryption is optional and it not being in
>    use indicated by setting the value of the IV LEngth field to 0. But I
>    couldn't find the text that explains what must be done with the
>    Initialization Vector field.
>
> [Med] That field won’t be present. Will add explicit text to record this.
>
>  On the one hand, that is a variable-length field and thus must not be
> included in the header when the IV Length =0. On the other hand, I expect
> that three-octet-long padding should be applied, zeroed on the
> transmission, and ignored on the receipt. If that is what is expected,
> perhaps clarifying text in Section 5.1 could be added.
>
> [Med] We don’t mention padding as this is new a NEW requirement. Padding
> is assumed to be applied when appropriate as per Section 2.2 of RFC8300. We
> can add a reminder, though.
>
GIM>> Thank you. I agree that some clarifying text would be helpful.

>
>    - And another question is on how an SFC element, SFF, for example,
>    would realize that the particular must or must not include MAC context
>    header? In some protocols, the use of authentication/encryption
>    indicated in the packet, e.g., Authentication flag in the BFD control
>    message. Had the authors considered a similar method?
>
> [Med] As discussed in the draft, that is the responsibility of the control
> plane. Once a MAC# is imposed, downstream nodes will need to comply with
> the behavior for validating/updating the enclosed information.
>
GIM>> Please, correct me if I misunderstood the use of the MAC Context
Header. Once its presence in the NSH is signaled through the control plane,
it MUST be present in each NSH and it cannot be used intermittently.
Without comparing, from the experience with BFD authentication, we learned
that requiring authentication of each control message is burdensome and not
critical. A lighter approach where some messages are authenticated has been
developed by the BFD WG by introducing NULL Authentication. Do you think a
similar option could be useful in SFC NSH?

I'll update draft-ietf-sfc-multi-layer-oam as you've suggested.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 13, 2021 at 1:10 AM <[e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:[e-mail]]
> *Envoyé :* mardi 12 janvier 2021 22:28
> *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> *Cc :* Service Function Chaining IETF list <[e-mail]>;
> [e-mail]
> *Objet :* Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
>
>
>
> Hi Med,
>
> many thanks for your comment on the new Authentication TLV and the
> reference to draft-ietf-sfc-nsh-integrity. I've compared the scope of both
> integrity protection mechanisms and think that there is no functional
> duplication or overlap but they are rather complementary. Please correct me
> if my understanding of draft-ietf-sfc-nsh-integrity is not accurate. As I
> understood it, the proposed in Section 5 of the NSH Integrity Protection
> draft Variable-Length Context Headers secure only the NSH layer, not a
> payload.
>
>
>
> [Med] Actually, the payload is also covered. You may refer to these
> figures in Section 4.
>
>
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                Transport Encapsulation                |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>       |                Base Header                            |  |
>
>    +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
>
>    |  |                Service Path Header                    |  S
>
>    |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
>
>    |  |                Context Header(s)                      |  |
>
>    |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>    |  |                Original Packet                        |
>
>    +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |
>
>    +------Scope of integrity protected data
>
>
>
> and
>
>
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                Transport Encapsulation                |
>
>    +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>    |  |                Base Header                            |  |
>
>    |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
>
>    |  |                Service Path Header                    |  S
>
>    |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
>
>    |  |                Context Header(s)                      |  |
>
>    |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>    |  |                Original Packet                        |
>
>    +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |
>
>    +----Scope of integrity protected data
>
>
>
>
>
> The goal of the Authentication TLV is to protect the integrity of the SFC
> Echo Request, Echo Reply messages, and optional TLVs. The text over which
> HMAC is calculated includes fields only within the SFC Echo Request/Reply
> message. We can certainly add a text pointing out that the Authentication
> TLV and its use are independent of the use of context headers defined
> in draft-ietf-sfc-nsh-integrity.
>
> Also, would you suggest enhancing the text used by the Authentication TLV
> by including a field from the NSH Base or NSH Path headers?
>
>
>
> [Med] Protecting part of the NSH information is suboptimal as attacks are
> still possible by misbehaving nodes by altering some of these fields. I
> would just remove the Authentication TLV from the OAM draft and point to
> the integrity draft where these matters are discussed. Thank you.
>
>
>
> Best regards,
>
> Greg
>
>
>
>
>
> On Tue, Jan 12, 2021 at 2:08 AM <[e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Thank you for sharing this updated version.
>
>
>
> I have a comment about the new Authentication TLV. We used to have a
> similar discussion in the past: whether each TLV document has to include
> its own protection means or have a generic solution. Please check Slide 7
> of
> https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01.
> As a follow-up, the WG developed
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-02.
>
>
>
> I suggest to avoid duplicated functionality and refer to
> draft-ietf-sfc-nsh-integrity if integrity at the NSH level is required.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc [mailto:[e-mail]] *De la part de* Greg Mirsky
> *Envoyé :* mardi 15 décembre 2020 02:18
> *À :* Service Function Chaining IETF list <[e-mail]>;
> [e-mail]
> *Objet :* [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
>
>
>
> Dear All,
>
> in addition to a number of nits being fixed, updates in this version
> include:
>
>    - a change in the format of the TLV used in the SFC Echo
>    Request/Reply. The shorter Type field seems not to affect extensibility but
>    an additional one-octet-long filed can be used in some cases (one being the
>    new Authentication TLV);
>    - a new Authentication TLV that can be used to protect the base SFC
>    Echo Request/Reply as well as any optional TLV.
>
> Authors welcome your comments, questions, and suggestions.
>
>
>
> Regards,
>
> Greg
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Dec 14, 2020 at 5:10 PM
> Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
> To: <[e-mail]>
> Cc: <[e-mail]>
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
>
>         Title           : Active OAM for Service Function Chains in
> Networks
>         Authors         : Greg Mirsky
>                           Wei Meng
>                           Bhumip Khasnabish
>                           Cui Wang
>         Filename        : draft-ietf-sfc-multi-layer-oam-07.txt
>         Pages           : 22
>         Date            : 2020-12-14
>
> Abstract:
>    A set of requirements for active Operation, Administration and
>    Maintenance (OAM) of Service Function Chains (SFCs) in networks is
>    presented.  Based on these requirements, an encapsulation of active
>    OAM message in SFC and a mechanism to detect and localize defects
>    described.  Also, this document updates RFC 8300 in the definition of
>    O (OAM) bit in the Network Service Header (NSH) and defines how the
>    active OAM message is identified in SFC NSH.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-07
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>