netdev - Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <55bbaf3f-653b-6194-fdb4-3efe2a7adcba@gssi.it>
Date:   Tue, 10 Mar 2020 17:26:24 +0100
From:   Ahmed Abdelsalam <ahmed.abdelsalam@...i.it>
To:     David Ahern <dsahern@...il.com>,
        Carmine Scarpitta <carmine.scarpitta@...roma2.it>
Cc:     davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, dav.lebrun@...il.com,
        andrea.mayer@...roma2.it, paolo.lungaroni@...t.it,
        hiroki.shirokura@...ecorp.com
Subject: Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

Hi David,

Thank you for your reply.

Our goal is not really a work around what is available and what the VRF 
can do.
The main issue (you already scratched in you email) is the consistency 
between IPv4 L3VPN and IPv6 L3VPN.
We can use the VRF device for End.DT4 but this will lead to 
inconsistency with End.DT6 as it uses the table instead.
This becomes hard to operate as provisioning the IPv4 and IPv6 VPNs 
needs to be done in different ways.

We would appreciate to get get your thoughts/advices on that and how we 
should go forward.

Regards,
Ahmed


On 09/03/2020 16:36, David Ahern wrote:
> On 3/6/20 9:45 AM, Ahmed Abdelsalam wrote:
>>
>> However, in the SRv6 we don’t really need a VRF device. The SRv6
>> functions (the already supported ones as well as the End.DT4 submitted
>> here) resides in the IPv6 FIB table.
>>
>> The way it works is as follows:
>> 1) create a table for the tenant
>> $ echo 100 tenant1 >> /etc/iproute2/rt_tables
>>
>> You instantiate an SRv6 End.DT4 function at the Egress PE to decapsulate
>> the SRv6 encapsulation and lookup the inner packet in the tenant1 table.
>> The example iproute2 command to do so is as below.
>>
>> $ ip -6 route add A::B encap seg6local action End.DT4 table tenant1 dev
>> enp0s8
>>
>> This installs an IPv6 FIB entry as shown below.
>> $ ip -6 r
>> a::b  encap seg6local action End.DT4 table 100 dev enp0s8 metric 1024
>> pref medium
>>
>> Then the BGP routing daemon at the Egress PE is used to advertise this
>> VPN service. The BGP sub-TLV to support SRv6 IPv4 L3VPN is defined in [2].
>>
>> The SRv6 BGP extensions to support IPv4/IPv6 L3VPN are now merged in in
>> FRRouting/frr [3][4][5][6].
>>
>> There is also a pull request for the CLI to configure SRv6-locator on
>> zebra [7].
>>
>> The BGP daemon at the Ingress PE receives the BGP update and installs an
>> a FIB entry that this bound to SRv6 encapsulation.
>>
>> $ ip r
>> 30.0.0.0/24  encap seg6 mode encap segs 1 [ a::b ] dev enp0s9
>>
>> Traffic destined to that tenant will get encapsulated at the ingress
>> node and forwarded to the egress node on the IPv6 fabric.
>>
>> The encapsulation is in the form of outer IPv6 header that has the
>> destination address equal to the VPN service A::B instantiated at the
>> Egress PE.
>>
>> When the packet arrives at the Egress PE, the destination address
>> matches the FIB entry associated with the End.DT4 function which does
>> the decapsulation and the lookup inside the tenant table associated with
>> it (tenant1).
> 
> And that is exactly how MPLS works. At ingress, a label is pushed to the
> front of the packet encapping the original packet at the network header.
> It traverses the label switched path and at egress the label is popped
> and tenant table can be consulted.
> 
> IPv6 SR is not special with any of these steps. If you used a VRF device
> and used syntax that mirrors MPLS, you would not need a kernel change.
> The infrastructure to do what you need already exists, you are just
> trying to go around and special case the code.
> 
> SR for IPv6 packets really should have been done this way already; the
> implementation is leveraging a code path that should not exist.
> 
>>
>> Everything I explained is in the Linux kernel since a while. End.DT4 was
>> missing and this the reason we submitted this patch.
>>
>> In this multi-tenant DC fabric we leverage the IPv6 forwarding. No need
>> for MPLS dataplane in the fabric.
> 
> My MPLS comment was only point out that MPLS encap and IPv6 SR encap is
> doing the exact same thing.
>