Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[Qin Wu <[e-mail]>]

Thanks Acee and Dhruv for suggested changes and check on the following two issues.
See reply inline below.
发件人: Acee Lindem (acee) [mailto:[e-mail]]
发送时间: 2022年8月25日 21:49
收件人: Dhruv Dhody <[e-mail]>; Qin Wu <[e-mail]>
抄送: John Scudder <[e-mail]>; [e-mail]; [e-mail]
主题: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Speaking as document shepherd and WG member:

Hi John, Qin, and Dhruv,

See a couple inlines.

From: Lsr <[e-mail]<mailto:[e-mail]>> on behalf of Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 25, 2022 at 7:02 AM
To: Qin Wu <[e-mail]<mailto:[e-mail]>>
Cc: John Scudder <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

Hi Qin, John,

I have added my comments for two issues, please see inline (look for Dhruv:)


On Thu, Aug 25, 2022 at 2:52 PM Qin Wu <bill.wu=[e-mail]<mailto:[e-mail]>> wrote:
Hi, John:
Thanks for your valuable AD review. We have incorporate your comments into draft-ietf-lsr-pce-discovery-security-support-10.
Regarding the issues your raised below, please reply inline below.

-Qin (on behalf of authors)
发件人: John Scudder [mailto:[e-mail]<mailto:[e-mail]>]
发送时间: 2022年8月18日 8:41
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: AD review of draft-ietf-lsr-pce-discovery-security-support-09

Dear Authors,

