RFC 5960, "MPLS Transport Profile Data Plane Architecture", August 2010

Note: This RFC has been updated by RFC 7274

Errata ID: 2534
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-18

Section 6 says:

   Where enhanced security is desirable, and a trust relationship exists
   between an LSR and its peer, the LSR MAY choose to implement the
   following policy for the processing of MPLS packets received from one
   or more of its neighbors:

      Upon receipt of an MPLS packet, discard the packet unless one of
      the following two conditions holds:

      1.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has distributed to that neighbor; or

      2.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has previously distributed to the peer
          beyond that neighbor (i.e., when it is known that the path
          from the system to which the label was distributed to the
          receiving system is via that neighbor).

It should say:

   Where enhanced security is desirable, and a trust relationship exists
   between two LSRs, an LSR receiving an MPLS packet MAY choose to 
   implement an additional policy for processing the received packet as
   follows:

      The receiving LSR discards the packet unless every MPLS label
      stack entry that it processes from the packet's label stack has a 
      label that has been agreed for use by the sender of the packet
      (for example, is a reserved label or has been distributed using
      the management plane or control plane upstream or downstream 
      allocation). 

Notes:

There was considerable confusion about the distinction between peer and neighbour. This was first raised in a liaison from the ITU-T visible at
https://datatracker.ietf.org/liaison/916/

Clarification was also added about which labels are acceptable.

This does not result in a technical change to the specification, but introduces clarity about the processes described.

Report New Errata