06 Sep

CDN Caching Panel discussion at APNIC 46

I am in Noumea in New Caledonia in the Pacific Islands. Next week we have APNIC 46 conference and I would be moderating an exciting panel discussion with friends from Akamai, Cloudflare, Facebook and more about working of CDNs. 

If attending APNIC 46, please come & join this session –https://conference.apnic.net/46/program/schedule/#/day/7/panel-cdn-caching

If you are interested in connecting to Hurricane Electric (AS6939) in this region, please do drop me a message. (List of our PoPs in the region here)

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

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!)
Update: 2nd April 2017 
Henry from Cloudflare pointed me to their official announcement blog post written after around 5 months of this post. You can find their official announcement here.

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:
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 and is using out of it while IP pool for User-2 is and is using 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 (not allocated to him) on his loopback interface.
ip -4 addr add dev lo0 and done!
Now if User 1 tries to ping user-2 with as in source then:
ping -I -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:
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.


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 in source and not anything else (like
Create an access list and permit:

access-list 1 permit
interface GigabitEthernet1/0
 description Link to User-1
 ip address
 ip access-group 1 in
 negotiation auto

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!