Re: [secdir] secdir review of draft-ietf-mpls-special-purpose-labels-05 (resend)

"Adrian Farrel" <> Tue, 18 March 2014 11:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 273261A03C9; Tue, 18 Mar 2014 04:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.783
X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ODWqw9oNI7n; Tue, 18 Mar 2014 04:16:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8660D1A06A8; Tue, 18 Mar 2014 04:16:08 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s2IBFxHe030545; Tue, 18 Mar 2014 11:15:59 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s2IBFqJw030437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 11:15:57 GMT
From: Adrian Farrel <>
To: 'Tom Yu' <tlyu@MIT.EDU>
References: <>
In-Reply-To: <>
Date: Tue, 18 Mar 2014 11:15:52 -0000
Message-ID: <013c01cf429b$70b72a90$52257fb0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHqkxBwphpOBtuABjYo2lKAwgzvvZqwDANA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--9.101-10.0-31-10
X-imss-scan-details: No--9.101-10.0-31-10
X-TMASE-MatchedRID: +f/wAVSGjuhxtRSiTWsxtfHkpkyUphL9MhomkrNJ+uzNQVzhfYY5so9/ 6wlLhvp4L81jVSVU6+iCbJKOlWLydZ+/3E8wlr+Dde4BwMgBa9OrzMdPEAIrFjAVXG2j6Yswakc q2RAHKcok/TQmrPGEgNZwCHB4c2lu1OGXhAFLw8vCz1ymGcrCUYEcpMn6x9cZi2g8XzxCDfvg9L It2OdOa5KrGRECKhSO8JwrmyXfpoNCl9DEsHnSbbMjW/sniEQKpw/gqzLticlIjvA1/YS+0bliD 6D5Idq7YaIwvoCNtbMo6ikEEzC7Af+JqEYbBLbNSDkh6bW+bccsleOknNBI05soi2XrUn/JyeMt MD9QOgCk8oKXKhRLPI2j49Ftap9EOwBXM346/+w+2PP2xW2k7pcpEZ0AmOH27WhLu0LiBHZJG8u y1zCyHwqZuffWhtd5
Subject: Re: [secdir] secdir review of draft-ietf-mpls-special-purpose-labels-05 (resend)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Mar 2014 11:16:10 -0000

Hi Tom,

> Summary: ready with nits
> I believe the Security Considerations section of this document is
> reasonable.
> Query: I'm not very familiar with MPLS; is the handling of the Entropy
> Label Indicator the only situation where a Label Switching Router
> would need to inspect (as opposed to hash for load balancing) labels
> below the top of the label stack?

Welcome to the wonderful world of MPLS, and thanks for your review.

RFC 6790 Section 4.3 says 
   In any case, reserved labels MUST NOT be used as
   keys for the load-balancing function.
but it is recognised that some implementations might currently be hashing the
label stack without inspection.

So, the technically correct answer is that every reserved label (aka special
purpose label) is such a case, and (since no-one knows what labels will show up
in the stack) it means that all labels used for hashing must be inspected.

> I was confused by the explanation of why Label 7 (ELI) has meaning as
> both an ordinary Special Label and an Extended Special Purpose Label
> until I read RFC 6790.  Perhaps explain that looking for the ELI is
> typically the only reason why a LSR would inspect the middle of the
> label stack?

Well, this is being changed (somewhat in the face of mutterings from two of the
authors) so that 7 is reserved in the extended range. Hence, no need to explain
or discuss :-)

> Re answer 6 of Section 3:
> If an ingress LSR pushes ESPLs onto the label stack, any downstream
> LSRs that do not understand ESPLs could erroneously use the ESPLs as
> load balancing inputs.  Would it be a good idea to recommend that
> ingress LSRs avoid pushing ESPLs onto the label stack if their policy
> cannot tolerate variations in downstream load balancing caused by
> inappropriate use of the ESPLs as load balancing inputs by downstream
> LSRs that don't understand ESPLs?

You are right about that.
The LSR would spot the XL and know that it was a special purpose label and so
would not use it.
But it would not know that the XL meant that the next label was also a special
purpose label and so would include that label in the hash.

And, indeed, this is what the answer to Question 6 observes. And the answer also
notes that reordering may occur in these situations (perhaps we thought it
obvious that if you don't want reordering to occur you had better avoid this
situation?). I think that also in our minds is that this whole piece of work is
considerably future-sighted. we don't anticipate the first extended special
purpose label being assigned for a number of years, so this document enables
hardware to be built and deployed that will be proof against the introduction of
ESPLs when they roll up.