What is BGP? It is the default Exterior Gateway Protocol for the INTERNET.
It is also often the Interior Gateway Protocol for ISPs.
It is used to exchange routing information with other ISPs and BGP speaking customer routers.


There are two major concerns about the security of BGP.
One is router table corruption either deliberate or accidental.
At DEFCON last year there was a "kewl" bgp hijack method demo'ed.
The concepts weren't really new and methods to mitigate this were well known just not implemented in many cases.
http://isc.sans.org/diary.html?storyid=4975

Another concern is blindly resetting BGP sessions causing the routers involved to lose route information. This diary has a fairly complete set of references for the "blind TCP RST of persistent TCP connections within the window size" vulnerability first released in 2004
http://isc.sans.org/diary.html?storyid=171
This vulnerability was exasperated somewhat by route servers and looking glass implementations that provided the five tuple needed thus in some cases you only had to  "guess" the correct sequence number within the windows size.
http://www.merit.edu/mail.archives/nanog/2004-04/msg00684.html

The "Blind connection reset attacks against TCP" published by F Gont here:
http://tools.ietf.org/html/draft-gont-tcpm-icmp-attacks-00
are harder to mitigate against since icmp packets wouldn't be expected to have MD5 authentication.

There are several recommended mitigations for BGP attacks.
GTSM:
http://www.ietf.org/rfc/rfc3682.txt

Pros: Its simple to implement given that most BGP peers are one or 2 hops away from each other.
So a valid peer should be able to get a BGP packet to their peer with a TTL of 255 or 254 in most cases.
It's easy for the router to check as it is a simple Inbound_TTL >= TTL_Allowed type comparison.
It is nearly impossible to spoof an attack on a BGP session that is protected by GTSM as you have to be either directly connected or at least as close hop count wise as the expected peer.

Cons:
Not all BGP speakers support GSTM.
Not all BGP speakers have an initial TTL of 255.
Not all BGP speakers use an initial TTL of 255 for resets when they have lost Session State of a BGP session. So the TCP reset may come from the OS stack which may not be GSTM aware.
There are some tunneling methods that MAY allow packets into an ISP with an unmodified TTL but those are corner cases that can be dealt with depending on implementation.

MD5 authentication of BGP sessions:
http://tools.ietf.org/html/rfc2385
Pros:
Most BGP implementations support this.
Without the "shared secret" used between peers it is nearly impossible to successfully launch a spoofing attack.
Cons:
Because of the way the rfc was written it allowed the vendors to ignore MD5 authentication for connectionless resets. This can impact BGP if one of the peers lose state or has a stale connection (see section 4.1 of the rfc above).
MD5 authentication itself can be attacked, as it can be a compute intensive operation depending on the vendor's implementation.
It doesn't protect against NON-TCP based attacks.

Additional security measures recommended for BGP speakers.
Implementing prefix filtering to block advertisements of rfc1918 space and bogons.
http://www.team-cymru.org/Services/Bogons/

Implementing prefix filtering to block customers from advertising cidr blocks they weren't issued.
Implementing prefix filtering based on cidr block advertisement size.
ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/Prefix-List-Filtering-Mar-03.pdf

A good set of templates to secure BGP is available for several routers here.
http://www.team-cymru.org/ReadingRoom/Templates/