Alvaro, Thanks again. more inline in replies. The new diff from the last is attached.
On Sep 26, 2018, at 1:10 PM, Alvaro Retana <[email protected]<mailto:[email protected]>> wrote: On September 24, 2018 at 9:35:06 PM, Naiming Shen (naiming) ([email protected]<mailto:[email protected]>) wrote: Naiming: Hi! Thank you for your detailed review on this draft, I’ll try to reply to the comments inline below, and the proposed document diff is attached at the end. Let me know if you would like to have other formats. In general, the diffs look good to me. But I do have some more comments below. Once we iron those out and you post an update I will start the IETF Last Call. Thanks! Alvaro. ... Note that I read -11, but -12 was published in the interim -- so I'm putting this comment up here. The only change in -12 is the addition (in the IANA Considerations section) of "a new registry for sub-TLVs of the Reverse Metric TLV". Why do we need this new registry? The description (in §2) of the use of this sub-TLV already references rfc5305 (where a TE Default Metric sub-TLV is already defined), so it seemed somewhat natural to me to simply reuse that sub-TLV here. From the discussion on the list, I understand the intent to "future proof", even if no other applications come to mind. If that is the path we want to go, then we'll need a complete description of the new sub-TLV as well. [Some of my comments bellow assume the existing sub-TLV from rfc5305.] <NS> With the email exchange from you and Les, I assume I keep the same as in the version 12 on this sub-TLV registry. Yes. However, I need you to add a description of the sub-TLV in this document. Right now there is a reference to rfc5305, but as Les explained, even though these sub-TLVs look the same, they are really different. When doing so, the references to rfc5305 (for the sub-TLV) would not be needed. <NS> ok, modified. see diff. ... 172 octet field containing an IS-IS Metric Value, and a 1 octet Traffic 173 Engineering (TE) sub-TLV length field representing the length of a [minor] Even though it is the only one used, the sub-TLV length field is not the "Traffic Engineering (TE) sub-TLV length field”. <NS> Ok, remove the TE sub-TLV wording. The new text still has the same wording: s/1 octet Traffic Engineering (TE) sub-TLV length field/1 octet sub-TLV length field <NS> ok, missed that. 174 variable number of Extended Intermediate System (IS) Reachability 175 sub-TLVs. If the "sub-TLV len" is non-zero, then the Value field 176 MUST also contain one or more Extended IS Reachability sub-TLVs. [minor] I'm guessing that by "Extended IS Reachability sub-TLVs" you really mean the sub-TLVs for the Extended IS Reachability TLV, right? Please at least put in a reference to rfc5305. <NS> Will reference to the rfc5305. Going back to Les’ explanation of the need for a new registry. This document only defined type 18, so in reality the other sub-TLVs from rfc5305 shouldn’t be used. Suggestion: OLD> If the "sub-TLV len” is non-zero, then the Value field MUST also contain one or more Extended IS Reachability sub-TLVs [RFC5305]. NEW> If the "sub-TLV len” is non-zero, then the Value field MUST also contain one or more sub-TLVs. <NS> done. 178 The Reverse Metric TLV is optional. The Reverse Metric TLV may be 179 present in any IS-IS Hello PDU. A sender MUST only transmit a single 180 Reverse Metric TLV in a IS-IS Hello PDU. If a received IS-IS Hello 181 PDU contains more than one Reverse Metric TLV, an implementation 182 SHOULD ignore all the Reverse Metric TLVs and treat it as an error 183 condition. [nit] The first two sentences sound redundant to me. <NS> OK. [major] The text above is not specific about which PDUs can include the Reverse Metric TLV. The text does say that it is optional and that it may be in an IIH once...but it doesn't say anything about other PDUs. The IANA Considerations section contains the attributes to be included in the registry, but those are not Normative. <NS> Added other PDU MUST ignore it. I saw the new text. Thanks for being explicit about the TLV being used in an IIH. Les also pointed to the following in ISO 10589: “TLVs received in a non-permitted PDU MUST be ignored.” That means that the last sentence in the new text ("If an IS-IS node received of IS-IS Reverse Metric TLV in the PDU other than the IS-IS Hello PDU, this TLV MUST be ignored.”) is redundant. <NS> ok, removed:-) but it used to be “.. may be optional present in …”, changed to ".. MAY be optional present in …”, the formally define into Hello PDU. ... 406 When the link TE metric is raised to (2^24 - 1) [RFC5817], either due 407 to the reverse-metric mechanism or by explicit user configuration, 408 this SHOULD immediately trigger the CSPF re-calculation to move the 409 TE traffic away from that link. It is RECOMMENDED also that the CSPF 410 does the immediate CSPF re-calculation when the TE metric is raised 411 to (2^24 - 2) to be the last resort link. [major] These Normative statements are ok, but just for the case where the metric is raised because of the reverse metric, and not for the explicit configuration case. This document is specifying the behavior of the reverse metric, not the general configuration response. IOW, if someone doesn't read this document, then there's no way for the general case to apply to them -- and the general case (changed config) is not dependent on implementing the reverse metric. <NS> That’s a good point. We have been strugling on this point. This is added due to some request from the field, and those networks would like to see this 2^^24-1 and 2^^24-2 to be immediately notified and re-evaluate TE paths, instead of fixed long interval for re-evaluate. By at least specifying in this document, we document this behavior. Now if the CSPF module do immediate or not, does not break anything. But the providers will have a place to point to when they try to convince the implementation behavior from vendors. We’ll remove this wording if you insist. Then someone can start a new document to specifying such a needed behavior. I see… Let’s leave it in — if someone else picks up on it, then let’s take it out. <NS> ok. thanks. ... 418 4. Security Considerations 420 The enhancement in this document makes it possible for one IS-IS 421 router to manipulate the IS-IS default metric and, optionally, 422 Traffic Engineering parameters of adjacent IS-IS neighbors. Although 423 IS-IS routers within a single Autonomous System nearly always are 424 under the control of a single administrative authority, it is highly 425 RECOMMENDED that operators configure authentication of IS-IS PDUs to 426 mitigate use of the Reverse Metric TLV as a potential attack vector, 427 particularly on multi-access LANs. [major] Authentication doesn't prevent a subverted router from using the reverse metric. <NS> Right. But authentication is all IS-IS has. :-( [minor] I would love to see more text on what the threat really is. I think that includes being able to divert traffic, sent traffic over less preferred paths, etc. -- in short, this extension can have a significant effect on routing decisions. <NS> Right. But this is no different from any other IS-IS operations, such as changing local interface metric. reverse-metric is no worse than those. all of them can change the routing behavior in the network. True. However, this is a new mechanism being defined in this document. At least recognizing the potential effect and that it “is no worse” is important. Note that the difference between, for example, locally changing the metric and the reverse-metric is that the local change is like shooting yourself on the foot. The reverse-metric allows someone else to influence you. That’s the reason form my comment below: <NS> Make sense, but I think one of the main reason of this draft is to simplify the operation of maintenance. If an operator (within the same local domain) not only needs to raise a ‘reverse metric’ on the local device, but also to hunt down all the other devices on the same LAN and to enable this feature one by one, that would defeats the purpose of this important usage. Even though this is sent over to neighbor to act, but most provider network those devices are under the same admin domain. [major] Is there anything (besides authenticating) that can be done to mitigate the threat? The text talks about local configuration having the ability to override a reverse metric -- but it seems like the intent is for the default to be "accept the reverse metric".. Making the default be "don't accept reverse metrics" (i.e. having to explicitly configure the willingness to accept the new TLV) would help by only allowing the reverse metric where the operator knows it wants it. Was there any discussion about this in the WG? <NS> I don’t recall there is such a discussion. This document does not specify which is the default behavior. An implemetation can use either opt-in or opt-out, which does not break the inter-operability. It would be great if the document took a stance on that. <NS> although I would certainly want this mechanism to be enabled by default, but I don’t want to express this in this document since there may generate some security concern. added in the “operational consideration” section that: It is RECOMMENDED that the network operators disable the capability when this Reverse Metric feature or mechanism is not being used in the network where in the case an IS-IS implementation has this mechanism enabled by default. to see if you are ok with that. Regards, - NaimingTitle: Diff: draft-ietf-isis-reverse-metric-12-review.txt - draft-ietf-isis-reverse-metric-12-review-2.txt
| draft-ietf-isis-reverse-metric-12-review.txt | draft-ietf-isis-reverse-metric-12-review-2.txt | |||
|---|---|---|---|---|
| Networking Working Group N. Shen | Networking Working Group N. Shen | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track S. Amante | Intended status: Standards Track S. Amante | |||
| Expires: March 28, 2019 Apple, Inc. | Expires: March 31, 2019 Apple, Inc. | |||
| M. Abrahamsson | M. Abrahamsson | |||
| T-Systems Nordic | T-Systems Nordic | |||
| September 24, 2018 | September 27, 2018 | |||
| IS-IS Routing with Reverse Metric | IS-IS Routing with Reverse Metric | |||
| draft-ietf-isis-reverse-metric-12 | draft-ietf-isis-reverse-metric-12 | |||
| Abstract | Abstract | |||
| This document describes a mechanism to allow IS-IS routing to quickly | This document describes a mechanism to allow IS-IS routing to quickly | |||
| and accurately shift traffic away from either a point-to-point or | and accurately shift traffic away from either a point-to-point or | |||
| multi-access LAN interface during network maintenance or other | multi-access LAN interface during network maintenance or other | |||
| operational events. This is accomplished by signaling adjacent IS-IS | operational events. This is accomplished by signaling adjacent IS-IS | |||
| skipping to change at page 1, line 38 | skipping to change at page 1, line 38 | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 28, 2019. | This Internet-Draft will expire on March 31, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 34 | skipping to change at page 2, line 34 | |||
| 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9 | 3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 11 | 7.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
| Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 | Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 | |||
| Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12 | Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 12 | |||
| Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 | Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 13 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1. Introduction | 1. Introduction | |||
| The IS-IS [ISO10589] routing protocol has been widely used in | The IS-IS [ISO10589] routing protocol has been widely used in | |||
| Internet Service Provider IP/MPLS networks. Operational experience | Internet Service Provider IP/MPLS networks. Operational experience | |||
| with the protocol, combined with ever increasing requirements for | with the protocol, combined with ever increasing requirements for | |||
| lossless operations have demonstrated some operational issues. This | lossless operations have demonstrated some operational issues. This | |||
| document describes the issues and a mechanism for mitigating them. | document describes the issues and a mechanism for mitigating them. | |||
| 1.1. Node and Link Isolation | 1.1. Node and Link Isolation | |||
| skipping to change at page 4, line 47 | skipping to change at page 4, line 47 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | Flags | Metric | | Type | Length | Flags | Metric | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Metric (Continue) | sub-TLV Len |Optional sub-TLV | Metric (Continue) | sub-TLV Len |Optional sub-TLV | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Reverse Metric TLV | Figure 1: Reverse Metric TLV | |||
| The Value part of the Reverse Metric TLV is composed of a 3 octet | The Value part of the Reverse Metric TLV is composed of a 3 octet | |||
| field containing an IS-IS Metric Value, a 1 octet field of Flags, and | field containing an IS-IS Metric Value, a 1 octet field of Flags, and | |||
| a 1 octet Traffic Engineering (TE) sub-TLV length field representing | a 1 octet Reverse Metric sub-TLV length field representing the length | |||
| the length of a variable number of sub-TLVs. If the "sub-TLV len" is | of a variable number of sub-TLVs. If the "sub-TLV len" is non-zero, | |||
| non-zero, then the Value field MUST also contain one or more Extended | then the Value field MUST also contain one or more sub-TLVs. | |||
| IS Reachability sub-TLVs [RFC5305]. | ||||
| The Reverse Metric TLV may be optionally present in any IS-IS Hello | The Reverse Metric TLV MAY be optionally present in any IS-IS Hello | |||
| PDU. A sender MUST only transmit a single Reverse Metric TLV in a | PDU. A sender MUST only transmit a single Reverse Metric TLV in a | |||
| IS-IS Hello PDU. If a received IS-IS Hello PDU contains more than | IS-IS Hello PDU. If a received IS-IS Hello PDU contains more than | |||
| one Reverse Metric TLV, an implementation MUST ignore all the Reverse | one Reverse Metric TLV, an implementation MUST ignore all the Reverse | |||
| Metric TLVs. If an IS-IS node received of IS-IS Reverse Metric TLV | Metric TLVs. | |||
| in the PDU other than the IS-IS Hello PDU, this TLV MUST be ignored. | ||||
| TYPE: 16 | TYPE: 16 | |||
| LENGTH: variable (5 - 255 octets) | LENGTH: variable (5 - 255 octets) | |||
| VALUE: | VALUE: | |||
| Flags (1 octet) | Flags (1 octet) | |||
| Metric (3 octets) | Metric (3 octets) | |||
| sub-TLV length (1 octet) | sub-TLV length (1 octet) | |||
| sub-TLV data (0 - 250 octets) | sub-TLV data (0 - 250 octets) | |||
| skipping to change at page 6, line 15 | skipping to change at page 6, line 14 | |||
| transmitted in an IIH PDU on a point-to-point link, and MUST be | transmitted in an IIH PDU on a point-to-point link, and MUST be | |||
| ignored when received on a point-to-point link. | ignored when received on a point-to-point link. | |||
| U bit (0x02): The "Unreachable" bit specifies that the metric | U bit (0x02): The "Unreachable" bit specifies that the metric | |||
| calculated by addition of the reverse metric value to the "default | calculated by addition of the reverse metric value to the "default | |||
| metric" is limited to (2^24-1). This "U" bit applies to both the | metric" is limited to (2^24-1). This "U" bit applies to both the | |||
| default metric in the Extended IS Reachability TLV and the Traffic | default metric in the Extended IS Reachability TLV and the Traffic | |||
| Engineering Default Metric sub-TLV of the link. This is only | Engineering Default Metric sub-TLV of the link. This is only | |||
| relevant to the IS-IS "wide" metric mode. | relevant to the IS-IS "wide" metric mode. | |||
| The Reserved bits of Flags field MUST be set to zero and MUST be | ||||
| ignored when received. | ||||
| The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router | The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router | |||
| wishes to signal to its neighbor to raise its Traffic Engineering | wishes to signal additional information to its neighbor. In this | |||
| (TE) Metric over the link. The Sub-TLV Type 18, the "Traffic | document, the Reverse Metric Traffic Engineering Metric sub-TLV, with | |||
| Engineering Default Metric" sub-TLV [RFC5305], is defined to be | Type 18, is defined. This Traffic Engineering Metric contains a | |||
| included in the Reverse Metric TLV. Upon receiving this Traffic | 24-bit unsigned integer. This sub-TLV is optional, and MUST appear | |||
| Engineering METRIC sub-TLV in a Reverse Metric TLV, a node SHOULD add | once at most in the Reverse Metric TLV, otherwise the entire Reverse | |||
| the received Traffic Engineering Default Metric offset value to its | Metric TLV MUST be ignore on the receive. Upon receiving this | |||
| existing, configured Traffic Engineering Default Metric within its | Traffic Engineering METRIC sub-TLV in a Reverse Metric TLV, a node | |||
| Extended IS Reachability TLV. Use of other sub-TLVs is outside the | SHOULD add the received Traffic Engineering Metric offset value to | |||
| scope of this document. The "sub-TLV Len" value MUST be set to zero | its existing, configured Traffic Engineering Default Metric within | |||
| when an IS-IS router does not have Traffic Engineering sub-TLVs that | its Extended IS Reachability TLV. The use of other sub-TLVs is | |||
| it wishes to send to its IS-IS neighbor. | outside the scope of this document. The "sub-TLV Len" value MUST be | |||
| set to zero when an IS-IS router does not have Traffic Engineering | ||||
| sub-TLVs that it wishes to send to its IS-IS neighbor. | ||||
| 3. Elements of Procedure | 3. Elements of Procedure | |||
| 3.1. Processing Changes to Default Metric | 3.1. Processing Changes to Default Metric | |||
| It is important to use the same IS-IS metric type on both ends of the | It is important to use the same IS-IS metric type on both ends of the | |||
| link and in the entire IS-IS area or level. On the receiving side of | link and in the entire IS-IS area or level. On the receiving side of | |||
| the 'reverse-metric' TLV, the accumulated value of configured metric | the 'reverse-metric' TLV, the accumulated value of configured metric | |||
| and the reverse-metric needs to be limited to 63 in "narrow" metric | and the reverse-metric needs to be limited to 63 in "narrow" metric | |||
| mode and to (2^24 - 2) in "wide" metric mode. This applies to both | mode and to (2^24 - 2) in "wide" metric mode. This applies to both | |||
| skipping to change at page 9, line 40 | skipping to change at page 9, line 42 | |||
| link. It is RECOMMENDED also that the CSPF does the immediate CSPF | link. It is RECOMMENDED also that the CSPF does the immediate CSPF | |||
| re-calculation when the Traffic Engineering metric is raised to (2^24 | re-calculation when the Traffic Engineering metric is raised to (2^24 | |||
| - 2) to be the last resort link. | - 2) to be the last resort link. | |||
| It is RECOMMENDED that implementations provide a capability to | It is RECOMMENDED that implementations provide a capability to | |||
| disable any changes by Reverse Metric mechanism through neighbor's | disable any changes by Reverse Metric mechanism through neighbor's | |||
| Hello PDUs. It can be to a node's individual interface Default | Hello PDUs. It can be to a node's individual interface Default | |||
| Metric or Traffic Engineering parameters based upon receiving a | Metric or Traffic Engineering parameters based upon receiving a | |||
| properly formatted Reverse Metric TLVs. | properly formatted Reverse Metric TLVs. | |||
| It is RECOMMENDED that the network operators disable the capability | ||||
| when this Reverse Metric feature or mechanism is not being used in | ||||
| the network where in the case an IS-IS implementation has this | ||||
| mechanism enabled by default. | ||||
| 4. Security Considerations | 4. Security Considerations | |||
| The enhancement in this document makes it possible for one IS-IS | The enhancement in this document makes it possible for one IS-IS | |||
| router to manipulate the IS-IS Default Metric and, optionally, | router to manipulate the IS-IS Default Metric and, optionally, | |||
| Traffic Engineering parameters of adjacent IS-IS neighbors. Although | Traffic Engineering parameters of adjacent IS-IS neighbors. Although | |||
| IS-IS routers within a single Autonomous System nearly always are | IS-IS routers within a single Autonomous System nearly always are | |||
| under the control of a single administrative authority, it is highly | under the control of a single administrative authority, it is highly | |||
| RECOMMENDED that operators configure authentication of IS-IS PDUs to | RECOMMENDED that operators configure authentication of IS-IS PDUs to | |||
| mitigate use of the Reverse Metric TLV as a potential attack vector, | mitigate use of the Reverse Metric TLV as a potential attack vector, | |||
| particularly on multi-access LANs. | particularly on multi-access LANs. | |||
| End of changes. 10 change blocks. | ||||
| 22 lines changed or deleted | 30 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
