[nsp-sec] AS Path Forging - Observations from an incident

[Hank Nussbacher]

At 07:33 PM 01-12-08 -0500, Heather Schiller wrote:
>----------- nsp-security Confidential --------
>
>
>***Please do not redistribute.. standard NSP-sec confidentiality applies***
>
>A couple of weeks ago I stumbled across a case of ASpath forging.. (how? 
>dumb luck and stubborn curiosity..)  This seemed to get a lot of attention 
>over the summer, everyone agreed it was a problem.  I don't think anyone 
>reported any incidents?  So, I thought I'd write up a bit of what we saw 
>and some thoughts about the problem in general.  I would appreciate any 
>feedback, suggestions or ideas.
>
>  I think the real danger is that, if done correctly, the routes "look 
> legitimate", nothing is "broken", no one complains, and it's likely to go 
> entirely unnoticed.
>
>
>We noticed one netblock with an as-path that did not have a matching route 
>inside our network.. when we looked further we saw several netblocks with 
>the same path.
>
>In all cases the as-path was:  3277 3216 3549 701 11486
>
>We could easily verify where 701 and 11486 were forged, by checking our 
>routes internally and seeing that the route did not exist, or did not 
>match what we have internally.  We were also able to use Global Crossing's 
>looking glass to verify that they did not have these routes in their 
>network either.
>
>Some of the netblocks were our IP space, but not assigned.. so we 
>considered those straight hijacks and began announcing competing 
>routes.  Some of the netblocks were direct allocations from ARIN to our 
>customers and were more specifics of routes we had in our network.  We 
>were concerned about a possible MITM for those.. but realized, there is no 
>good way to verify this.
>
>By the time we could get our legal and management act together, the routes 
>were gone.. One thing I would suggest, if you are an ISP and have strict 
>policies on taking action, work w/ your mgmt or legal group to make sure 
>your AUP covers this, and that you have an escalation process and 
>documentation in place if your customer does this, or you discover someone 
>else doing this.
>
>Not sure if anyone is interested, but below are some notes I pulled 
>together about why these are such a pain.  Other than a possible means of 
>detection, I don't have much by way of solutions.. except that "we" (the 
>peoples that run the internet) should collectively agree on some technical 
>solution that includes a way to document AS relationships for prefixes and 
>verify an organizations authority to use a resource.. netblocks and ASNs.
>
>
>Key Problems:
>
>Detection:
>  1) No mechanism exists to automatically detect and notify (see below for 
> notes about why)
>
>  2) Since the aspath is forged, you aren't accepting the route back into 
> your network (the aspath is looped so the route gets dropped) - so it's 
> hard to see from your own network.
>
>
>Verification:
>  3) If you don't have access to the device configs or a looking glass you 
> trust for each network, it is hard to verify each ASN in the path to 
> figure out where the forgery is starting.

I am possibly encountering an issue with a forged /24.  I am not interested 
in prevention or resolution for now.  I am interested in detection.  The 
path looks valid and doesn't have any strange ASNs.  Any new ideas in the 
past month to do MITM AS-path forging detection?

Thanks,
Hank



>Notification:
>  4) Since you can't identify who is starting the forgery, it is difficult 
> to know who to notify.
>
>
>Resolution:
>  5) Successful resolution is when the offender stops announcing the 
> route.  No concrete method exits to motivate the offender to stop, short 
> of terminating service or depeering.
>    a) Announcing a competing route for the affected netblock disrupts 
> them at best, but does not return the netblock to a useable state.
>    b) Not accepting routes with the offeding AS similarly disrupts all of 
> their traffic, but does not return the netblock to a useable state.
>
>  6) If a customer does this, all we can do is remove the prefix from 
> their prefix list and not accept the announcement.
>
>
>Prevention:
>  7) No mechanism to prevent our customers from doing this.  We can only 
> verify that our customers are authorized to use the ASN we configure them 
> with.  They or their customers can forge the aspath of routes they send 
> to us.  (Look into a method to filter and reject based on the AS's in the 
> path of routes they send us, and way to load list of acceptable ASN's in 
> the path for each prefix (not just origin) Get that list published in RIR 
> whois records or similar?)
>
>  8)Make sure our AUP/IPUP policies cover this and we have a process to 
> notify, escalate and resolve if we find a customer doing this.
>
>  9) No mechanism to prevent peers or other external entities from doing 
> this.  There is no community wide standard method for AS or route 
> authorization and verification.
>
>
>
>All the public tools (free) tools that exist today, basically have some 
>subset of the problems below.
>
>  1) Do not peer heavily enough, so they don't have a wide base of 
> data/different views
>
>  2) Not suitable for large scale service providers, with dozens of ASN's 
> and hundreds of aggregates and thousands of prefixes.
>
>  3) They do not get data 'fast' enough - I think all the systems I have 
> looked at depend on either Routeviews or RIPE RIS data.  If I'm not 
> mistaken Routeviews data is published every 2 hours and RIPE RIS every 8 
> hours (if you don't want to process every update).
>
>  4) The biggest problem - None compares your internal routing table and 
> paths, with a public view.   At the moment, that's the only way I can 
> think of, for finding these.
>
>[1-4 are applicable to the Kapella Forged ASpath issue.  1-3 are also 
>applicable to standard hijacks]
>
>
>--
>====================================================
>  Heather Schiller       Verizon Business
>  Customer Security      1.800.900.0241
>  IP Address Management  help4u at verizonbusiness.com
>=====================================================
>
>
>
>_______________________________________________
>nsp-security mailing list
>nsp-security at puck.nether.net
>https://puck.nether.net/mailman/listinfo/nsp-security
>
>Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
>community. Confidentiality is essential for effective Internet security 
>counter-measures.
>_______________________________________________