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

Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:gregimirsky@gmail.com]
Envoyé : mardi 12 janvier 2021 22:28
À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
Cc : Service Function Chaining IETF list <sfc@ietf.org>; sfc-chairs@ietf.org
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 <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> 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:sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>] De la part de Greg Mirsky
Envoyé : mardi 15 décembre 2020 02:18
À : Service Function Chaining IETF list <sfc@ietf.org<mailto:sfc@ietf.org>>; sfc-chairs@ietf.org<mailto:sfc-chairs@ietf.org>
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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Mon, Dec 14, 2020 at 5:10 PM
Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-07.txt
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Cc: <sfc@ietf.org<mailto:sfc@ietf.org>>

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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
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.