cloudflare/isbgpsafeyet.com

How to tell if the route is signed or not (and if filtering peers only and or partially safe)?

tedtrp opened this issue · 15 comments

#1 If an ISP signed a route, how does one tell that they did?

#2 And if they did sign the route:

a) how does one know if it is with filtering peers only?

b) how does one know how safe it is? For example besides "unsafe" I see reports of "partially safe".

Please and thank you.

lspgn commented

Hi @tedtrp :
For 1.
The RPKI data is public, you can download it and parse it with RPKI validators (OctoRPKI, Routinator, rpki-client, FORT, RIPE RPKI validator) or use our public dashboard. You can then search by ASN or directly the route. One thing to note, an owner of IP resources can sign to any ASN. A same route can have multiple signed records with different ASNs.

For 2.
This information is provided by the ISP regarding their configurations. And in some cases, looking at propagation of certain invalid routes and correlating with the ISP relationship can indicate partial filtering (eg: filtering of peers but not customers)
The difference between unsafe and partially safe is defined in Contributing. We changed the definition since the launch and we don't accept signed as partially safe anymore (we only changed the ISPs' classification on the newly added).

Ok.

What if the ISP has both signed and unsigned?

As an example my ISP (3737) has both. 198.182.247.0/24 and 209.102.224.0/20 is/are unsigned but everything else is signed.

In my review in/at https://github.com/cloudflare/isbgpsafeyet.com/blob/master/data/operators.csv what should it be marked as - Singed even through it has both or mark as it started or should I leave it alone, until any update? For example 100% signed or until I know filtering peers only.

Please and thank you

lspgn commented

While it would be optimal to sign everything, some IP space cannot always be signed (eg: legacy, delegated, doing a transfer).
In the case of PenTeledata AS3737, 94% of their routes are signed. Which is definitely fine. We're trying to avoid some ISPs that have too sparsely signed prefixes.
I had a look at 198.182.247.0/24, it seems that our BGP collector used behind rpki.cloudflare.com missed the withdrawals from 3737 (currently announced by AS6128).
The ROA probably will be created soon?
Screen Shot 2020-09-09 at 3 08 25 PM

Where did you get that graph from?

Please and thank you

Interesting thank you.

#1 Should the entry for my ISP be changed from "PenTeleData,ISP,,unsafe,3737,1071" to "PenTeleData,ISP,started,unsafe,3737,1071"?

Or should it be updated to "PenTeleData,ISP,signed,unsafe,3737,1071" ?

#2 Only if so, how would that be done?

#3 How would some one detect if it is with filtering peers only or not? If this requires more than one IP and routes (BGP) please tell me. If it could be done it at a web based UI, that would be best if possible for me as I do not have routes (BGP).

Please and thank you

lspgn commented
  1. & 2. Yes, feel free to make the change to "signed" in that case. "started" would also mean the ISP is working towards RPKI Origin Validation. You can use GitHub editor to edit the specific line. Similar to the previous changes.

3 . Usually this information is given by the ISP. Otherwise, you would need to find if you can reach invalid routes from Cloudflare and customers of PenTeleData (eg: on bgpview). Nothing that would be easy to test from a web based UI as far as I know. This would require lots of traces.

(one side note: try not using # followed by a number on GitHub comments, this references another issue which can be unrelated. example)

Q1 Should be written as

a) "PenTeleData,ISP,signed expect for 198.182.247.0/24 and 209.102.224.0/20,unsafe,3737,1071" This is my educated guess because that is the truth.

OR

b) "PenTeleData,ISP,signed expect for two blocks,unsafe,3737,1071" This is my second educated guess because that is the truth without telling what the blocks are.

OR

c) "PenTeleData,ISP,virtually signed,unsafe,3737,1071" That is my third educated guess because that is the truth without telling what the blocks are and how many.

OR just

d) "PenTeleData,ISP,signed,unsafe,3737,1071" even through I am sure that is not the truth.

?

Q2 Instead of # and number use # letter and then number(s) - like I am now?

Q3 Who thought of that idea of using # followed by a number to ref another issue?

Q4 Why did they think that is a good idea?

Q5 What where they thinking?

Q6: Was that feature added before or after MS take ownership of this platform?

Please and thank you

lspgn commented

q1: a) -> no need for too much details since it has to fit in the table on the page.

q2: yes this is fine. GitHub can also format as a list automatically when you write 1.

q3: I don't know :p https://docs.github.com/en/github/writing-on-github/autolinked-references-and-urls

q4: it's very common in code repositories to have this kind of referencing

q6: this feature has been here for a while, definitely before Microsoft

While I re-edited my post, ok,

lspgn commented

👍 will check for your pull request when it's ready

Changed to "PenTeleData,ISP,virtually signed,unsafe,3737,1071" If you do not like it fine, change it to "PenTeleData,ISP,signed,unsafe,3737,1071" 👍

lspgn commented

I'd prefer "signed" so that it remains consistent with the other records

Ok, fine changed

Closing because there is nothing else I need to ask