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!

01 Feb

Network hijacking: Wrong BGP announcements screwing up traffic

Yesterday I came across a very interesting case of network hijacking of an ISP from wrong BGP announcements by another network. This issue was reported to NANOG mailing list. 

Issue was reported by Kevin, Senior Engineer at Altus Communications (AS11325). Problem was that SBJ Media LLC (AS33611) was making a /24 block announcement for specific slices of Altus –, and which are allocated to Altus Communications (as per ARIN whois).

Good news for now is problem seems on it’s way to fix, and route servers of At&t and Hurricane Electric are showing right path for /24 blocks.Just now Kevin updated NANOG saying: 

I hope none of you ever get hijacked by a spammer housed at Phoenix NAP. 🙂
We’re still not out of the woods, announcing /24s and working with upper
tier carriers to filter out our lists. However, I just got this response from Phoenix NAP and found it funny. The “thief” is a former customer,whom we terminated their agreement with. They then forged an LOA, submitted it to CWIE.net and Phoenix NAP and resumed using space above and beyond their terminated agreement.


This one is very interesting case and shows even today there’s no guarantee of correct routing on the Internet. So many autonomous systems out there but still at the end of day routing somehow works! 


What an ISP can do in such cases? (what I myself learned from looking at such cases so far):

  1. Small chunks like /24 are given more priority over /20, thus if someone hijacks /24 out of your /20 block then you can (should) also start announcing /24 to make sure hijacker does not get any additional benefit by announcing small specific route.
  2. Pick out upstream ISP’s of attacker’s autonomous system & eventually get announced prefixes filtered out at the source itself.
  3. Pick your upstream ISP’s and eventually request them for prefix filtering. 


This whole incidence reminds me of YouTube blackout in 2008 by Pakistan Telecom. Other then prefix filtering by big ISP’s one can’t really do much if such wrong announcement continues.



With hope that your ISP’s network is not “stealing” others IP’s time for me to go out for morning walk in village!

Special thanks to John Schneider from Iowa Network Services for his inputs & answering my questions! 🙂

26 Sep

openDNS performing better in India now!

Hello everyone!


Seems like Tata Communications routing table is changed (call it fixed) to route traffic for openDNS to Singapore. It’s not going to London anymore and I see very good latency from BSNL too (which uses Tata Comm for most of it’s International traffic).


Here’s latest routing from BSNL to openDNS: 


HOST: laptop                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. router2                                                                        0.0%    50    2.0   1.7   1.5   2.2   0.2
  2.                                                             2.0%    50   25.4  26.2  24.5  36.1   1.6
  3.                                                        0.0%    50   26.1  31.2  25.0 125.5  17.8
  4.               2.0%    50   70.1  72.2  69.4  97.8   6.0
  5.                                                            0.0%    50   92.9  94.8  92.9 109.0   2.2
  6. ix-4-2.tcore1.CXR-Chennai.as6453.net            0.0%    50   94.3  98.4  93.1 154.6  12.6
  7. if-5-2.tcore1.SVW-Singapore.as6453.net          0.0%    50  127.2 130.6 125.8 165.5   8.5
  8. if-2-2.tcore2.SVW-Singapore.as6453.net         0.0%    50  126.8 128.6 124.4 178.2   8.3
  9. Vlan1807.icore1.SVQ-Singapore.as6453.net   2.0%    50  135.4 132.3 126.1 140.4   4.4
 10.                                                      0.0%    50  202.4 163.6 156.9 256.5  17.5
 11.                                                       0.0%    50  159.1 166.8 157.0 272.4  23.6
 12.                                                      2.0%    50  160.3 160.6 158.6 191.9   4.6
 13. resolver1.opendns.com                                           2.0%    50  159.0 158.3 156.9 162.4   1.0


Overall I am getting latency from 160ms which seems OK considering 25-30ms latency for DSL, adding 60-90ms for route till South India followed by 30-40ms latency between Chennai and Singapore and eventually destination openDNS node on ASN 36692. 


Oh and btw I was lucky enough to meet DNS godfather David Ulevitch at openDNS HQ in San Francisco during last US trip. A very impressive personality!


Well that’s all for now. Will be posting a couple more updates soon. Have a good week ahead!