LDP Specification
RFC 5036

[Ballot comment]
Bill Fenner has posted a new implementation survey in the form of
an e-mail that lists the results of an e-mail poll that the chairs
made. Its borderline whether this really qualifies as a good implementation
report, but I'm not sure I should hold a discuss any longer because
we weren't really missing the whole report, just the answer to the
question of whether it referred to 3036 or the bis document.

I completely missed Loa's email in November.  He asked me about it at the reception yesterday and  I discovered that my previous comments in the tracker were all wrong.  Attached is Loa's email.  I will ask for this to be posted as an implementation report and we'll see if that's enough for Jari's concern.  There are still too few positions to pass, and Sam's DISCUSS, but those issues may be able to be dealt with this week still.

From: Loa Andersson
Subject: rfc3036bis implementation report
Date: Wed, Nov 8 2006 +0100
Organization: Acreo AB
To: Bill Fenner
Cc: Ross Callon , George Swallow

Write-up on the rfc3036-bis and the implementation report.
==========================================================

One of the comments from the IESG on the set of documents that we sent in
for review to take the LDP Specification (RFC3036) to draft standard has
been
that the implementation report is old, actually it relates to rfc3036, not
to rfc3036bis. This is a fair comment.

We have therefore agreed with the shepherding AD to publish the 2002 survey
with an addition that states that the document is publish to keep the
histrorical record correct.

We have also sent the a new implementation survey out to the working group
and we have

Responses wery much aligns with what we found out from the 2002
(rfc3036) survey,
but the responses is now based on the 3036bis implementation.

All the features of the 3036bis LDP specification has been implemented by at
least two independent implementors. All features has also been interop
tested
between at least two of the implementations that has responded to the the
survey. In a couple of cases they have also been interop tests between one
of the implementations for which we have a response to the 3036bis survey
and one that has not responded to the survey.

Loa and George



--
Loa Andersson

Principal Networking Architect
Acreo AB                          phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                          loa@pi.se

Details of why this is waiting: we are waiting for an implementation report on the modified document.  The 2002 implementation report is to be published for historical record, since it's not the implementation report for the 3036bis.  The working group is working on getting an implementation report done.

Since the IETF Last Call is partly on the implementation report, I'm putting this back in Publication Requested, to remind us that it will need a new Last Call when the implementation report is ready.

[Ballot discuss]
Holding a DISCUSS for the concerns raised earlier
by Margaret, Scott, and Ted about the interoperability
report. See the tracker history for the detailed
questions.

Updated note Oct 18, 2006: After re-reviewing the text
I am actually not worried about the issue from Margaret --
the individual features were tested, even if we no longer
have the data on which company tested against which.
But I am still worried about Scott's question:
"The implementation report describes a survey conducted in 2002.  draft-ietf-mpls-rfc3036bis-03 is a candidate for Draft Standard.  Has 3036bis been around since 2002 such that the survey corresponds to the specification it documents?"

To record what we discussed on today's management issues - The IESG agreed to the proposed method of removing the normative references.


Subject: Management Item: Eliminating normative downrefs from LDP for progressing to Draft Standard
Date: Tue, Jul 18 10:24:02
To: iesg@ietf.org

