Label Switching Router Self-Test
draft-ietf-mpls-lsr-self-test-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
07 | (System) | Notify list changed from mpls-chairs@ietf.org to (None) |
2007-12-03
|
07 | (System) | State Changes to Dead from AD is watching by system |
2007-12-03
|
07 | (System) | Document has expired |
2007-09-17
|
07 | Ross Callon | State Changes to AD is watching from IESG Evaluation::Revised ID Needed by Ross Callon |
2007-09-13
|
07 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
2007-06-22
|
07 | (System) | Removed from agenda for telechat - 2007-06-21 |
2007-06-21
|
07 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2007-06-21
|
07 | Russ Housley | [Ballot comment] This document should be reformatted without hyphenation. Please expand "FEC" the first time it is used. (It is not "forward error … [Ballot comment] This document should be reformatted without hyphenation. Please expand "FEC" the first time it is used. (It is not "forward error correction," which was my first thought.) |
2007-06-21
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-06-21
|
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-06-21
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2007-06-21
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-06-21
|
07 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2007-06-21
|
07 | Jari Arkko | [Ballot discuss] I would like to understand better the implications and safeguards related to the use of a reply address carried within the message itself. … [Ballot discuss] I would like to understand better the implications and safeguards related to the use of a reply address carried within the message itself. In general Internet protocols, such a feature would result in yet another capability for someone to send a packet and have the answer to go to some innocent victim. This is not necessarily the worst possible vulnerability given that the effect is similar to being able to spoof source addresses and that no amplification is involved. However, I would not like to add new protocols that do this without a good reason and/or good safeguards to prevent misuse. I do not understand the MPLS technology well enough to say whether the above can lead to a general Internet vulnerability, or if this is somehow limited. Nodes that implement this spec, is there a chance that they will respond to the messages defined here even when not configured to be a part of an MPLS network? Are there ways for attackers to send messages from the Internet or from far-away MPLS nodes to this node and have it reply to a given address? I would like to see the document contain a better explanation of the above issues. Secondly, it may be necessary to improve the safeguards related to this feature if the explanation reveals that there are potential vulnerabilities. One easy safeguard would be to say that the node is only allowed to send to addresses configured as legal. |
2007-06-21
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2007-06-20
|
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-06-20
|
07 | Ron Bonica | [Ballot discuss] Do we need to ask if this draft addresses a problem that can be addressed using existing tools? I sustpect that this is … [Ballot discuss] Do we need to ask if this draft addresses a problem that can be addressed using existing tools? I sustpect that this is the case because a) there are other tools for testing MPLS data plane operation and b) this draft has been around for a long time without any implementations |
2007-06-20
|
07 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2007-06-20
|
07 | Tim Polk | [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing … [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing of labels and filtering labels). Without further elaboration describing the types of abuse envisioned by the authors, it is difficult to see if these recommendation are sufficient. This statement also seems to conflict with the security consoiderations in RFC 3036, section 5.2, which states that label distribution does not require privacy: "Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label." Why do the loopback labels present additional privacy requirements? Enumerating types of attacks that are and are not possible in an MPLS network using this mechanism would be very helpful. In particular, it appears this mechanism be used to cause generate traffic to a final destination that is not one of the participating LSPs. Is this a feature, a vulnerability, or both? It appears that the DPVRp is always smaller than the DPVRq. If so, it would be more efficient to execute a flooding attack directly, but there may be value in obscuring the source... If the security considerations are related to those of another message type, then a reference would be fine instead of new text. (To my non-MPLS expert eyes, the security considerations specified in 3036 pertaining to the Basic Hello seem related.) |
2007-06-20
|
07 | Tim Polk | [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing … [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing of labels and filtering labels). Without further elaboration describing the types of abuse envisioned by the authors, it is difficult to see if these recommendation are sufficient. This statement also seems to conflict with the security consoiderations in RFC 3036, section 5.2, which states that label distribution does not require privacy: "Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label." Why do the loopback labels present additional privacy requirements? Enumerating types of attacks that are and are not possible in an MPLS network using this mechanism would be very helpful. In particular, it appears this mechanism be used to cause generate traffic to a final destination that is not one of the participating LSPs. Is this a feature, a vulnerability, or both? It appears that the DPVRp is always smaller than the DPVRq. If so, it would be more efficient to execute a flooding attack directly, but there may be value in obscuring the source... If the security considerations are related to those of another message type, then a reference would be fine instead of new text. (To my non-MPLS expert eyes, the security considerations specified in 3036 pertaining to the Basic Hello seem related.) |
2007-06-20
|
07 | Tim Polk | [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing … [Ballot discuss] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse" and provides two recommendations (limit sharing of labels and filtering labels). Without further elaboration describing the types of abuse envisioned by the authors, it is difficult to see if these recommendation are sufficient. This statement also seems to conflict with the security consoiderations in RFC 3036, section 5.2, which states that label distribution does not require privacy: "Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label." Why do the loopback labels present additional privacy requirements? Enumerating types of attacks that are and are not possible in an MPLS network using this mechanism would be very helpful. If the security considerations are related to those of another message type, then a reference would be fine instead of new text. (To my non-MPLS expert eyes, the security considerations specified in 3036 pertaining to the Basic Hello seem related.) |
2007-06-20
|
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Discuss from No Objection by Tim Polk |
2007-06-20
|
07 | Tim Polk | [Ballot comment] |
2007-06-20
|
07 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2007-06-20
|
07 | Tim Polk | [Ballot comment] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse." Further elaboration describing the types of … [Ballot comment] The Security Considerations section begins with "Were loopback labels widely known, they might be subject to abuse." Further elaboration describing the types of abuse envisioned by the authors would be helpful. |
2007-06-20
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-06-19
|
07 | Magnus Westerlund | [Ballot discuss] IANA section is not sufficient as pointed out by IANA. Please provide answers to IANAs questions. The IANA section should clearly indicate which … [Ballot discuss] IANA section is not sufficient as pointed out by IANA. Please provide answers to IANAs questions. The IANA section should clearly indicate which registries different requests are related to. Also the type of port is needed. |
2007-06-19
|
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2007-06-19
|
07 | Dan Romascanu | [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol … [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol extension that has operational and management implications. Specifically I would like to see at minimum the following information in this section: - operational scenarios (some information exists about why the Loopback FEC type is needed and how it is applied for LSR self test and upstream neighbor verification, but is is distributed in the document) - how is a loopback test activated and how are results gathered, stored and presented - does it need a CLI, will it be activated remotely, will a MIB module need to be defined? - how are configured loopback labels and UDP ports if the default UDP port is changed - are there any limitations on the level of traffic that can be generated and the number of tests to be performed in an given interval of time? 2. The IANA considerations section should also deal with the allocation of the FEC element type instead of 130 mentioned now. 3. It looks like there are various bits of processing that have to happen here; but there is no talk about metering/prioritizing/etcing this traffic, leaving open a potential dos avenue. The security considerations section seems to hint at this (recommending that loopback labels be shared among trusted neighbors only). 4. The security considerations section should mention that any control interface that allows for packets generation needs to be properly access-secured and that the levels of test traffic must be kept within reasonable limits, so that they do not impact the performance of the LSRs involved in the tests or the levels of traffic in the network. |
2007-06-19
|
07 | Dan Romascanu | [Ballot comment] 1. I will leave to the security experts to make the final determination, but I am wondering what is the reasons that sharing … [Ballot comment] 1. I will leave to the security experts to make the final determination, but I am wondering what is the reasons that sharing loopback labels only between trusted neighbors and filtering lables on interfaces are only recommendations and not requirements. 2. FEC should be expanded in the Abstract. 3. Section 3.1, last sentence in the first paragraph - there is a double appearance of 'the' 4. Section 3.4, last sentence: 'It is RECOMMENDED that testing of label imposition SHOULD NOT be performed in such circumstances as the Verification Request will in most case travel multiple hops'. One of RECOMMENDED or SHOULD NOT can be dropped, also s/case/cases. |
2007-06-19
|
07 | Dan Romascanu | [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol … [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol extension that has operational and management implications. Specifically I would like to see at minimum the following information in this section: - operational scenarios (some information exists about why the Loopback FEC type is needed and how it is applied for LSR self test and upstream neighbor verification, but is is distributed in the document) - how is a loopback test activated and how are results gathered, stored and presented - does it need a CLI, will it be activated remotely, will a MIB module need to be defined? - how are configured loopback labels and UDP ports if the default UDP port is changed - are there any limitations on the level of traffic that can be generated and the number of tests to be performed in an given interval of time? 2. An issue raised by IANA during the Last Call review seems not to have been addressed, unless I am missing something. Section 3.2 talks about a UDP port to be used for MPLS Data Plane Verification Request messages, but I do not see this addressed in the IANA Considerations session. 3. The IANA considerations section should also deal with the allocation of the FEC element type instead of 130 mentioned now. 4. It looks like there are various bits of processing that have to happen here; but there is no talk about metering/prioritizing/etcing this traffic, leaving open a potential dos avenue. The security considerations section seems to hint at this (recommending that loopback labels be shared among trusted neighbors only). 5. The security considerations section should mention that any control interface that allows for packets generation needs to be properly access-secured and that the levels of test traffic must be kept within reasonable limits, so that they do not impact the performance of the LSRs involved in the tests or the levels of traffic in the network. |
2007-06-19
|
07 | Dan Romascanu | [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol … [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol extension that has operational and management implications. Specifically I would like to see at minimum the following information in this section: - operational scenarios (some information exists about why the Loopback FEC type is needed and how it is applied for LSR self test and upstream neighbor verification, but is is distributed in the document) - how is a loopback test activated and how are results gathered, stored and presented - does it need a CLI, will it be activated remotely, will a MIB module need to be defined? - how are configured loopback labels and UDP ports if the default UDP port is changed - are there any limitations on the level of traffic that can be generated and the number of tests to be performed in an given interval of time? 2. An issue raised by IANA during the Last Call review seems not to have been addressed, unless I am missing something. Section 3.2 talks about a UDP port to be used for MPLS Data Plane Verification Request messages, but I do not see this addressed in the IANA Considerations session. 3. It looks like there are various bits of processing that have to happen here; but there is no talk about metering/prioritizing/etcing this traffic, leaving open a potential dos avenue. The security considerations section seems to hint at this (recommending that loopback labels be shared among trusted neighbors only). |
2007-06-19
|
07 | Dan Romascanu | [Ballot comment] I will leave to the security experts to make the final determination, but I am wondering what is the reasons that sharing loopback … [Ballot comment] I will leave to the security experts to make the final determination, but I am wondering what is the reasons that sharing loopback labels only between trusted neighbors and filtering lables on interfaces are only recommendations and not requirements. |
2007-06-19
|
07 | Dan Romascanu | [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol … [Ballot discuss] 1. This document is missing an 'Operational and management considerations' section which I believe is needed for a document that defines a protocol extension that has operational and management implications. Specifically I would like to see at minimum the following information in this section: - operational scenarios (some information exists about why the Loopback FEC type is needed and how it is applied for LSR self test and upstream neighbor verification, but is is distributed in the document) - how is a loopback test activated and how are results gathered, stored and presented - does it need a CLI, will it be activated remotely, will a MIB module need to be defined? - how are configured loopback labels and UDP ports if the default UDP port is changed - are there any limitations on the level of traffic that can be generated and the number of tests to be performed in an given interval of time? 2. An issue raised by IANA during the Last Call review seems not to have been addressed, unless I am missing something. Section 3.2 talks about a UDP port to be used for MPLS Data Plane Verification Request messages, but I do not see this addressed in the IANA Considerations session. |
2007-06-19
|
07 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2007-06-17
|
07 | David Ward | [Ballot discuss] Given this draft has been around for a very long time and there are no known implementations, should this be INFO? |
2007-06-17
|
07 | David Ward | [Ballot Position Update] New position, Discuss, has been recorded by David Ward |
2007-06-14
|
07 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2007-06-14
|
07 | Ross Callon | Ballot has been issued by Ross Callon |
2007-06-14
|
07 | Ross Callon | Created "Approve" ballot |
2007-06-13
|
07 | Ross Callon | State Changes to IESG Evaluation from AD Evaluation::AD Followup by Ross Callon |
2007-06-13
|
07 | Ross Callon | Placed on agenda for telechat - 2007-06-21 by Ross Callon |
2007-05-25
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-05-25
|
07 | (System) | New version available: draft-ietf-mpls-lsr-self-test-07.txt |
2006-11-08
|
07 | (System) | Request for Early review by SECDIR Completed. Reviewer: Tero Kivinen. |
2006-10-04
|
07 | Ross Callon | State Changes to AD Evaluation::Revised ID Needed from Waiting for Writeup by Ross Callon |
2006-09-13
|
07 | Yoshiko Fong | IANA Last Call Comment: First action: Upon approval of this document, the IANA will make the following assignments in the "PORT NUMBERS" registry located at … IANA Last Call Comment: First action: Upon approval of this document, the IANA will make the following assignments in the "PORT NUMBERS" registry located at http://www.iana.org/assignments/port-numbers mpls-verify-reqest TBD/udp # [RFC-mpls-lsr-self-test-06] Second action: Upon approval of this document, the IANA will make the following assignments in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Parameters - per [RFC4379]" registry located at http://www.iana.org/assignments/mpls-lsp-parameters table: "Message Types - per [RFC4379]" 3 LSP Ping Message Type MPLS Data Plane Verification Request [RFC-mpls-lsr- self-test-06] 4 LSP Ping Message Type MPLS Data Plane Verification Request [RFC-mpls-lsr- self-test-06] Third acation: the document requests two further registrations: LSP Ping Object Type 11 IPv4 Reply-to Address LSP Ping Object Type 12 IPv6 Reply-to Address From the document IANA has not be able to determine which table in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ registry in second action this registration is requested in. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please advise. We understand the above to be the only IANA Actions for this document. |
2006-09-08
|
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2006-08-25
|
07 | Amy Vezza | Last call sent |
2006-08-25
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-24
|
07 | Ross Callon | State Changes to Last Call Requested from AD Evaluation by Ross Callon |
2006-08-24
|
07 | Ross Callon | Last Call was requested by Ross Callon |
2006-08-24
|
07 | (System) | Ballot writeup text was added |
2006-08-24
|
07 | (System) | Last call text was added |
2006-08-24
|
07 | (System) | Ballot approval text was added |
2006-07-07
|
07 | Ross Callon | State Changes to AD Evaluation from Publication Requested by Ross Callon |
2006-03-24
|
07 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2005-10-26
|
06 | (System) | New version available: draft-ietf-mpls-lsr-self-test-06.txt |
2005-07-19
|
05 | (System) | New version available: draft-ietf-mpls-lsr-self-test-05.txt |
2005-02-22
|
04 | (System) | New version available: draft-ietf-mpls-lsr-self-test-04.txt |
2004-10-25
|
03 | (System) | New version available: draft-ietf-mpls-lsr-self-test-03.txt |
2004-02-16
|
02 | (System) | New version available: draft-ietf-mpls-lsr-self-test-02.txt |
2003-10-27
|
01 | (System) | New version available: draft-ietf-mpls-lsr-self-test-01.txt |
2003-10-03
|
00 | (System) | New version available: draft-ietf-mpls-lsr-self-test-00.txt |