[c-nsp] RPKI validation weirdness

Thu May 7 16:56:35 EDT 2020

Hi Pierre,

This reminds me of a case of my own while labbing RPKI on XE. Only eBGP routes are subject to RPKI validation. iBGP routes are automatically considered to be valid. Cisco's implementation in XE will automatically modify the best path selection to prefer valid over unknown over invalid very high in the selection ruleset. This is what I assume happens :

If asbr02 goes up first, it gets the prefix, considers it a best path, sends it to asbr01 via iBGP. Then asbr01 goes up, compares an unknown external path to a valid internal one and chooses the second. Thus, traffic flows through there.

If asbr01 goes up first, it gets the prefix from its external neighbor, considers it best, sends it to asbr02. Asbr02 comes up but I'm guessing BIRD is actually preferring the route from asbr01. Thus, it never sends its own external route to asbr01. So, asbr01 keeps preferring its own external unknown one.

If I understand your design correctly, you might want to research whether BIRD can signal RPKI state via iBGP, as this would cause eventual consistency.

Regarding the extcommunity, I'm not sure if it's the best of ideas to announce state on iBGP routes, let alone reflected ones. I'd have to check whether the RFC actually specifies this before I form an opinion on what's happening. Assuming you do have asbr01 configured to announce rpki state though, it could be the expected behavior.

My thoughts and words are my own.

Spyros

-----Original Message-----
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of Pierre Emeriaud
Sent: Thursday, May 7, 2020 11:03 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] RPKI validation weirdness

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/