- Test - lists.nanog.org

Re: BGP Scalability Simulation
by Fouant, Stefan 03 Sep '08

03 Sep '08

Topology and setup of these kinds of tests largely depend on whether you are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight forward as you are almost always testing reconvergence of the BGP next-hop. iBGP testing scenarios on the other hand can be quite a bit more complex as you may also be testing the reconvergence of the underlying IGP if the BGP next-hop remains unchanged. Can you describe your testing goals and environment in a bit more detail? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ----- Original Message ----- From: Moazzam Khan <emoazzam(a)gmail.com> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Mon Sep 01 15:37:19 2008 Subject: BGP Scalability Simulation Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK

6 7

"How the 'Net works: an introduction to peering and transit" (arstech)
by Paul Vixie 02 Sep '08

02 Sep '08

http://arstechnica.com/guides/other/peering-and-transit.ars -- Paul Vixie

1 0

BGP Scalability Simulation
by Moazzam Khan 02 Sep '08

02 Sep '08

Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK

2 1

Re: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, why are we peering with the American RBN?]
by Paul Ferguson 01 Sep '08

01 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Steven M. Bellovin" <smb(a)cs.columbia.edu> wrote: >On Mon, 01 Sep 2008 11:08:20 -0400 Valdis.Kletnieks(a)vt.edu wrote: > >> a) There exist providers that are willing to take money from scum. >> b) We won't get rid of the scum until we admit (a) is true. > >I mostly agree with you -- but I get very worried about who defines >"scum". Consider the following cases, which I will assert are not very >far-fetched: > I can certainly see how the definition of "scum" could be hijacked to fit any particular political agenda, too. For the particular purposes I referred to earlier, the definition would be: "Continuing to allow criminal activity to occur within your network." "Criminal activity" is easily definable by laws which state that malicious, willful, and concerted attempts to perpetrate financial theft, fraud, and unauthorized computer tampering are illegal. But with all the ensuing discussion, it would appear that this is a matter in which ISPs defer, and a matter best addressed by law enforcement. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIvEXpq1pz9mNUZTMRAhRNAJ9nzEVp3PCAoQKFKltQFRwh3yLpwACg0gRO EnWO3Y4YQ/Z+F52z5il6Pdg= =cMVa -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
by Gadi Evron 01 Sep '08

01 Sep '08

Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_a… In it, Brian Krebs discusses the SF Bay Area based Atrivo/Intercage, which has been long named as a bad actor, accused of shuffling abuse reports to different IP addresses and hosting criminals en masse, compared often to RBN in maliciousness. "The American RBN", if you like. 1. I realize this is a problematic issue, but when it is clear a network is so evil (as the story suggests they are), why are we still peering with them? Who currently provides them with transit? Are they aware of this news story? If Lycos' make spam not war, and Blue Security's blue frog were ran out of hosting continually, this has been done before to some extent. This network is not in Russia or China, but in the silicon valley. 2. On a different note, why is anyone still accepting their route announcements? I know some among us re-route RBN traffic to protect users. Do you see this as a valid solution for your networks? What ASNs belong to Atrivo, anyway? Anyone has more details as to the apparent evilness of Atrivo/Intercage, who can verify these reports? As researched as they are, and my personal experience aside, I'd like some more data before coming to conclusions. Hostexploit released a document [PDF] on this very network, just now, which is helpful: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item… Gadi.

5 5

10GE CWDM
by Zed Usser 31 Aug '08

31 Aug '08

Hi! I seem to suffer from an acute lack of 10GE CWDM optics options. Is it just me or am I just looking in all the wrong places? You'd think that by now there would be an upgrade market from 1GE to 10GE. DWDM wavelenghts are not always available, but CWDM often are. - Zed

4 3

GNi/365main Above.net peering problems?
by Rusty Hodge 30 Aug '08

30 Aug '08

Anyone using transit from GNi at 365main seeing problems on routes that normally go over Above.net? For the last 36 hours, we've had problems. GNi isn't saying anything except that "replacement router cards are being delivered". I'm not sure if it's just routing via Above.net but lots of routes going through core-01.ge-1-1.sfo1.gni.com seems to be getting dropped.

2 2

RE: Revealed: The Internet's well known BGP behavior
by John Lee 30 Aug '08

30 Aug '08

1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living. 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where. 3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops. 4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack. And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch. John (ISDN) Lee :) ________________________________________ From: Frank [fsmendoza(a)gmail.com] Sent: Wednesday, August 27, 2008 8:47 PM To: NANOG list Subject: Revealed: The Internet's Biggest Security Hole http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed<http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html>a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. "It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "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." The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel<http://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html>) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data <http://www.5ninesdata.com/>, and Alex Pilosov, CEO of Pilosoft <http://www.pilosoft.com/>, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. "We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working." The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic. Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic. The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one. To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network. The attack is called an IP hijack and, on its face, isn't new. But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertently<http://news.bbc.co.uk/1/hi/technology/7262071.stm>hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss. Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs. Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients. "Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?" Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago. Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data. A handful of academic groups <http://www.routeviews.org/> collect BGP routing information <http://bgpmon.netsec.colostate.edu/index.html> from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400." Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said. "Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive." Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors. Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it. Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so. The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop. For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop. "That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said. The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers. Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP. "We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did." ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it." "The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said.

20 35

Problems with Routing to AT&T and HP
by Xaver Aerni 30 Aug '08

