Skip to main content

Label Switching Router Self-Test
draft-ietf-mpls-lsr-self-test-07

Discuss


Yes

(Ross Callon)

No Objection

(Chris Newman)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Mark Townsley)
(Sam Hartman)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Dan Romascanu Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-06-19) Unknown
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.
David Ward Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-06-17) Unknown
Given this draft has been around for a very long time and there are no known implementations, should this be INFO?
Jari Arkko Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-06-21) Unknown
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.
Magnus Westerlund Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-06-19) Unknown
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.
Ron Bonica Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-06-20) Unknown
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
Tim Polk Former IESG member
(was No Objection) Discuss
Discuss [Treat as non-blocking comment] (2007-06-20) Unknown
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.)
Ross Callon Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-06-21) Unknown
  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.)
Sam Hartman Former IESG member
No Objection
No Objection () Unknown