[Bcc'd to iesg-secretary]

I'd like to talk about the planned path forwards for
draft-ietf-mpls-rfc3036bis.  I modeled it on what we
did for LSP Ping, so hopefully there won't be any
major heartburn with the same tactic here.

The problem:
- draft-ietf-mpls-rfc3036bis-03 has the following
  downreferences:
  - RFC 1321 (MD5) - OK per RFC3967
  - RFC 1483 (AAL5) - accident, not actually used
  - RFC 1700 - historic, gotta change that reference
  - RFC 3031 (MPLS Architecture)
  - RFC 3032 (MPLS Label Stack Encoding)
  - RFC 3034 (Label Switching on Frame Relay Networks)
  - RFC 3035 (LDP on ATM VCs)
  - RFC 3037 (LDP Applicability)

We don't want to try to drag the whole world to
Draft Standard, but there has been a multi-year
effort towards getting LDP to Draft Standard (how
many is multi?  I think Scott Bradner was the Sub-IP
Area Director that advised this path.)

The attempt at a solution:

-  This document assumes familiarity with the MPLS architecture
-  [RFC3031].  Note that [RFC3031] includes a glossary of MPLS terminol-
-  ogy, such as ingress, label switched path, etc.
+  This document assumes (but does not require) familiarity with the
+  MPLS architecture [RFC3031].  Note that [RFC3031] includes a glossary
+  of MPLS terminology, such as ingress, label switched path, etc.

The key bits of 3031 and 3032 that LDP needs:

-  The Implicit NULL label (see [RFC3031]) is represented as a Generic
-  Label TLV with a Label field value as specified by [RFC3032].
+  The Implicit NULL label is defined in [RFC3031] as follows:
+
+  "The Implicit NULL label is a label with special semantics which an
+  LSR can bind to an address prefix.  If LSR Ru, by consulting its ILM
+  (Incoming Label Map) sees that labeled packet P must be forwarded
+  next to Rd, but that Rd has distributed a binding of Implicit NULL to
+  the corresponding address prefix, then instead of replacing the value
+  of the label on top of the label stack, Ru pops the label stack, and
+  then forwards the resulting packet to Rd."
+
+  The implicit NULL label is represented in LDP as a Generic Label TLV
+  with a Label field value of 3, as defined in [RFC3032].

The other key bit of 3032:

    Label
-      This is a 20-bit label value as specified in [RFC3032] represented
-      as a 20-bit number in a 4 octet field.
+      This is a 20-bit label value represented as a 20-bit number in a 4
+      octet field as follows:
+
+    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
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |    Label                            |                      |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+  For further information, see [RFC3032].

There's a similar problem with 3034, which I just noticed while composing
this email, but propose a similar solution to - the current text is

  DLCI
      The Data Link Connection Identifier.  Refer to [RFC3034] for the
      label values and formats.

and I'd propose replacing it with the two different possible formats for
the DLCI label.

Otherwise, 3034 and 3035 are examples of a place where the Hop Count
is used without the Path Vector, but they're just examples - the text is
like

  Note that the Hop Count TLV and its procedures are used without the
  Path Vector TLV in situations when loop detection is not configured
  (see [RFC3035] and [RFC3034]).

but since this document describes the procedures for both Path Vector
and Hop Count TLVs, I don't think this is normative.

Finally, 3037 is an Informational applicability statement, so would probably
be appropriate for 3967 processing.


Does anyone have any heartburn with this approach, before we go too
far down a fruitless path?

Thanks,
  Bill

[Ballot discuss]
Holding a DISCUSS for the concerns raised earlier
by Margaret, Scott, and Ted about the interoperability
report. See the tracker history for the detailed
questions.

We are at least expecting a revised ID for the references.  As the Gen-ART review states, we probably need to grant an explicit variance for TCP-MD5 like was done for BGP.

[Ballot comment]
From Gen-ART review of draft-ietf-mpls-rfc3036bis-03.txt
by David Black. These comments arrived after I already
entered No Objection but seem to need attention.

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

  The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
  Deployment practices for LDP are very similar to those of BGP: LDP
  connections are usually confined within a single autonomous system
  and most frequently span a single link between two routers.  This
  makes the LDP threat environment very similar to BGP's.  Given this,
  and a considerable installed base of LDP in service provider
  networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

  This section specifies a mechanism to protect against the introduc-
  tion of spoofed TCP segments into LDP session connection streams.
  The use of this mechanism MUST be supported as a configurable option.

  The mechanism is based on use of the TCP MD5 Signature Option speci-
  fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

Also see
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mpls-rfc3036bis-03-black.txt
for nits

[Ballot comment]
From Gen-ART review of draft-ietf-mpls-rfc3036bis-03.txt
by David Black. These comments arrived after I already
entered No Objection but seem to need attention.

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

  The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
  Deployment practices for LDP are very similar to those of BGP: LDP
  connections are usually confined within a single autonomous system
  and most frequently span a single link between two routers.  This
  makes the LDP threat environment very similar to BGP's.  Given this,
  and a considerable installed base of LDP in service provider
  networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

  This section specifies a mechanism to protect against the introduc-
  tion of spoofed TCP segments into LDP session connection streams.
  The use of this mechanism MUST be supported as a configurable option.

  The mechanism is based on use of the TCP MD5 Signature Option speci-
  fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

Also see
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mpls-rfc3036bis-03-black.txt
for nits

Also see
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mpls-ldp-survey2002-00-black.txt
for issues with the implementation report

[Ballot comment]
From Gen-ART review of draft-ietf-mpls-rfc3036bis-03.txt
by David Black. These comments arrived after I already
entered No Objection but seem to need attention.

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

  The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
  Deployment practices for LDP are very similar to those of BGP: LDP
  connections are usually confined within a single autonomous system
  and most frequently span a single link between two routers.  This
  makes the LDP threat environment very similar to BGP's.  Given this,
  and a considerable installed base of LDP in service provider
  networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

  This section specifies a mechanism to protect against the introduc-
  tion of spoofed TCP segments into LDP session connection streams.
  The use of this mechanism MUST be supported as a configurable option.

  The mechanism is based on use of the TCP MD5 Signature Option speci-
  fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

[Ballot comment]
From Gen-ART review by David Black. These comments arrived after I'd
entered No Objection but seem to need attention.

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

  The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
  Deployment practices for LDP are very similar to those of BGP: LDP
  connections are usually confined within a single autonomous system
  and most frequently span a single link between two routers.  This
  makes the LDP threat environment very similar to BGP's.  Given this,
  and a considerable installed base of LDP in service provider
  networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

  This section specifies a mechanism to protect against the introduc-
  tion of spoofed TCP segments into LDP session connection streams.
  The use of this mechanism MUST be supported as a configurable option.

  The mechanism is based on use of the TCP MD5 Signature Option speci-
  fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

[Ballot discuss]
I am having some trouble understanding how the implementation report shows that 2 independent implementations, both of which are included in this report, were tested together for each feature.

Are the raw results of the implementation reports (i.e. showing what was included in each implementation and what was tested against which other implementations) available anywhere?

[Ballot discuss]
There is not a description of the impact of spoofing attacks in
section 5.1.  As such, I cannot evaluate whether the protections
outlined are adequate.  Please describe what an attacker could do by
spoofing hellos.

Especially for basic hellos, if the advice given in 5.1 is followed,
it seems like that effectively reduces the set of people who could
spoof basic hellos to those who could generate labeled packets.  If
that's part of why this is not a problem, please mention it.  If it is
not obvious please explain why it is a mitigation.

IANA Comments:
Do we understand correctly that the only IANA action is to remove the Host Address FEC from the registry since it is not used by any implementation?

[Ballot comment]
I'm abstaining for now because I won't be on the call this week and I won't be able to ask this question directly.  I'll consider moving to a no-ob if the answer is "yes".

The implementation report describes a survey conducted in 2002.  draft-ietf-mpls-rfc3036bis-03 is a candidate for Draft Standard.  Has 3036bis been around since 2002 such that the survey corresponds to the specification it documents?