Several news sources have been carrying a story about the DEFCON BGP hijack. While that “trick” was pretty cool it was not new. Original DEFCON paper is here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt

Wired article here:
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html
As Pieter Zatko (aka Mudge of L0pht) is quoted in this article:
"I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail."

What is new here?
The TTL adjustment was cool and new to me.
Getting the data back to the hijacked network was also kind of cool but as prepending isn’t new just not used in this way in the past as far as I know:)

The rest is old very OLD.

BGP4 was always capable of directing traffic that is what it was designed to do.

Path-prepending is a technique that's equally well known.
   
This is no easy to attack this as you need to be trusted by your upstream ISPs. Since those ISPs have neither the interest nor the need
to trust their customers to announce only their own BGP information many ISPs filter what customers can announce to them.

Large ISPs are in a position to do it as they are trusted but have even less motivation in performing BGP hijacking. A successful BGP hijack by a large ISP would result in peers publicly mocking them and front page headlines that would not be good for business.
   
Attracting a substantial amount of traffic and sending it out again is going to get noticed. Both on your bandwidth usage with the potential for a self inflicted fill the pipe ddos and by people watching traffic patterns/announcements in BGP.

Here is one of the early bgp hijacks it was an accident but in 1997 this accident caused major outages and traffic to be redirected when as7007 hijacked a large portion of the internet.
http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html

   
If you want to prevent what they did at DEFCON implementing the following template should help.

http://www.cymru.com/Documents/secure-bgp-template.html
Additionally ISPs should add router-filter statements (junos)
 policy-statement CUSTOMER.COM.AS201020 {
      term 10 {
          from {
              as-path CUSTOMER.COM.AS201020;
              route-filter 1.1.1.0/24 orlonger;
          }
          then next policy;
      }
      term 20 {
          then reject;
}

Or cisco prefix-lists
ip prefix-list 201020 seq 10 permit 1.1.1.0/22 le 24
To limit what your customers can announce to you. It is described here: http://puck.nether.net/bgp/cisco-config.html

A more complete PKI based solution is being developed by the sidr working group at IETF. Here is several of the drafts others are available at ietf.org.

http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-02.txt

A good collection of BGP security papers is available here:

http://www.cs.cmu.edu/~dwendlan/routing/