netdev - [MPLS] Why can we encapsulate outgoing label with reserved values?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20190516100713.GT18865@dhcp-12-139.nay.redhat.com>
Date:   Thu, 16 May 2019 18:07:13 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     Robert Shearman <rshearma@...cade.com>
Cc:     netdev@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Ying Xu <yinxu@...hat.com>
Subject: [MPLS] Why can we encapsulate outgoing label with reserved values?

Hi Robert, Eric,

In commit 5a9ab0176198 ("mpls: Prevent use of implicit NULL label as outgoing
label") I saw we disabled setting label 3. Is there a reason that why we did
not disable other reserved values(0-15)?

I saw function mpls_label_ok() checks the index and reject all reserved values.
With this two different handles, we can encap a reserved label, but could not
exchange or decapsulate the reserved labels. e.g.

# ip route add 10.10.10.2/32 encap mpls 3 via inet 10.3.3.1
Error: Implicit NULL Label (3) can not be used in encapsulation.
# ip route add 10.10.10.2/32 encap mpls 0 via inet 10.3.3.1
# ip -f mpls route add 0 via inet 10.3.3.1
Error: Invalid label - must be MPLS_LABEL_FIRST_UNRESERVED or higher.

Thanks
Hangbin