Thanks for you patience as this document sat in my queue for too long. :-( Here’s my review.

I’ve supplied my comments in the form of an edited copy of the draft. Minor editorial suggestions I’ve made in place without further comment, more substantive comments are done in-line and prefixed with “jgs:”. You can use your favorite diff tool to review them; I’ve attached a PDF of the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply. I’d appreciate feedback regarding whether you found this a useful way to receive my comments as compared to a more traditional numbered list of comments with selective quotation from the draft.

Thanks,

—John


--- draft-ietf-lsr-pce-discovery-security-support-09.txt        2022-08-17 15:35:47.000000000 -0400
+++ draft-ietf-lsr-pce-discovery-security-support-09-jgs-comments.txt   2022-08-17 20:37:48.000000000 -0400
@@ -13,14 +13,14 @@
                                                           21 August 2021


-IGP extension for PCEP security capability support in the PCE discovery
+IGP extension for PCEP security capability support in PCE discovery
             draft-ietf-lsr-pce-discovery-security-support-09

 Abstract

    When a Path Computation Element (PCE) is a Label Switching Router
    (LSR) participating in the Interior Gateway Protocol (IGP), or even a
-   server participating in IGP, its presence and path computation
+   server participating in the IGP, its presence and path computation
    capabilities can be advertised using IGP flooding.  The IGP
    extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
    to advertise path computation capabilities using IGP flooding for
@@ -28,10 +28,10 @@
    method to advertise PCEP security (e.g., Transport Layer Security
    (TLS), TCP Authentication Option (TCP-AO)) support capability.

-   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
+   This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV
    that can be announced as an attribute in the IGP advertisement to
    distribute PCEP security support information.  In addition, this
-   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
+   document updates RFC 5088 and RFC 5089 to allow advertisement of a Key
    ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
    RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
    movement of the IANA "PCE Capability Flags" registry.
@@ -100,7 +100,7 @@
 1.  Introduction

    As described in [RFC5440], PCEP communication privacy is one
-   importance issue, as an attacker that intercepts a Path Computation
+   important issue, as an attacker that intercepts a Path Computation
    Element (PCE) message could obtain sensitive information related to
    computed paths and resources.

@@ -114,14 +114,14 @@
 Internet-Draft       IGP discovery for PCEP Security         August 2021


-   Among the possible solutions mentioned in these documents, Transport
+   Among the possible solutions mentioned in that document, Transport
    Layer Security (TLS) [RFC8446] provides support for peer
    authentication, and message encryption and integrity while TCP
    Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms
    for TCP-AO [RFC5926] offer significantly improved security for
    applications using TCP.  As specified in section 4 of [RFC8253], in
    order for a Path Computation Client (PCC) to establish a connection
-   with a PCE server using TLS or TCP-AO, PCC needs to know whether PCE
+   with a PCE server using TLS or TCP-AO, the PCC needs to know whether the PCE
    server supports TLS or TCP-AO as a secure transport.

    [RFC5088] and [RFC5089] define a method to advertise path computation
@@ -129,10 +129,10 @@
    However these specifications lack a method to advertise PCEP security
    (e.g., TLS) support capability.

-   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
+   This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV
    that can be announced as attributes in the IGP advertisement to
    distribute PCEP security support information.  In addition, this
-   document updates RFC5088 and RFC5089 to allow advertisement of Key ID
+   document updates RFC5088 and RFC5089 to allow advertisement of a Key ID
    or Key Chain Name Sub-TLV to support TCP-AO security capability.

    Note that the PCEP Open message exchange is another way to discover
@@ -171,7 +171,7 @@


    Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
-   discovery using IS-IS.  This document will use the same flag for the
+   discovery using IS-IS.  This document will use the same flags for the
    OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP
    Authentication Option (TCP-AO) support, PCEP over TLS support
    respectively.
@@ -191,20 +191,54 @@
    *  PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS
       support flag bit.

-   If PCE supports multiple security mechanisms, it SHOULD include all
-   corresponding flag bits in IGP advertisement.
+   If the PCE supports multiple security mechanisms, it SHOULD include all
+   corresponding flag bits in its IGP advertisement.

    If the client is restricted to a PCE server with TCP-AO support, the
-   client MUST check if TCP-AO support flag bit in the PCE- CAP-FLAGS
+   client MUST check if the TCP-AO support flag bit in the PCE-CAP-FLAGS
    sub-TLV is set.  If not, the client SHOULD NOT consider this PCE.  If
    the client is restriced to a PCE server using TLS, the client MUST
    check if PCEP over TLS support flag bit in the PCE-CAP-FLAGS sub-TLV
    is set.  If not, the client SHOULD NOT consider this PCE.  Note that
    this can be overridden based on a local policy at the PCC.
+
+jgs: The above paragraph seems to be conflicted. You start with "if the
+client is restricted to... TCP-AO".  Restriction implies that AO MUST be
+supported, that's the meaning of the word "restrict".  But yet, you only
+say the client SHOULD NOT use the PCE if AO isn't supported.  That's not
+"restriction".
+
+I do appreciate that you add a note in the last sentence to say that the
+SHOULD NOT might be overcome by local configuration.  But... that
+basically means local configuration could disable the restriction.
+
+Let me suggest another paragraph that I think would capture what I
+understand to be your intent, without creating a dissonance in your
+use of RFC 2119 keywords.  Feel free to take it as written, edit it,
+write your own, or disagree completely (in which latter case, let's
+discuss further please).
+
+   A client's configuration MAY indicate that support for a given
+   security capability is required.  If a client is configured to
+   require that its PCE server support TCP-AO, the client MUST verify
+   that the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given
+   server is set before it opens a connection to that server.
+   Similarly, if the client is configured to require that its PCE server
+   support TLS, the client MUST verify that the PCEP over TLS support
+   flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set
+   before it opens a connection to that server.
+
+I'm sure it would be possible to tune or polish further, if someone
+wants to.  I left out the "note that" sentence, because IMO it's
+implied by the first sentence of the rewrite.
+
[Qin Wu] The proposed changes to section 3.1 look good to authors, we have integrated in v-10 (See attached)

+jgs: I don't find any place where you explicitly mention that the
+sub-TLVs you define are identical for both OSPF and IS-IS. Please
+do make this explicit.

[Qin Wu] We authors add explicit statement in section 3 to say
“

   In addition, the sub-TLVs defined in this document (i.e.,Section 3.2,
Section 3.3) are used identically in both OSPF and IS-IS.
”
Hope this addresses your comment.

 3.2.  KEY-ID Sub-TLV

-   The KEY-ID sub-TLV specifies a key that can be used by the PCC to
+   The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to
    identify the TCP-AO key [RFC5925].

    The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within
@@ -233,6 +267,14 @@

       Reserved: MUST be set to zero while sending and ignored on
       receipt.
+
+jgs: what is the size of the Reserved field?  I'm guessing it's three
+octets, to align the sub-TLV to a word boundary, but you need to say.
+[Qin Wu] Yes, it can be inferred from 4 octets length and 1 octet KEY ID.
But we can make it explicitly.
+A diagram of the style used in RFC 5088 would make this more evident
+since presumably you'd show the Reserved field in the diagram.  I
+don't insist you add diagrams, but they do tend to help the document's
+readability so maybe consider it for this and also §3.3.
 [Qin Wu] This has been discussed on the list before, it is intentional not use diagram
for IGP since OSPF uses diagram for TLV format while ISIS not.

 3.3.  KEY-CHAIN-NAME Sub-TLV

@@ -241,9 +283,9 @@

    The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried
    within the IS-IS Router Information Capability TLV when the
-   capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to
+   capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to
    indicate TCP Authentication Option (TCP-AO) support.  Similarly, this
-   sub-TLV MAY be present in the PCED TLV carried within OSPF Router
+   sub-TLV MAY be present in the PCED TLV carried within the OSPF Router
    Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV
    in OSPF is set to indicate TCP-AO support.

@@ -257,6 +299,57 @@
       identify the key chain.  It SHOULD be a string of printable ASCII
       characters, without a NULL terminator.  The sub-TLV MUST be zero-
       padded so that the sub-TLV is 4-octet aligned.
+
+jgs: Shouldn't your SHOULD be a MUST? If not, what are the non-ASCII
+characters that are allowed, and under what circumstances?
+
+For that matter, why are you restricting the key chain name to ASCII?
+You cite RFC 8177 above. Looking at 8177, it defines a key-chain name
+as a YANG string, and RFC 7950 tells us that for a YANG string:
+
+   Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
+   characters, including tab, carriage return, and line feed but
+   excluding the other C0 control characters, the surrogate blocks, and
+   the noncharacters.
+
+If you really do want to restrict the alphabet in your extension, I
+think you need to explain why, or otherwise you need to support the
+same alphabet RFC 8177 does.

[Qin Wu]: Okay.We can align with what RFC8177 does.

Dhruv: I am not sure "It MUST be a string" is enough. How about ->

 It MUST be encoded using UTF-8.  A receiving entity MUST NOT interpret
 invalid UTF-8 sequences. This field is not NUL terminated. UTF-8
 "Shortest Form" encoding is REQUIRED to guard against the technical
 issues outlined in [UTR36].

Acee: I agree that this is better and it is certainly ok to provide better specification than RFC 8177.

[Qin Wu-2]: Okay, I will integrate the above proposed text. Thanks!
+Next question, what does the Length field indicate, exactly?  Is it the
+length of the string?  Presumably so, since there is no termination
+character.  Please say so, and say what the units are (e.g., "Length:
+length of the Key Name field, in octets").
+
+Finally, at the end of the description of the Key Name field, you say
+"The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned."
+Since we've already established that the Length field must indicate the
+Key Name field length, what tells the parser how many bytes of padding
+are present? Is it just supposed to know, based on whether the Key Name
+field falls on a word boundary or not? Because, the Length field isn't
+going to tell it.
+
+Perhaps all OSPF and IS-IS TLV parsers are robust to this kind of format;
+if so let's discuss. But Occam's Razor suggests that the format documented
+here isn't quite right, and that it should be something more like:
+
+       Type: 7
+       Length: Variable
+       Key Name:
+               String Length: one octet whose value is the number of octets
+                                          in the Key Name
+               String: zero or more characters of (whatever the supported
+                           alphabet is).
+       Padding: 0-3 octets of padding, such that the sub-TLV is 4-octet
+                    aligned.
+
+So there are two length fields: one is the usual TLV length field, that
+tells you the size of the value portion. The other is the string length,
+and it's needed because you're going to add 0-3 bytes of padding. If you
+didn't use the padding, you could get away with a single length field,
+but since you do have padding, you need both fields, it seems.
+
+That obviously isn't a finished description but it gives you the idea.

[Qin Wu] We authors believe your questions can be interpret as two sub-questions as follow:
1. Does it include the Type and Length, or just the Key Name?
2. Does it count the number of bytes of Key Name, or also include the trailing pad bytes?

Our answer is:

The Length field indicates the length in octets of the Key Name field excluding any trailing zero pad bytes.

Since we already have the statement of "The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned."
We don't need anything further. Although, we presumably don't want an arbitrary number of trailing zero bytes,
so we could say...

The sub-TLV MUST be zero-padded with 0, 1, 2, or 3 zero octets so that the sub-TLV is 4-octet aligned.
Acee: I’m not sure this is necessary since this OSPF TLV encoding with padding to a 4-octet boundary is ubiquitous and has only come into question when encountered for the first time. However, I don’t feel that strongly.
[Qin Wu-2]: If this is true, I think we can fall back to the original text.

Does this address your comment above.

 4.  Update to RFC5088 and RFC5089

@@ -282,9 +375,9 @@
 Internet-Draft       IGP discovery for PCEP Security         August 2021


-   The introduction of the additional sub-TLVs should be viewed as an
-   exception to the [RFC5088][RFC5089] policy justified by the
-   requirements to discover the PCEP security support prior to
+   This introduction of additional sub-TLVs should be viewed as an
+   exception to the [RFC5088][RFC5089] policy, justified by the
+   requirement to discover the PCEP security support prior to
    establishing a PCEP session.  The restrictions defined in
    [RFC5089][RFC5089] should still be considered to be in place.

@@ -292,8 +385,23 @@
    [RFC8231], section 6.9 of [RFC8306], and section 11.1 of [RFC8623]
    has changed to the IGP Parameters "Path Computation Element (PCE)
    Capability Flags" registry created in this document.
+
+jgs: I'm confused by this paragraph, both why we need it and the details.
+
+First, I think you have the wrong section reference for RFC 8231,
+shouldn't it be Section 8.1?

+[Qin Wu] Correct, I have fixed this.
+But in any case, since you aren't changing the name of the registry to
+be something other than "Path Computation Element (PCE) Capability
+Flags", I don't think you need to provide these details.  People looking
+for the registry should still be able to find it.
+
[Qin Wu] We authors think it is important that readers of RFC 8231 should be able to find the registry originally defined in that document.
We also believe it is important for implementers of RFC 8306 and RFC 8623 to know that the code points defined in those documents are now housed in a registry.
You are correct that no other part of this document forms an update to those other RFCs. Here are a few proposed changes to abstract:
The Abstract should have:

This document Updates RFC 8231 to move the IANA "PCE Capability Flags" registry to be housed under the IANA Common IGP Parameters registry.
2. This document Updates RFC 8306 and 8623 to create a registry to contain the PCE Sub-TLVs that they define.
This text needs to also be in the Introduction.
Let us know if addition text or clarifications are needed.

Dhruv: I think the point 2 here is incorrect. There RFC only creates new bits in the capability flag. Here is my suggested text change ->


YOUR:
This document also updates RFC 8231 to move the IANA "PCE Capability
Flags" registry to be housed under the IANA Common IGP Parameters
registry.  Further, this document updates RFC 8306 and 8623 to create
a registry to contain the PCE Sub-TLVs that they define.

SUGGESTION:
As per [RFC5088], the IANA created a new top-level OSPF registry, the
"Path Computation Element (PCE) Capability Flags" registry. This
documents update [RFC5088] and moves the registry to "Interior
Gateway Protocol (IGP) Parameters". This document updates [RFC5557]
to change the term "OSPF registry" to "IGP registry". This document
updates [RFC8306] where it uses the term "OSPF PCE Capability Flag" and
request assignment from OSPF Parameters registry with "PCE
Capability Flag" and the IGP Parameters registry. Further, this
document updates [RFC8231] where it references the registry location as
"Open Shortest Path First (OSPF) Parameters" registry to "Interior
Gateway Protocol (IGP) Parameters" registry. This document updates
[RFC8623] and [RFC9168] where it uses the term OSPF Parameters to IGP
Parameters.

We would also need to add RFC5557 and RFC9168 in the update list.

Acee: I like this precise specification of the IANA action. I’d remove the word “new” from the first sentence and I don’t think that changing the registry name would constitute an update to RFC 5557 and RFC 9168.

[Qin Wu-2] Thank for proposed text, I will use Acee’s tweaked text and will not add two additional RFCs in the updated list. Thanks!
Thanks,
Acee


Thanks!
Dhruv



+In short I suggest removing the paragraph, and removing RFCs 8231,
+8306, and 8623 from the Updates: header. (Then also update the Abstract
+and references accordingly.)  If you think we shouldn't make this change,
+let's discuss.

-5.  Backward Compatibility Consideration
+5.  Backward Compatibility Considerations

    An LSR that does not support the IGP PCE capability bits specified in
    this document silently ignores those bits.
@@ -307,7 +415,7 @@
 6.  Management Considerations

    A configuration option may be provided for advertising and
-   withdrawing PCEP security capability via OSPF and IS-IS.
+   withdrawing the PCEP security capability via OSPF and IS-IS.

 7.  Security Considerations

@@ -317,18 +425,31 @@
    The information related to PCEP security is sensitive and due care
    needs to be taken by the operator.  This document defines new
    capability bits that are susceptible to a downgrade attack by
-   toggling them.  The content of Key ID or Key Chain Name Sub-TLV can
-   be tweaked to enable a man-in-the-middle attack.  Thus before
+   setting them to zero.  The content of Key ID or Key Chain Name Sub-TLV can
+   be altered to enable a man-in-the-middle attack.  Thus before
    advertising the PCEP security parameters, using the mechanism
    described in this document, the IGP MUST be known to provide
    authentication and integrity for the PCED TLV using the mechanisms
    defined in [RFC5304], [RFC5310] or [RFC5709].

    Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does not
-   provide any encryption mechanisms to protect the secrecy of the PCED
+   provide any encryption mechanisms to protect the confidentiality of the PCED
    TLV, then the operator must ensure that no private data is carried in
    the TLV, e.g. that key-ids or key-chain names do not reveal sensitive
    information about the network.
+
+jgs: Is this really an "if"? Are there any standardized ways to protect
+confidentiality (probably a better word than "secrecy", by the way, so
+I've suggested an edit above) of IGP contents? I'm not aware of any, and
+indeed RFC 5088 and RFC 5089 clearly say there aren't. If there are any
+feasible solutions, please cite them here. Otherwise, maybe an edit like
+
+   Moreover, as stated in the Security Considerations of [RFC5088] and
+   [RFC5089], there are no mechanisms defined in OSPF or IS-IS to
+   protect the confidentiality of the PCED TLV. For this reason, the
+   operator must ensure that no private data is carried in the TLV, e.g.
+   that key-ids or key-chain names do not reveal sensitive information
+   about the network.

 [Qin Wu] Make sense, thanks for proposed change.

@@ -342,29 +463,34 @@

 8.1.  PCE Capability Flag

-   IANA is requested to move the "PCE Capability Flags" registry from
-   "Open Shortest Path First v2 (OSPFv2) Parameters" to under the IANA
-   Common IGP parameters registry and allocate new bits assignments for
-   the IGP Parameters "Path Computation Element (PCE) Capability Flags"
-   registry.
+   IANA is requested to move the "Path Computation Element (PCE)
+   Capability Flags" registry from the "Open Shortest Path First v2 (OSPFv2)
+   Parameters" grouping to the "Interior Gateway Protocol (IGP) Parameters"
+   grouping.
+
+   IANA is requested to make the following assignments from the
+   "Path Computation Element (PCE) Capability Flags" registry.

-        Bit           Meaning                 Reference
+        Bit           Capability Description  Reference
         xx            TCP-AO Support          [This.I.D]
         xx            PCEP over TLS support   [This.I.D]

-   The registry is located at: https://www.iana.org/assignments/igp-
+   The grouping is located at: https://www.iana.org/assignments/igp-
    parameters/igp-parameters.xhtml

+jgs: The URL is fine I guess, although unusual and not necessary to
+include in an IANA Considerations section.
+[Qin Wu] Okay.
 8.2.  PCED sub-TLV Type Indicators

    The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they
    did not create a registry for it.  This document requests IANA to
-   create a new subregistry called "PCED sub-TLV type indicators" under
-   the "Interior Gateway Protocol (IGP) Parameters" registry.  The
-   registration policy for this subregistry is "IETF Review" [RFC8126].
-   Values in this subregistry come from the range 0-65535.
+   create a new registry called "PCED sub-TLV type indicators" under
+   the "Interior Gateway Protocol (IGP) Parameters" grouping.  The
+   registration policy for this registry is "IETF Review" [RFC8126].
+   Values in this registry come from the range 0-65535.

-   This subregistry should be populated with:
+   This registry should be populated with:

         Value         Description             Reference
         0             Reserved                [This.I.D][RFC5088]
@@ -376,9 +502,13 @@
         6             KEY-ID                  [This.I.D]
         7             KEY-CHAIN-NAME          [This.I.D]

-   This registry is located at: https://www.iana.org/assignments/igp-
-   parameters/igp-parameters.xhtml and used by both OSPF PCED TLV and
-   IS-IS PCED sub-TLV.
+   This registry is used by both the OSPF PCED TLV and the IS-IS PCED
+   sub-TLV.
+
+   This grouping is located at: https://www.iana.org/assignments/igp-
+   parameters/igp-parameters.xhtml.
+
+jgs: Same comment regarding the URL.

 9.  Acknowledgments

@@ -518,7 +648,34 @@
 Appendix A.  No MD5 Capability Support

    To be compliant with Section 10.2 of RFC5440, this document doesn't
-   consider adding capability for TCP-MD5.  Therefore by default, a PCEP
+   consider adding capability for TCP-MD5.
+
+jgs: I don't get how NOT having a TCP-MD5 capability is a requirement
+for compliance with RFC 5440 §10.2. Maybe you're saying that TCP-MD5 is
+a baseline Mandatory-To-Implement algorithm and therefore it doesn't
+require signaling? But what about a possible future scenario where
+another specification updates RFC 5440 to remove the TCP-MD5
+requirement? At that point, it would be necessary to add a flag to
+signal MD5 support. So why not define it now, and start rolling it out
+now? Seems like it would make cleanly deprecating MD5 in the future,
+easier.
+
+If the flag were in the base version of this document, if you saw a PCE
+advertise PCE-CAP-FLAGS that include either the AO or TLS flags, and NOT
+the MD5 flag, you could infer that MD5 was not supported. If neither the
+AO nor the TLS flag, nor the MD5 flag, was advertised, it might be
+because the advertising PCE doesn't support this specification at all,
+so MD5 might be supported, and I can see using this appendix to report
+that detail.
+
+Forgive me if the question of MD5 has already been discussed by the WG
+and this option considered already, I'd be happy to be pointed at the
+relevant mail archives if that's the case.
+
+In any case, let's please have a conversation so I can, at minimum,
+understand what this section is trying to say.
+
[Qin Wu] After discussion among our authors, We authors agree with your concern. But is it necessary to define new flag bit for TCP-MD5, we feel not neededsince TCP MD5 has a lot of security concern.
We could move this into the Security Considerations section and delete the Appendix.
In the security section, We could add one paragraph to say as follows:
“
As described in Section 10.2 of [RFC5440], an PCEP speaker MUST support TCP MD5 [RFC2385], so no capability advertisement is needed to indicate support. However, as noted in [RFC6952], TCP MD5 has been obsoleted by TCP-AO [RFC5925] because of security concerns. However, TCP-AO is not widely implemented and so it is, therefore, RECOMMENDED (per [RFC8253] which updates [RFC5440]) that PCEP is secured using TLS. In any case, an implementation SHOULD offer at least one of the two security capabilities defined in this document.

“




+   Therefore by default, a PCEP
    Speaker supports the capability for TCP-MD5 (See section 10.2,
    [RFC5440]).  A method to advertise TCP-MD5 Capability support using
    IGP flooding is not required.  If the client is looking for a PCE
@@ -528,6 +685,10 @@
    which security capability (e.g., TCP-MD5) is selected, the same key-
    ids or key-chain names on the PCC and PCE server should be
    configured.
+
+jgs: Is that last sentence "Irrespective of..." trying to say that
+the key-id or keychain can be used to select MD5 keys as well? If so,
+that deserves to be said more clearly.
 [Qin Wu] See above.
 Authors' Addresses

_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr