Re: [secdir] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

"Yemin (Amy)" <amy.yemin@huawei.com> Fri, 22 February 2019 09:58 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB45124BF6; Fri, 22 Feb 2019 01:58:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJd6MojXkx4W; Fri, 22 Feb 2019 01:58:36 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21573124D68; Fri, 22 Feb 2019 01:58:35 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 87217FD0604ADCFB3C26; Fri, 22 Feb 2019 09:58:32 +0000 (GMT)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 22 Feb 2019 09:58:32 +0000
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 22 Feb 2019 09:58:31 +0000
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 22 Feb 2019 09:58:31 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.114]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Fri, 22 Feb 2019 17:58:25 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Sandra Murphy <sandy@tislabs.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
Thread-Index: AQHUuqwWHpLws/0qnkGGhYcJXbfKyaXk9tGggAa5hMA=
Date: Fri, 22 Feb 2019 09:58:25 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com>
References: <154908012600.28521.5714645741731093529@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.169.30.234]
Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CDDGGEMM528MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/w0x2mk0bOGBnCLGUT4VCcNgDYSM>
Subject: Re: [secdir] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 09:58:40 -0000

Hi Sandra,

Many thanks for the detail review comments, please see reply inline below.
And I’m very sorry for the late reply.

BR,
Amy

-----Original Message-----
From: Sandra Murphy [mailto:sandy@tislabs.com]
Sent: Saturday, February 02, 2019 12:02 PM
To: secdir@ietf.org<mailto:secdir@ietf.org>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org<mailto:draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>
Subject: Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13



Reviewer: Sandra Murphy

Review result: Has Issues



I have reviewed this document draft-ietf-ccamp-rsvp-te-bandwidth-availability

as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.



This draft provides a new TLV for the Ethernet SENDER_TSPEC object that will carry availability requirements for RSVP-TE signaling of GMPLS LSPs.



The draft is thorough.  I do have some comments.  I reviewed the normative references RFCs 2205, 3209, 3473, 6003, as well as RFC3945 and RFC5920.  I can’t claim that I understood everything in that stack, so the following could easily be wrong.



Computing the LSP path:



Page 4, section 2 discusses obtaining network topology, calculating the LSP route, RFC8330’s extensions for availability in OSPF TE LSA messages.  Does this draft assume that this extension will always be used with an EXPLICIT_ROUTE object?  Is this draft not applicable without that explicit LSP route calculation?

[Amy] No, there's no assumption that the extension can be only used with an EXPLICIT_ROUTE object.  The node who obtains network topology, calculates the LSP route, could be a source node and intermediate nodes.

Availability TLV vs CLASSTYPE objects:



The definition in RFC6003 of the Bandwidth Profile TLV has certain constraints on the values of the Index:

                         The Index field value MUST correspond to at least one

      of the Class-Type values included either in the CLASSTYPE object

      [RFC4124] or in the EXTENDED_CLASSTYPE object [MCOS].



I am not certain if this means that the presence of an Ethernet SENDER_TSPEC Object with a Bandwidth Profile TLV means there must be a CLASSTYPE object in the RSVP-TE message as well, or that the Index field values are taken from the set of defined Class-Type values.



But if the first, does this induce requirements by inclusion of the Availability TLV that these other CLASSTYPE objects must be included as well?

Or are you intending to update RFC6003 to eliminate that constraint?  If the second, does the RFC6003 constraint also constrain the index values used in the Availability TLV?  Should that be mentioned?  (Or am I just confused?)

[Amy] It’s the second case. The RFC6003 constraint should also apply to the index values used in the Availability TLV. The current text states that “having the same value of Index field”, which implies the same constraint.



Bandwidth TLV to Availability TLV association:



Page 4, Section 3.1 says



      When the Availability TLV is included, it MUST be present along

      with the Ethernet Bandwidth Profile TLV. If the bandwidth

      requirements in the multiple Ethernet Bandwidth Profile TLVs have

      different Availability requirements, multiple Availability TLVs

      SHOULD be carried. In such a case, the Availability TLV has a one

      to one correspondence with the Ethernet Bandwidth Profile TLV by

      having the same value of Index field. If all the bandwidth

      requirements in the Ethernet Bandwidth Profile have the same

      Availability requirement, one Availability TLV SHOULD be carried.

      In this case, the Index field is set to 0.



I find that the description is not clear in all cases.  I found a message in the working group discussion of this association that the association is either “n:n” or “n:1”.  I think this description sounds more like n 1:1 associations

or a  n:1 association.   Is that what is intended?  Can the associations be

mixed in the same message?  Suppose there were 3 Bandwidth TLVs that needed the same availability and one that had a different availability need, could there be 3 Bandwidth TLVs with index 0 and one Availability-TLV with index 0 and also a Bandwidth TLVs - Availability TLV pair with matching index values?

[Amy] Thanks for looking into the past discussion. The intension was n*(1:1) association or n:1 association. It was not so accurate by using “n:n” association in the past.

Regarding the example you list, if the four Bandwidth TLVs are sent in the same message, it’s better to use four different index values as they are “multiple Ethernet Bandwidth Profile TLVs have different Availability requirements”.

Of course what you proposed could also work technically.



error checking:



Other documents in the references (RFC2205, 3209, 3473, 6003, etc) have made a point of explicitly describing the error handling - when PathErr and ResvErr and Notify messages are sent, to whom, the error codes, the error value sub-codes, etc.  I don’t see that here for the bandwidth-tlv-to-availability-tlv associations.

[Amy] Thanks for the comment, I agree the error process should be clearer.

Is a mix of index-zero and index-non-zero bandwidth-tlv-to-availability-tlv associations (like above) an error? is the message dropped?  is an error sent?

if the message is not dropped, are any of the bandwidth-tlv, availability-tlv associations retained?

[Amy] The message MAY be ignored and SHOULD NOT be propagated.

If there are availability-tlvs with non-zero indexes with no matching index value among the bandwidth-tlvs, that surely is an error?  Is the message dropped?  Or is the availability tlv dropped?  Is a PathErr/ResvErr message sent?

[Amy] yes, this is an error. It’s preferred to drop the availability tlv.

Suppose all availability-tlvs have a matching (zero or non-zero) index value among the bandwidth-tlvs, but there are extra bandwidth-tlvs (no availability-tlv with a matching index value).  Is that an error?  Are the extra bandwidth-tlvs dropped? ignored? propagated?

[Amy]The extra bandwidth-tlvs MAY be ignored and SHOULD NOT be propagated.

(RFC3209 has several cases where there might be extra objects or sub-objects and the language is “can be/MAY be/SHOULD be/are ignored and SHOULD NOT be /are not/need not be propagated” )





multiplicity:



RFC3209 says it does not apply to multicast, but it does talk about multiple parallel LSP tunnels between two nodes, and about multipoint-to-point LSPs for WF and SE style reservations when there are multiple senders, and about the merging rules of WF reservations.  Does availability work in those style reservations?

[Amy] Considering that the traffic from senders is more likely to be concurrent and independent, the availability TLV can be limited to Fixed Filter (FF) Style only.

availability vs “variable discrete bandwidth”:



I believe I understood the discussion of the need to signal availability requirements in order for the system to determine when an LSP was feasible.  I can dimly understand that there might be links have “variable discrete bandwidth”.  Section 2 says “The Availability TLV can be applicable to any kind of physical links with variable discrete bandwidth, such as microwave or DSL.”

Why not other link types? Do only “variable discrete bandwidth” links support availability?

[Amy] To our current knowledge, only“variable discrete bandwidth” links support availability.



calculating availability:



In page 9, Appendix A:



Perhaps I don’t understand how the availability metric is used.  In the

following:



   On a sunny day, the modulation level 3 can be used to achieve 400

   Mbps link bandwidth.



   A light rain with X mm/h rate triggers the system to change the

   modulation level from level 3 to level 2, with bandwidth changing

   from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the

   local area is 52 minutes in a year. Then the dropped 200 Mbps

   bandwidth has 99.99% availability.



I would say that the 400Mbps bandwidth is available whenever it is not raining.

It lightly rains 52 min year, which means it is not raining 99.99% of the time, so the 400Mbps availability is 99.99%.  The 200Mbps is available during that 52 min, so 99.99% is not the 200Mbps availability. Right?



The analogous comment applies to the next two paragraphs.



Does that explain why the table shows the 100Mbps bandwidth having two different availabilities?

[Amy]Your understanding is also correct. That is just a different way to present the result. Take the values from the table, 100Mbps with 99.995% and 100Mbps with 99.999% can be also considered as bandwidth with 99.99% availability.

Thus it will result the total bw with 99.99% availability = 200+100+100=400Mbps





security:



The draft (*) security consideration points to RSVP-TE, but without an RFC reference, and to RFC5920.  Because this is a GMPLS related feature, it should refer to the GMPLS extensions to RSVP-TE in RFC3473.  As an extension to RFC6003, it could refer to that RFC’s security considerations section, but that only gets the reader to RFC3473, RFC3209, and RFC5920.



The security considerations for RSVP-TE itself (RFC3209) points to RFC2205.

RFC2205 defines an Integrity object (defined in RFC2747) that carries a keyed cryptographic digest based on a shared key, providing hop-by-hop protection between two RSVP nodes.  However, PATH messages are directed toward the traffic destination address, not the next RSVP node.  There could be clouds of non-RSVP nodes between two RSVP nodes that the PATH encounters.  This makes it difficult to share a key between individual pairs of RSVP nodes, and could motivate operators to configure the same key in large numbers of RSVP nodes.



RFC3473 points to RFC2747’s protection of RSVP messages.  It also notes that it introduces a Notify message that is not sent to the traffic destination address but instead to a node that requested notification.  One transmission option is that the NOTIFY is encapsulated in an IP packet and forwarded directly to the requesting node.  That complicates the Integrity object protection, unless the shared key is widely shared.



RFC3945 notes that authentication in GMPLS systems may use the authentication mechanisms of the component protocols, pointing to RFC2747 (as well as others for LDP, LMP, etc that don’t apply here).



RFC5920 discusses threats, attacks, and protections for MPLS/GMPLS data and control planes.  Section 7.1.2 in particular talks about “Control-Plane Protection with RSVP-TE”, and could be mentioned here explicitly.  It talks about network border configuration to limit external attacks, and mentions

RFC2747 authentication protections, making some of the same points about non-RSVP clouds and shared keys configuration.  It also points to RFC4230, which is a very detailed look at RSVP security, and probably deserves to be mentioned here.



So all told, at the end of all the reference chains, the only defined authentication and integrity protection in 2205, 3209, and 3473 is based on shared keys that are very difficult to configure with fine granularity.



However, as was said in reply to a different MPLS related draft review

yesterday:



    The MPLS network is often considered to be a closed network such that

    insertion, modification, or inspection of packets by an outside party is

    not possible.



So maybe that is accepted as sufficient in deployment.



MPLS documents are also typically granted an exception from more rigorous security requirements because MPLS is used only within one routing domain / ISP / provider / etc, under a single administrative control, so errors made would not be global in impact.  In particular, errors that might result from one legitimate but faulty/mis-configured/subverted/malicious MPLS node should not propagate out to the general Internet.  (**)

[Amy] Thanks for the detail explanation on the security consideration, it’s quiet educational. As the operating environment of GMPLS is similar to MPLS network, we will adopt the similar text.



Nits:



floating numbers



Page 5, Section 3.1, says “a 32-bit floating number”.  I believe you mean a floating-point number.  I checked other IETF RFCs (e.g., RFC8330), and it is common to mention the IEEE 754-2008 standard when including a floating point value in the spec.



But is a floating point value needed?  The draft says that the values are typically in a small set of known values.  The intro sounds like a small set of classes are used for “efficient planning”.  Just curious.  OTOH, RFC8330 uses floating point, and the ITU documents’ calculation of availability make it seem like full floating point is needed.

[Amy] will update to “floating-point number”.



the Availability TLV format:



page 5, section 3.1 says:



                                               The Availability TLV has

   the following format:



       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |    Index      |                 Reserved                      |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                          Availability                         |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                          Figure 1: Availability TLV



I presume that this is just the Value portion of the TLV format that is defined for the Ethernet SENDER_TSPEC Object in Section 4 of RFC6003.

[Amy] Yes, it is.



Page 1, Abstract:



   typically used for describing these links when during network

   planning



“when during” - is that deliberate?  It sounds redundant, maybe due to editing.

Or maybe it was supposed to be “when doing”?

[Amy] Will update to “when doing”.



   signaling. This extension can be used to set up a Generalized Multi-

   Protocol Label Switching (GMPLS) Label Switched Path (LSP) using the

   Ethernet SENDER_TSPEC object.



not sure - what is using the SENDER_TSPEC - the LSP or this extension?

[Amy] How about change to “in conjunction with SENDER_TSPEC”.



Page 3, Section 1:



   bandwidth availability. For example, the bandwidth with 99.999%

   availability of a link is 100 Mbps; the bandwidth with 99.99%

   availability is 200 Mbps.



maybe:



   bandwidth availability. Suppose, for example, the bandwidth with 99.999%

[Amy] will update the text.



Page 5, section 3.2:



   TLVs and one or more Availability TLVs. Each Ethernet Bandwidth

   Profile TLV corresponds to an availability parameter in the

   Availability TLV.



… “in an Availability TLV”? or “in the associated Availability TLV”? There’s more than one.

[Amy] will update to “in the associated Availability TLV”.



Page 6, section 3.2



        link), it SHOULD reserve the bandwidth resource from each



“it” -> “the node”



       this LSP. Optionally, the higher availability bandwidth can be



“the higher” -> “a higher”  (there’s more than one, right?)



        request cannot be satisfied, it SHOULD generate PathErr message



“it” -> “the node”



   generate PathErr message with the error code "Extended Class-Type



“PathErr” -> “a PathErr” or “PathErr messages”

[Amy] will update the draft accordingly.

postscripts:



(**) [[[ I will note that RFC3209 includes an AS number subject among the subobjects of the EXPLICIT_ROUTE object.  With the idea that you might set up explicit routes that go through multiple ASNs.  Ouch.  I know there are providers who have different ASNs under single administrative control, from acquisitions or business use cases, but this just makes it possible for an explicit route for an LSP to be misconfigured to include your (external) neighbor ASN.  And RFC5920 talks about “ASBR-ASBR communication for inter-AS LSPs”.  Better have good outbound filters on your border routers. ]]]



(*)As is typical for specifications that extend other published RFCs, this draft says it “does not introduce any new security considerations”.



<begin soapbox> In general, I am skeptical of extension drafts that make such claims.  Surely the existing security considerations should be examined to see how they apply to this new feature or object being introduced?  Do current protections adequately protect the new feature/object?  Does the new feature/object carry new information, produce new behaviors?  etc. But this is so very common I could hardly request that more be said here. Just saying. <end

soapbox>

[Amy] Thanks again for the detail review.