I've seen packets originating from RFC1918 addresses from two fairly large european ISP's (ASN1257 & smaller ASN35706) coming in on eBGP transit links lately, and I'm a bit puzzled why it wouldn't be dropped by an ACL first entrance in my ISP's network (or really, entrance in ANY ISP's network).

While I recognize that this is not a threat, I find it interesting and I would like to know what experience other people have of this.

In this example, is a RFC1918 network of mine, and port 8111 hosts a HTTP Push service for a pretty large customer.

# "FINSYN" packet 
10:58:07.069638 IP > Flags [FS], seq 737341754, win 65535, options [mss 1392,nop,wscale 4,nop,nop,TS val 1648454418 ecr 0,sackOK,eol], length 0
10:59:37.115697 IP > Flags [S.], seq 49951854, ack 1797656853, win 5792, options [mss 1460,sackOK,TS val 3490717429 ecr 1648449264,nop,wscale 7], length 0

# traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 (  0.142 ms  0.145 ms  0.164 ms 
 2  a.b.c.d (a.b.c.d)  1.215 ms  1.535 ms  1.713 ms
 3  * * *
 4  user7x.217-10-127.netatonce.net (  4.723 ms  4.693 ms  4.881 ms

Are my expectations sane?

Would you expect such packets to even enter your ISP's network?

Would you change ISP?

Additional feedback?


Not really, yes, and no. ISPs tend not to filter traffic that way for a couple of reasons:

The first is practical. Equipment designed to process high packet volumes has evolved to the point where a lot of the routing decisions are made in hardware. Imposing ACLs diverts that traffic to be handled in software, which doesn't route packets nearly as quickly, adding to the amount of equipment required to route the same volume. This is really a problem of evaluating threat before acting on it. The level of traffic containing spoofed 1918 addresses would have to be sufficient to have detrimental effects on other parts of the network before an ISP could make a business case for implementing ACLs and investing in more equipment. When that equipment is a router chassis populated with cards that cost six figures each, the bar is set relatively high.

The second is legal. The product sold by most ISPs to most business customers is plain, vanilla packet transit. Once the ISP starts filtering customer traffic, it runs the risk of being held liable for not having filtered traffic that a customer deems damaging. Most contracts explicitly indemnify the ISP from it, and at that point there's no point in adding filtering, putting the onus entirely on the customer. That's why managed, firewalled connections are more expensive than the regular flavor: it costs more to provide and carries more liability.

Your options are to drop the traffic at your ingress or, in the event you're seeing large amounts of it, take it up with the originating AS's abuse team.

  • "Once the ISP starts filtering customer traffic, it runs the risk of being held liable" can you cite a specific legislation or precedent that backs up this claim? – curiousguy Jun 25 '12 at 21:13
  • 1
    @curiousguy: As far as I know, there are no laws on the books in the U.S. that explicitly make the carrier liable, nor are there any that absolve them of liability. "Runs the risk" means some customer and his lawyer could bring a civil suit and win. I spent the latter half of the 1990s at a Tier-1 ISP and had ample opportunity to become familiar with the reasons our legal department had for putting what it did in the contracts we had with our customers. – Blrfl Jun 26 '12 at 14:29
  • @Blrfl If the ISP didn't do the filtering, wouldn't they be liable of sending illegal Internet Protocol packets to the customer? – curiousguy Jun 26 '12 at 19:16
  • @curiousguy: Illegal how? ISPs are under no legal or technical obligation to filter that traffic, nor do most of their contracts for unmanaged transit require it. – Blrfl Jun 26 '12 at 22:06
  • @curiousguy - I have deleted the comments you have posted that were obviously inflammatory, and would ask you to please keep conversation polite – Rory Alsop Jun 27 '12 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.