27 Apr

Cloudflare hosting F root server

A few days some folks in internet community noticed Cloudflare AS13335 announcing F root server’s routes covering prefix 192.5.5.0/24.

 

 

Above tweet shows that case is clearly not a mistake but rather some sort of arrangement between Cloudflare and ISC (which is responsible for F-root). There was another discussion on DNS-OARC mailing list here.

From our bgp.he.net tool, one can analyse route propagation for F root’s AS3557.

 

Here we can see that routes are visible from AS13335 to Telefonica AS13335. One can safely assume that AS12956 (considered to be a Tier1 / transit free network as per list here) is not a customer of Cloudflare. So the fact that still route is being announced to Telefonica gives an impression that AS3557 is downstream of Cloudflare.

It’s hard to say on the kind of arrangement as I still see many of instances of F-root are being hosted directly by ISC from hostname.bind query triggered via local RIPE Atlas probes in those regions. It could be that Cloudflare is hosting a part of this setup say in developing region where they have their caching PoPs. Yet to see a detailed blog post from Cloudflare about it. (I like their detailed blog!)

13 Aug

What is BCP38 and why it is important?

BCP38 – also known as “Network Ingress Filtering” is concept where we filter incoming packets from end customers and allow packets ONLY from IP’s assigned to them.

 

Before going to BCP38, let’s first understand how packets forwarding work:

Network

 

Here User 1 is connected to User 2 via a series of router R1, R2 and R3. Here R1 and R3 are ISP’s edge routers while R2 is a core router. In typical way the network is setup, entire effort is given on logic of routing table i.e for packets to reach from User 1 to User 2, we need to ensure that User 1 has default route towards R1, knows that User-2’s IP is behind R3 which is reachable via R2. So path User 1 > R1 > R2 > R3 > User 2 comes up. And same for User 2 > R3 > R2 > R1 > User 1 as return path.

Now e.g IP pool for User-1 is 192.168.1.0/24 and is using 192.168.1.2 out of it while IP pool for User-2 is 192.168.2.0/24 and is using 192.168.2.2 out of it.

 

End to end traces

user2 User1

 

This is pretty much how most of network setups are. Now say User-1 get’s fishy and tries spoofing packets . User-1 can add 8.8.8.8 (not allocated to him) on his loopback interface.

ip -4 addr add 8.8.8.8/32 dev lo0 and done!

Now if User 1 tries to ping user-2 with 8.8.8.8 as in source then:

ping 192.168.2.2 -I 8.8.8.8 -c 2

User 1 will not got any packets in reply since return packets will not come but forward packets will go. Let’s run

tcpdump -i eth0 -n ‘icmp’ on User-2’s  machine:

tcpdump

 

 

Clearly user 1 is able to spoof packets and send them to User-2. While user 1 may not get back replies but this half communication in itself makes this very dangerous. This makes it prone to so many security issues like triggering a potential DoS attack with invalid IP’s or triggering DDoS attacks with DNS amplification or NTP amplification.

 

BCP38

So what is way to deal with it? – That’s BCP38 i.e filtering on the edge. The reason it’s important to filter on edge is because this cannot be done once packets leave edge. So e.g R2 might not be familiar on which IP’s R1 has allocated to whom and hence R2 cannot prevent spoofing of IPs allocated to R1 (it can however deny all non-R1 belong IP’s though). As we go into the core networks, IP filtering becomes harder and more of a problem then solution. Hence, it is expected that networks filters their edge and large networks filter small network.

So take e.g in this case R1 can put a filter to allow packets with only 192.168.1.0/24 in source and not anything else (like 8.8.8.8)

Create an access list and permit:

 

This completely prevents any spoofed packets from entering R1 from user 1. Ending this post with an interesting slide from Martin Levy from Cloudflare on extent of heavy amplification attacks done via spoofing.



 

 

Have fun and stay safe!