30 Aug '08

Hello, We have updated the AS8404 whith IP Rages 94.100.157/24 and 94.100.158.0/23. The Update of the Ripe Database was maked 1 week ago. Our clients has also have Problems to connect some Servers in USA. Over AT&T and HP (i see is an ATT link too) Is possible that AT&T has some Routers which must be updated manualy... Enclose is a Routing log Greetings X. Aerni linux-o4eb:~ # traceroute www.hp.com traceroute to www.hp.com (15.193.112.23), 30 hops max, 40 byte packets 1 77-59-223-226.static.cablecom.ch (77.59.223.226) 0.557 ms 0.849 ms 0.631 ms 2 77-59-223-225.static.cablecom.ch (77.59.223.225) 1.202 ms 1.173 ms 1.985 ms 3 62-2-54-69.static.cablecom.ch (62.2.54.69) 2.146 ms 0.717 ms 1.823 ms 4 ch-gva01a-ra1-ge-1-1-0.aorta.net (213.46.171.53) 9.111 ms 7.430 ms 5.241 ms 5 fr-par02a-rd1-pos-1-0.aorta.net (213.46.160.25) 27.150 ms 27.541 ms 28.884 ms 6 us-was02a-rd1-pos-1-0.aorta.net (213.46.160.106) 108.778 ms 108.656 ms 108.438 ms 7 us-was02a-ri1-ge-0-0-0-0.aorta.net (213.46.190.190) 110.421 ms 110.551 ms 108.689 ms 8 te-4-1.car3.Washington1.Level3.net (4.79.168.201) 164.303 ms 156.589 ms 148.794 ms 9 ae-1-69.edge1.Washington3.Level3.net (4.68.17.11) 109.955 ms 111.947 ms 109.865 ms 10 att-level3-oc192.Washington1.Level3.net (4.68.127.154) 195.878 ms 188.086 ms 180.087 ms 11 tbr2.wswdc.ip.att.net (12.123.8.102) 153.431 ms 152.593 ms 153.443 ms 12 cr2.wswdc.ip.att.net (12.122.16.109) 151.829 ms 151.673 ms 152.191 ms 13 cr1.attga.ip.att.net (12.122.1.173) 152.351 ms 152.811 ms 151.694 ms 14 cr2.dlstx.ip.att.net (12.122.28.174) 163.353 ms 157.482 ms 152.473 ms 15 cr1.dlstx.ip.att.net (12.122.1.209) 152.950 ms 152.487 ms 152.391 ms 16 cr2.hs1tx.ip.att.net (12.122.28.158) 152.213 ms 152.240 ms 152.922 ms 17 tbr2.hs1tx.ip.att.net (12.122.21.198) 152.295 ms 153.509 ms 153.006 ms 18 gar3.hs1tx.ip.att.net (12.123.134.45) 152.065 ms 151.947 ms 152.131 ms 19 12.116.42.166 (12.116.42.166) 153.071 ms 152.897 ms 153.265 ms 20 cce01gwb06-vl105.houston.hp.com (16.96.40.61) 154.593 ms 153.516 ms 153.215 ms 21 * * * 22 * * * 23 * * * 24 * * * 25 16.224.136.18 (16.224.136.18) 153.506 ms 151.410 ms 152.626 ms 26 16.224.136.58 (16.224.136.58) 153.228 ms 153.170 ms 155.002 ms 27 * * * 28 * * * 29 * * * 30 * * *

1 0

BGP more specific prefixes
by mauricio elelgrande 30 Aug '08

30 Aug '08

Sorry for sending this "huge" mail :-) At this moment we have a very simple multihomed ASN with a /20 prefix (x.y.0.0/20) like many other companys in the world. Some days ago, a BGP issue was announced about "IP hijacking". OK, we understand that this is some "new" because the traffic is also sent back to the "real owner" of the block. What kind of security can we have (and all internet providers) about that there is nobody announcing a subset of their prefix or a subset of their customer prefixes (i.e. x.y.0.0/24) disturbing the "normal" traffic flow? Of course, we know about prefix monitoring tools (from RIPE and others) but... it is the best solution? Or simply anyone can announce the /24 prefix that he want "capturing" that /24 prefix (of course if the "normal" prefix is smaller than that (i.e. /16))? In other words... can anybody "capture" the /24 prefix that he want? For example, what hapens if somebody announces a /24 from company "A" meanwhile the "normal" valid prefix of company "A"is a /16 and directs it to null0? That /24 is "shutted down". That is not the "new IP hijacking" issue because the traffic is not sent back to company "A". The question is very simply, It is very very difficult for me to believe that anybody can "shutdown" the /24 network that he wants in the world. I am right? Or may be that simply internet works like this and the providers are very careful about what accepts from their customers and what announces to other providers? I don't know the details of how internet providers work, but I know that when we made our multihoming for our ASN both providers did not setup the BGP session until we have created the "route object" in RIPE that makes a relationship between our ASN and our prefix. Also both providers have made filters in order to accept only our prefix in our BGP session. In other words... There is anybody in internet that can be sure that their traffic (traffic destined to their prefix) is not going to be "stoled"? If yes... how? Keep in mind that announcing the same prefixes than the attacker will not solve totally the problem because it is only a partial solution. If announcing a more specific /24 network is so easy... why does this not happen every day (for example for shutting down competitors sites)? Best regards

3 2