[c-nsp] RPKI validation weirdness

Thu May 7 16:55:30 EDT 2020

Hi Pierre,

I think this is well known bug on XE.

We just had a thread week or so back on this list.

You need to enable extended community to carry the validation state as
otherwise XE considers IBGP learned paths by default as VALID.

I think Cisco is already backporting the fixes for this - but as long as
you enable ext community state propagation you will be fine.

Thx
R.

On Thu, May 7, 2020 at 10:07 PM Pierre Emeriaud <petrus.lt at gmail.com> wrote:

> Hello all
>
> First of all, sorry for the long text wall, but I thin I have a bit of
> an interesting issue here. I have a router that announces a prefix
> that is not RPKI signed at all, hence sould neither appear valid nor
> invalid.
>
> It _does appear valid_ though on an asr1k running 03.16.06.S. Here is the
> setup.
>
> Said network (44.151.210.0/23) is announced by AS206155 to a transit
> operator (AS204092) on two peerings:
> - one direct from as206155 (89.234.186.158 - router id 80.67.190.204)
> to 204092 ("asbr01" - asr1k - 89.234.186.153)
> - one indirect from as206155 (185.1.89.27) to 204092 ("asbr02" -
> linux/bird - router id 89.234.186.34) though an IX RS.
> - this only happens if peering with asbr02 goes up before asbr01,
> otherwise asbr02 prefers the route through asbr01.
>
> asbr01 and 02 from as204092 are using the same two validators, one
> running routinator, the other is using FORT.
>
> 44.151.210.0/23 is not signed, nor is 44.128.0.0/10. Those prefixes do
> not appear as valid in the rpki table:
>
> asbr01#show ip bgp rpki table | i 44.151.210
> asbr01#
>
> However the /23 appears signed and hence is prefered:
>
> asbr01#show ip bgp | be 44.151.21
> N*   44.151.210.0/23  80.67.167.221           20             0 57199
> 34019 3215 206155 i
> N*                    193.200.43.85           10             0 34019
> 3215 206155 i
> N*                    89.234.186.158          50    200      0 206155 i
> V*>i                  185.1.89.27            150    150      0 206155
> i   <<< BEST & ROA VALID!?
>
> asbr01#show ip bgp 44.151.210.0
> BGP routing table entry for 44.151.210.0/23, version 487298116
> BGP Bestpath: deterministic-med: med
> Paths: (8 available, best #7, table default)
>   Advertised to update-groups:
>      75         114        118        122
> <snip>
>   Refresh Epoch 1
>   206155
>     89.234.186.158 from 89.234.186.158 (80.67.190.204)
>       Origin IGP, metric 50, localpref 200, valid, external
>       Community: 64496:200
>       path 7FA510447288 RPKI State not found             <<<< ok, expected.
>       rx pathid: 0, tx pathid: 0
>   Refresh Epoch 1
>   206155, (Received from a RR-client)
>     185.1.89.27 (metric 11) from 89.234.186.34 (89.234.186.34)
>       Origin IGP, metric 150, localpref 150, valid, internal, best
>       Community: 64496:100 64496:2150
>       unknown transitive attribute: flag 0xE0 type 0x20 length 0x18
>         value 0003 1D3C 0000 0064 0000 0096 0003 1D3C
>               0003 1D3C 0000 0064
>       path 7FA51044F508 RPKI State valid                 <<<<<<< ???
>       rx pathid: 0, tx pathid: 0x0
>
> The bird on asbr02 do not show the prefix as roa valid:
>
> bird> show route for 44.151.210.0 all
> Table master4:
> 44.151.210.0/23      unicast [bgp_breizhix_ipv4 2020-04-30 from
> 185.1.89.1] * (100) [AS206155i]
>         via 185.1.89.27 on enp3s0f0.22
>         Type: BGP univ
>         igp_metric: 20
>         BGP.origin: IGP
>         BGP.as_path: 206155
>         BGP.next_hop: 185.1.89.27
>         BGP.local_pref: 150
>         BGP.community: (64496,100)
>         BGP.ext_community: (generic, 0x43000000, 0x1) <<< ROA not found
>         BGP.large_community: (204092, 100, 150)
>                      unicast [bgp_cogent_ipv4 14:13:53.541] (100)
> [AS206155i]
>
>
> I've captured the update from asbr02 to asbr01 and there isn't the
> 0x43 extended community. However after this first update asbr01
> reflects it to the other ibgp peers _with_ the validation state 0x00!
> The capture is available here: https://paste.swordarmor.fr/tHOf
>
> I'm quite new at RPKI, so I might be missing something entirely, but
> the Cisco behaviour looks wrong at best, if not dangerous, as this
> makes unsigned prefixes look valid.
>
> I've skimmed for known rpki bugs on XE and haven't found anything
> conclusive, hence my attempt at having more eyeballs looking at this
> :)
>
> What's the list view on this issue?
>
> thanks
> pierre
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>