anssi-fr / tabi Goto Github PK

I have a RIB file with exactly two records, that are in conflict with each other. See pull request link below. In this case, I found out that the detect_conflicts function returns two conflicts. Is this an expected behavior?

https://github.com/ANSSI-FR/tabi/pull/3/files#diff-2f062b81eb0021f04e0686060432a769R76

python detect_hijacks.py -c rrc01 -i mabo \
    --rpki-roa-file roa.csv \
    --irr-ro-file routes.csv \
    --irr-mnt-file maintainers.csv \
    --irr-org-file organisations.csv \
    ../../{bview,updates}.*.gz

Running hijack detection tool is throwing the error :

Traceback (most recent call last):

File "detect_hijacks.py", line 81, in <module>
  for conflict in detect_hijacks(**kwargs):
File "build/bdist.linux-x86_64/egg/tabi/emulator.py", line 146, in detect_hijacks
File "build/bdist.linux-x86_64/egg/tabi/annotate.py", line 163, in annotate_if_roa
File "build/bdist.linux-x86_64/egg/tabi/annotate.py", line 222, in annotate_roa_announce
TypeError: can only compare to a set 

I guess most tabi users care about entire ASes and use the -a parameter to specify the list of ASes they care about.
It would be great if there were an option to monitor specific prefixes only as well for those that only care about the prefixes they have services in.

thanks!
nusenu

and thanks for making me aware of this tool with your tweet :)
https://twitter.com/guedou/status/997010949335928832

May I know how you are able to generate & use the dynamic CSV files with real time data instead of static files as shown in repo.

@nv-anssi @guedou @ol-anssi @pcapillon @gdedrouas

Hi @nv-anssi ,

I have analysed the results of detection tool with our older RIB files and I suspect there false positives.

{"timestamp": 1489445634.0, "collector": "rrc01", "peer_as": 4755, "peer_ip": "121.244.206.224", "announce": {"type": "F", "prefix": "1.12.0.0/16", "asn": 4847, "as_path": "4755 6453 4134 4847"}, "conflict_with": {"prefix": "1.12.0.0/14", "asn": 18245}, "asn": 18245, "type": "ABNORMAL"}

Here prefix -"1.12.0.0/16" is said to be Abnormal for "asn": 4847, "as_path": "4755 6453 4134 4847

But the history of the RIB files shows that the ASN 4847 has been consistently advertising the prefix 1.12.0.0/16 and seems to be maintaining its stability.

So according to some papers/algoithms they are not abnormal. How are you trying to deal with such false posivities.
Please help me to understand If I am wrong here

Hello,

I have unzipped "all.hijacks.json.gz" file and I am not sure about the signification of each json fields. There are some informations about some fields and I tried to answer :

• collector : BGP collector which has been hijacked ?

• conflict_with :
  prefix : address block of the hijacker ?
  asn : ASN of the hijacker ?

• timestamp : when the announce was received (UTC timestamp)

• peer_ip : IP of the BGP peer (neighbor) which received the announce (so we talk about the hijacker ?)

• peer_as : AS of the BGP peer (neighbor) which received the announce (so we talk about the hijacker ?)

• announce :
  prefix : address block of the hijacked ?
  asn : ASN of the hijacked ?
  as_path : List of ASN used to reach the hijacked ASN ?

• type : either "U" if the announce was received from a BGP update or "F" if it was from a BGP full view

• asn : ASN of the hijacked or the hijacker ?