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

[[e-mail]]

Hi Greg,

Looks good to me. Thanks.

Cheers,
Med

De : Greg Mirsky [mailto:[e-mail]]
Envoyé : mardi 19 janvier 2021 18:32
À : 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,
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]<mailto:[e-mail]>> wrote:
Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Envoyé : lundi 18 janvier 2021 18:04
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]<mailto:[e-mail]>>
Cc : Service Function Chaining IETF list <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Envoyé : mardi 12 janvier 2021 22:28
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]<mailto:[e-mail]>>
Cc : Service Function Chaining IETF list <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>] De la part de Greg Mirsky
Envoyé : mardi 15 décembre 2020 02:18
À : Service Function Chaining IETF list <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[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<http://tools.ietf.org>.

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


_______________________________________________
sfc mailing list
[e-mail]<mailto:[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.



_________________________________________________________________________________________________________________________

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.