Re: Revealed: The Internet's well known BGP behavior
On 30/08/2008, at 9:58 AM, Florian Weimer wrote: * Alex Pilosov: We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering. The technique of path stuffing ASes who you do not want to receive an announcement is called AS PATH poisoning. It's a fairly well known trick. -- Nathan Ward
Re: Revealed: The Internet's well known BGP behavior
On Aug 29, 2008, at 22:41, "jim deleskie" <[EMAIL PROTECTED]> wrote: I'm afraid of the answer to that question No you are not, since you already know the answer. -- TTFN, patrick On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <[EMAIL PROTECTED]> wrote: On Fri, Aug 29, 2008, jim deleskie wrote: Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad. The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed." Adrian
Re: Revealed: The Internet's well known BGP behavior
I'm afraid of the answer to that question On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <[EMAIL PROTECTED]> wrote: > On Fri, Aug 29, 2008, jim deleskie wrote: >> Announcing a smaller bit of one of you block is fine, more then that >> most everyone I know does it or has done and is commonly accepted. >> Breaking up someone else' s block and making that announcement even if >> its to modify traffic between 2 peered networks is typically not >> looked as proper. Modify your taffic good. Do it to anyone other >> traffic = bad. > > The question shouldn't really be "would people do this to others' traffic"; > the question should be "has it already happened and noone noticed." > > > > > > Adrian > >
Re: Revealed: The Internet's well known BGP behavior
On Fri, Aug 29, 2008, jim deleskie wrote: > Announcing a smaller bit of one of you block is fine, more then that > most everyone I know does it or has done and is commonly accepted. > Breaking up someone else' s block and making that announcement even if > its to modify traffic between 2 peered networks is typically not > looked as proper. Modify your taffic good. Do it to anyone other > traffic = bad. The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed." Adrian
Re: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercage, w hy are we peering with the American RBN?]
On Sat, 30 Aug 2008, Paul Ferguson wrote: I applaud GLBX's move to disconnect Atrivo/Intercage. What the Armin/McQuaid/Jonkman report [1] documented are activities that many of us in the security community have known for a couple of years. One thing that Krebs _didn't_ mention in his WaPo article are the large number of rogue DNS servers that also reside there. A couple of colleagues, Feike Hacquebord, Chenguai Lu, et al., presented a paper at the Virus Bulletin conference last year [2]. While the paper is almost a year old, that particular situation has gotten progressively worse. My only concern here is that by the publicity this issue continues to receive, these activities will just move else where, like scurrying cockroaches (like what happened with AS40989). One step at a time, I suppose. Yep, I am almost intrigued to see where they move. They'd move eventually anyway, the question is if we can then gripe about other countries not being responsive and approach that problem, or have to drive by their building to the office every morning? Gadi
Re: Revealed: The Internet's well known BGP behavior
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad. -jim On Fri, Aug 29, 2008 at 6:58 PM, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Alex Pilosov: > >> We've demonstrated ability to monitor traffic to arbitrary >> prefixes. Slides for presentation can be found here: >> http://eng.5ninesdata.com/~tkapela/iphd-2.ppt > > The interesting question is whether it's acceptable to use this trick > for non-malicious day-to-day traffic engineering. > >
GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercage, w hy are we peering with the American RBN?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Marc Sachs" <[EMAIL PROTECTED]> wrote: >Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said >good-bye to Atrivo/Intercage), it looks like they are no longer their >upstream: > >http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > I applaud GLBX's move to disconnect Atrivo/Intercage. What the Armin/McQuaid/Jonkman report [1] documented are activities that many of us in the security community have known for a couple of years. One thing that Krebs _didn't_ mention in his WaPo article are the large number of rogue DNS servers that also reside there. A couple of colleagues, Feike Hacquebord, Chenguai Lu, et al., presented a paper at the Virus Bulletin conference last year [2]. While the paper is almost a year old, that particular situation has gotten progressively worse. My only concern here is that by the publicity this issue continues to receive, these activities will just move else where, like scurrying cockroaches (like what happened with AS40989). One step at a time, I suppose. - - ferg [1] http://www.hostexploit.com/ [2] http://www.virusbtn.com/pdf/conference_slides/2007/HacquebordVB2007.pdf -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIuJelq1pz9mNUZTMRArvXAJ9PHNQygl5Mnrozgu140di34FvuigCcCzFa UWI10pR0jTyDUapX/J3Opa4= =YU/M -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/
Re: Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
On Fri, Aug 29, 2008 at 19:14, Gadi Evron <[EMAIL PROTECTED]> wrote: > On Fri, 29 Aug 2008, Marc Sachs wrote: >> >> Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said >> good-bye to Atrivo/Intercage), it looks like they are no longer their >> upstream: >> >> http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > > Current peers: > http://cidr-report.org/cgi-bin/as-report?as=AS19151 (just purchased by > Host.net) > http://cidr-report.org/cgi-bin/as-report?as=AS26769 This popped up on my radar only because of AS19151 and the BGP Attack thread mentioning PHAS. Just last night I got phaser@ notifications about 19151 popping in and out of 22653 (a network I reside deep inside of) for about a 12 hour span. H, -Jim P.
Re: BGP Attack - Best Defense ?
- Original Message - Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? --- --- [EMAIL PROTECTED] wrote:--- Correct, as you would then be contending with the path length portion of the 10 determistic citeria in the bgp protocol. --- And the only one that'd really come into play would be shortest number of AS hops, so topological closeness would be the deciding factor on whether the traffic transits the attacker's network or properly comes directly to me. scott
Re: Using 32 bit ASN numbers
On Aug 29, 2008, at 6:08 PM, Owen DeLong wrote: Marshal, Since his question was specifically about I don't see the answer in either of the places you referenced Sorry, I was too eager to respond. The assignees of the 32 bit ASN will have to ask for space from IANA from the former "eGLOP" space, now the Extended AD-HOC space. There will be no automatic pre-assignment of space, see http://www.ietf.org/internet-drafts/draft-ietf-mboned-rfc3171bis-03.txt for details. This has not become an RFC yet, and if people have comments, we welcome them on the MBONED list. Regards Marshall The calculator didn't like a 32 bit ASN: AS Number Out of Range AS numbers are represented by 16 bits; 65535 maximum in decimal. No, likely not. Marshall Back to the GLOP Calculator Return to Shepfarm Multicast [EMAIL PROTECTED] Owen On Aug 29, 2008, at 1:58 PM, Marshall Eubanks wrote: On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Yes, and yes. The space they are given is the GLOP space ! See http://www.multicasttech.com/faq/#GLOP and http://www.shepfarm.com/multicast/glop.html Regards Marshall Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner <[EMAIL PROTECTED]> wrote: Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED] wrote: These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: BGP Attack - Best Defense ?
Goto www.traceroute.org for a very comprehensive looking glass and routeview servers list. You can then determine how succesful your attempts to quell an attack are. - Original Message - From: "Scott Weeks" [EMAIL PROTECTED] Sent: 08/29/2008 04:06 PM MST To: <[EMAIL PROTECTED]> Subject: Re: BGP Attack - Best Defense ? --- [EMAIL PROTECTED] wrote: -- From: Steve Gibbard <[EMAIL PROTECTED]> On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? -- Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? -- I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs -- Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. -- I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: BGP Attack - Best Defense ?
-- [EMAIL PROTECTED] wrote: - You need to contact 1st their directly connected provider, 2nd contact your upstream provider and ask that they contact their peers and negate the announcement. 3rd if this is an ARIN provided block contact them as you do pay for your allocation and they will have the contacts to resolve the issue. You cannot normally announce smaller than a /24 --- As someone told me in a private email: ## I would then try to contact the ASs still using the attack ## path to get it stopped. (Yell help on NANOG? ;-) :: What if the relevant ASNs are in a remote part of the world :: that doesn't participate in NANOG, or speak english, or even :: have a 24x7 NOC Which is why I said "Yell help on NANOG? ;-)". Since there're more ASN operators here than on any other *NOG I'm aware of I would have my best hope after exhausting all other avenues of resolution. scott
RE: Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
On Fri, 29 Aug 2008, Marc Sachs wrote: Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said good-bye to Atrivo/Intercage), it looks like they are no longer their upstream: http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 Current peers: http://cidr-report.org/cgi-bin/as-report?as=AS19151 (just purchased by Host.net) http://cidr-report.org/cgi-bin/as-report?as=AS26769 Marc SANS ISC -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 4:02 PM To: [EMAIL PROTECTED] Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as _major.html 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&Itemi d=15 Gadi.
Re: BGP Attack - Best Defense ?
Correct, as you would then be contending with the path length portion of the 10 determistic citeria in the bgp protocol. - Original Message - From: "Scott Weeks" [EMAIL PROTECTED] Sent: 08/29/2008 04:06 PM MST To: <[EMAIL PROTECTED]> Subject: Re: BGP Attack - Best Defense ? --- [EMAIL PROTECTED] wrote: -- From: Steve Gibbard <[EMAIL PROTECTED]> On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? -- Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? -- I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs -- Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. -- I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said good-bye to Atrivo/Intercage), it looks like they are no longer their upstream: http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 Marc SANS ISC -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 4:02 PM To: [EMAIL PROTECTED] Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as _major.html 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&Itemi d=15 Gadi.
Re: BGP Attack - Best Defense ?
--- [EMAIL PROTECTED] wrote: -- From: Steve Gibbard <[EMAIL PROTECTED]> On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? -- Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? -- I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs -- Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. -- I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve --
Re: BGP Attack - Best Defense ?
You need to contact 1st their directly connected provider, 2nd contact your upstream provider and ask that they contact their peers and negate the announcement. 3rd if this is an ARIN provided block contact them as you do pay for your allocation and they will have the contacts to resolve the issue. You cannot normally announce smaller than a /24 - Original Message - From: "Scott Weeks" [EMAIL PROTECTED] Sent: 08/29/2008 03:50 PM MST To: <[EMAIL PROTECTED]> Subject: Re: BGP Attack - Best Defense ? --- [EMAIL PROTECTED] wrote: --- From: Jason Fesler <[EMAIL PROTECTED]> > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? --- They would go to me. They have been coming to me since I heard about this service on NANOG. Thanks folks at Colorado State University! :-) -- Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options. -- I'm currently on an eyeball network and no one is physically close to me, since I'm in Hawaii (the most isolated land mass in the world). Even though the TTL changes in this attack, the physics don't. The gamers would probably be the first alert folks as they would see the delay regardless of what their traceroutes say... ;-) In this attack the traffic makes it to both end-points. The middle is what changes. Restating my question differently: If the attacker is announcing a /24 of mine, I figure it out some how and I start announcing the same. What happens if the attacker doesn't stop? This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: BGP Attack - Best Defense ?
On Fri, 29 Aug 2008, Scott Weeks wrote: Restating my question differently: If the attacker is announcing a /24 of mine, I figure it out some how and I start announcing the same. What happens if the attacker doesn't stop? You may as well announce both the same /24 and /25s if you can...though those probably won't make it far. If they hijack something less specific than a /24, go one bit more specific than the rogue announcement. After that, try contacting the rogue ASN's upstreams. After that? See if you can find a backhoe for hire? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: BGP Attack - Best Defense ?
On Fri, 29 Aug 2008, Scott Weeks wrote: I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. I would then try to contact the ASs still using the attack path to get it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve
Re: BGP Attack - Best Defense ?
--- [EMAIL PROTECTED] wrote: --- From: Jason Fesler <[EMAIL PROTECTED]> > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? --- They would go to me. They have been coming to me since I heard about this service on NANOG. Thanks folks at Colorado State University! :-) -- Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options. -- I'm currently on an eyeball network and no one is physically close to me, since I'm in Hawaii (the most isolated land mass in the world). Even though the TTL changes in this attack, the physics don't. The gamers would probably be the first alert folks as they would see the delay regardless of what their traceroutes say... ;-) In this attack the traffic makes it to both end-points. The middle is what changes. Restating my question differently: If the attacker is announcing a /24 of mine, I figure it out some how and I start announcing the same. What happens if the attacker doesn't stop?
Re: BGP Attack - Best Defense ?
I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options.
Re: Using 32 bit ASN numbers
Marshal, Since his question was specifically about I don't see the answer in either of the places you referenced The calculator didn't like a 32 bit ASN: AS Number Out of Range AS numbers are represented by 16 bits; 65535 maximum in decimal. Back to the GLOP Calculator Return to Shepfarm Multicast [EMAIL PROTECTED] Owen On Aug 29, 2008, at 1:58 PM, Marshall Eubanks wrote: On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Yes, and yes. The space they are given is the GLOP space ! See http://www.multicasttech.com/faq/#GLOP and http://www.shepfarm.com/multicast/glop.html Regards Marshall Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner <[EMAIL PROTECTED]> wrote: Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED] wrote: These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: BGP Attack - Best Defense ?
Please allow me to change this: "I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker." to this: "Announce the same more specific as the attacker." scott --- [EMAIL PROTECTED] wrote: From: "Scott Weeks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: BGP Attack - Best Defense ? Date: Fri, 29 Aug 2008 14:29:21 -0700 My question revolves around the best recovery from an attack of the type we've been discussing. I only figured out the attack methodology yesterday evening Hawaiian Standard Time. Be gentle please... :-) I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker. The topologically closer ASs would then start sending the traffic to me properly. Those topologically closest to the attacker would still send to the attack path. I would then try to contact the ASs still using the attack path to get it stopped. (Yell help on NANOG? ;-) Is this the best recovery plan at this time? scott
Re: Revealed: The Internet's well known BGP behavior
* Alex Pilosov: > We've demonstrated ability to monitor traffic to arbitrary > prefixes. Slides for presentation can be found here: > http://eng.5ninesdata.com/~tkapela/iphd-2.ppt The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering.
BGP Attack - Best Defense ?
My question revolves around the best recovery from an attack of the type we've been discussing. I only figured out the attack methodology yesterday evening Hawaiian Standard Time. Be gentle please... :-) I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker. The topologically closer ASs would then start sending the traffic to me properly. Those topologically closest to the attacker would still send to the attack path. I would then try to contact the ASs still using the attack path to get it stopped. (Yell help on NANOG? ;-) Is this the best recovery plan at this time? scott
Re: Using 32 bit ASN numbers
On Aug 29, 2008, at 4:58 PM, Marshall Eubanks wrote: On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? Oh, and there is a plan in the works to accommodate those with 32 bit ASN. Regards Marshall If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Yes, and yes. The space they are given is the GLOP space ! See http://www.multicasttech.com/faq/#GLOP and http://www.shepfarm.com/multicast/glop.html Regards Marshall Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner <[EMAIL PROTECTED]> wrote: Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED] wrote: These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: Using 32 bit ASN numbers
On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Yes, and yes. The space they are given is the GLOP space ! See http://www.multicasttech.com/faq/#GLOP and http://www.shepfarm.com/multicast/glop.html Regards Marshall Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner <[EMAIL PROTECTED]> wrote: Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED] wrote: These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: Using 32 bit ASN numbers
Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner <[EMAIL PROTECTED]> wrote: > Pender, > > One small correction... For 7600, 12.2SR, the support would come out in > 12.2SRD > > Arie > > On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED] > >wrote: > > > > > These are the dates I have for Cisco platforms: > > > > IOS XR 3.4 - September 2007 > > IOS 12.0(32)S11 - November 2008 > > IOS 12.2SRE - December 2008 > > IOS 12.5(1)T - April 2009 > > > > -Original Message- > > From: andy lam [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 29, 2008 11:29 AM > > To: [EMAIL PROTECTED]; Brian Raaen > > Subject: Re: Using 32 bit ASN numbers > > > > > > Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication > Key > > Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop > > tracking enhancements. > > > > > http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 > > BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 > > bytes to 4 bytes to scale with expected Internet growth. > > > > 12.2SR* is supposed to be in late 2008, but has not yet been announced > > publicly. > > > > > > Juniper it's in JUNOS 9.1 as farr as I can tell. > > > > > > --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: > > > > From: Brian Raaen <[EMAIL PROTECTED]> > > Subject: Using 32 bit ASN numbers > > To: [EMAIL PROTECTED] > > Date: Friday, August 29, 2008, 11:04 AM > > > > I am doing some research for our company regarding 32 bit ASN numbers. I > > am > > trying to locate information about vendor and service provider support. > In > > particular I have not been able to find what Cisco IOS image I would need > > to > > load on our router to support 32 bit ASN's. I also want to know what > > experience people have had with service provider support of 32 bit ASN's > > > > -- > > Brian Raaen > > Network Engineer > > [EMAIL PROTECTED] > > > > > > > > > > > > > > >
Re: Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
On Sat, Aug 30, 2008 at 1:32 AM, Gadi Evron <[EMAIL PROTECTED]> wrote: > 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? The ASNs you ask about - as per the report - are on pages 4..8 of http://hostexploit.com/downloads/Atrivo%20white%20paper%20082808ac.pdf
Re: Using 32 bit ASN numbers
Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James <[EMAIL PROTECTED]>wrote: > > These are the dates I have for Cisco platforms: > > IOS XR 3.4 - September 2007 > IOS 12.0(32)S11 - November 2008 > IOS 12.2SRE - December 2008 > IOS 12.5(1)T - April 2009 > > -Original Message- > From: andy lam [mailto:[EMAIL PROTECTED] > Sent: Friday, August 29, 2008 11:29 AM > To: [EMAIL PROTECTED]; Brian Raaen > Subject: Re: Using 32 bit ASN numbers > > > Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key > Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop > tracking enhancements. > > http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 > BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 > bytes to 4 bytes to scale with expected Internet growth. > > 12.2SR* is supposed to be in late 2008, but has not yet been announced > publicly. > > > Juniper it's in JUNOS 9.1 as farr as I can tell. > > > --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: > > From: Brian Raaen <[EMAIL PROTECTED]> > Subject: Using 32 bit ASN numbers > To: [EMAIL PROTECTED] > Date: Friday, August 29, 2008, 11:04 AM > > I am doing some research for our company regarding 32 bit ASN numbers. I > am > trying to locate information about vendor and service provider support. In > particular I have not been able to find what Cisco IOS image I would need > to > load on our router to support 32 bit ASN's. I also want to know what > experience people have had with service provider support of 32 bit ASN's > > -- > Brian Raaen > Network Engineer > [EMAIL PROTECTED] > > > > > > >
Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html 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&Itemid=15 Gadi.
Re: HurricaneElectric
On 2008/08/29 07:45 PM Christian Koch wrote: you might want to check the obvious first :) http://www.tunnelbroker.net/forums/ [EMAIL PROTECTED] Yes, problem was my prefix was routed wrong.. so trying to get to the site was tedious and would have required turning off IPv6 only to turn it on later and whatever so .. yeah :P Anyway, it's sorted now. Thanks HE guys :) At least I know the support address now.
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 30 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 267403 Prefixes after maximum aggregation: 129611 Deaggregation factor: 2.06 Unique aggregates announced to Internet: 130029 Total ASes present in the Internet Routing Table: 29086 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25321 Origin ASes announcing only one prefix: 12271 Transit ASes present in the Internet Routing Table:3765 Transit-only ASes present in the Internet Routing Table: 83 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 584 Unregistered ASNs in the Routing Table: 211 Number of 32-bit ASNs allocated by the RIRs: 59 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:758 Number of addresses announced to Internet: 1895287072 Equivalent to 112 /8s, 247 /16s and 201 /24s Percentage of available address space announced: 51.1 Percentage of allocated address space announced: 62.1 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.3 Total number of prefixes smaller than registry allocations: 131240 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:61349 Total APNIC prefixes after maximum aggregation: 22780 APNIC Deaggregation factor:2.69 Prefixes being announced from the APNIC address blocks: 58289 Unique aggregates announced from the APNIC address blocks:26196 APNIC Region origin ASes present in the Internet Routing Table:3351 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix:885 APNIC Region transit ASes present in the Internet Routing Table:511 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 374332192 Equivalent to 22 /8s, 79 /16s and 219 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:122481 Total ARIN prefixes after maximum aggregation:64799 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks:91576 Unique aggregates announced from the ARIN address blocks: 35030 ARIN Region origin ASes present in the Internet Routing Table:12412 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix:4782 ARIN Region transit ASes present in the Internet Routing Table:1189 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 360803168 Equivalent to 21 /8s, 129 /16s and 107 /24s Percentage of available ARIN address space announced: 74.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153
Re: HurricaneElectric
you might want to check the obvious first :) http://www.tunnelbroker.net/forums/ [EMAIL PROTECTED] On Fri, Aug 29, 2008 at 5:34 AM, Colin Alston <[EMAIL PROTECTED]> wrote: > Is anyone from Hurricane Electric/TunnelBroker.net here? > >
Re: IP Fragmentation
On Fri, 29 Aug 2008 05:44:28 +0530, Glen Kent said:
> I understand, but the question is what if they dont?
If it's an alleged router, and it doesn't know how to frag a packet, it's
probably so brain-damaged that it can't send a recognizable 'Frag Needed'
ICMP back either. At that point, all bets are off...
> What do standard implementations do if they send a regular IP packet
> (no DF bit set) and receive an ICMP dest unreachable - Fragmentation
> reqd message back? Do they fragment this packet and then send it out
> again with the MTU reported in the ICMP error message, or is the ICMP
> error message silently ignored?
A quick perusal of the current Linux 2.6 net/ipv4/icmp.c source says this
case ICMP_FRAG_NEEDED:
if (ipv4_config.no_pmtu_disc) {
LIMIT_NETDEBUG(KERN_INFO "ICMP: " NIPQUAD_FMT ": "
"fragmentation needed "
"and DF set.\n",
NIPQUAD(iph->daddr));
} else {
info = ip_rt_frag_needed(net, iph,
ntohs(icmph->un.frag.mtu),
skb->dev);
In other words, if we're configured to do PMTU discovery, we cut back the MTU,
and if PMTUD is disabled, we make a note in the kernel log that something odd
happened and keep going. Note that it's by definition "odd", because if PMTUD
is disabled, we didn't *send* a packet with the DF bit set, so any ICMP error
complaining about a DF bit we didn't set is considered spurious.
pgprLOGowMKBy.pgp
Description: PGP signature
RE: Using 32 bit ASN numbers
These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: Using 32 bit ASN numbers
Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN—Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen <[EMAIL PROTECTED]> wrote: From: Brian Raaen <[EMAIL PROTECTED]> Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Using 32 bit ASN numbers
I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: Revealed: The Internet's well known BGP behavior
Jon Lewis wrote: Do you utilize the IRR, have an as-set, and put all customer AS/CIDR's into the IRR? I've honestly never heard from LVL3 about our advertisements. Other providers have varied from just needing a web form, email, phone call, or those combined with faxed LOAs. The latter gets very annoying...but maybe it is the way it should be. Level3 pull information from a number of sources, including RIPE where we register our routes. One of the nice things about their setup is you can query a whois interface to check the filter generation: e.g. (to pick someone else's AS-MACRO at random) whois -h filtergen.level3.net RIPE::AS-DEMON Sam
The Cidr Report
This report has been generated at Fri Aug 29 21:18:25 2008 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
22-08-08276915 170364
23-08-08278717 170858
24-08-08278619 170869
25-08-08278715 171104
26-08-08278889 171519
27-08-08279124 171732
28-08-08278921 172395
29-08-08279583 170820
AS Summary
29241 Number of ASes in routing system
12343 Number of ASes announcing only one prefix
5015 Largest number of prefixes announced by an AS
AS4538 : ERX-CERNET-BKB China Education and Research Network
Center
88351232 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 29Aug08 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 279883 172711 10717238.3% All ASes
AS4538 5015 881 413482.4% ERX-CERNET-BKB China Education
and Research Network Center
AS6389 4313 358 395591.7% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS209 2899 666 223377.0% ASN-QWEST - Qwest
AS4755 1720 250 147085.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS6298 2008 811 119759.6% COX-PHX - Cox Communications
Inc.
AS17488 1371 305 106677.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS18566 1046 45 100195.7% COVAD - Covad Communications
Co.
AS8151 1589 605 98461.9% Uninet S.A. de C.V.
AS1785 1650 674 97659.2% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4323 1494 560 93462.5% TWTC - tw telecom holdings,
inc.
AS22773 968 76 89292.1% CCINET-2 - Cox Communications
Inc.
AS19262 944 198 74679.0% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS11492 1214 502 71258.6% CABLEONE - CABLE ONE
AS2386 1563 917 64641.3% INS-AS - AT&T Data
Communications Services
AS9498 674 65 60990.4% BBIL-AP BHARTI Airtel Ltd.
AS6478 1134 560 57450.6% ATT-INTERNET3 - AT&T WorldNet
Services
AS18101 696 174 52275.0% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS4766 900 410 49054.4% KIXS-AS-KR Korea Telecom
AS4808 626 152 47475.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS855589 119 47079.8% CANET-ASN-4 - Bell Aliant
AS22047 564 127 43777.5% VTR BANDA ANCHA S.A.
AS7018 1431 996 43530.4% ATT-INTERNET4 - AT&T WorldNet
Services
AS9443 524 89 43583.0% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS4134 838 407 43151.4% CHINANET-BACKBONE
No.31,Jin-rong Street
AS24560 572 154 41873.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS7011 903 491 41245.6% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS7029 522 112 41078.5% WINDSTREAM - Windstream
Communications Inc
AS4668 683 274 40959.9% LGNET-AS-KR LG CNS
AS4780 717 322 39555.1% SEEDNET Digital
BGP Update Report
BGP Update Report Interval: 28-Jul-08 -to- 28-Aug-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9583 161731 2.9% 129.3 -- SIFY-AS-IN Sify Limited 2 - AS1803 102448 1.8% 78.9 -- ICMNET-5 - Sprint 3 - AS569175708 1.4%5823.7 -- MITRE-AS-5 - The MITRE Corporation 4 - AS815170862 1.3% 31.8 -- Uninet S.A. de C.V. 5 - AS905163939 1.1% 404.7 -- IDM Autonomous System 6 - AS453847320 0.8% 9.4 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS10396 39967 0.7% 579.2 -- COQUI-NET - DATACOM CARIBE, INC. 8 - AS17488 37375 0.7% 25.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS886635099 0.6% 109.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS929933606 0.6% 26.2 -- IPG-AS-AP Philippine Long Distance Telephone Company 11 - AS629833223 0.6% 15.6 -- COX-PHX - Cox Communications Inc. 12 - AS14522 32412 0.6% 158.1 -- Satnet 13 - AS638931280 0.6% 7.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 14 - AS505630874 0.6% 253.1 -- INS-NET-2 - Iowa Network Services 15 - AS346430227 0.5% 81.3 -- ASC-NET - Alabama Supercomputer Network 16 - AS28194 29473 0.5%4912.2 -- 17 - AS209 29222 0.5% 5.9 -- ASN-QWEST - Qwest 18 - AS18231 28359 0.5% 114.8 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS17974 27926 0.5% 36.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS33783 27785 0.5% 199.9 -- EEPAD TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS14593 18957 0.3% 18957.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS299108263 0.1%8263.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 3 - AS47467 14731 0.3%7365.5 -- GRIFFEL Griffel AB 4 - AS569175708 1.4%5823.7 -- MITRE-AS-5 - The MITRE Corporation 5 - AS28194 29473 0.5%4912.2 -- 6 - AS406278677 0.2%4338.5 -- RC-COLO1 - RingCentral Inc 7 - AS432993980 0.1%3980.0 -- TELECONTACT-AS Telecontact Ltd. 8 - AS23082 18566 0.3%3713.2 -- MPHI - Michigan Public Health Institute 9 - AS272455896 0.1%2948.0 -- HEIDRICK-CHICAGO - HEIDRICK 10 - AS397482137 0.0%2137.0 -- VITAS VITAS LLC 11 - AS309292110 0.0%2110.0 -- HUTCB Hidrotechnical Faculty - Technical University 12 - AS4184 4002 0.1%2001.0 -- STORTEK-WHQ - Storage Technology Corporation 13 - AS239171888 0.0%1888.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS147561796 0.0%1796.0 -- ATMOSPHERE-AS - Atmosphere 15 - AS397941782 0.0%1782.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 16 - AS30969 18315 0.3%1665.0 -- TAN-NET TransAfrica Networks 17 - AS112681651 0.0%1651.0 -- WNM-ORG - Walls New Media 18 - AS427951599 0.0%1599.0 -- XEROX-GENERAL-AS Xerox General Services 19 - AS31567 15881 0.3%1588.1 -- AKSORAN Aksoran LCC 20 - AS285421543 0.0%1543.0 -- Gobierno del Estado de Coahuila TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 75632 1.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 194.126.143.0/24 61225 1.0% AS9051 -- IDM Autonomous System 3 - 221.134.222.0/24 60139 1.0% AS9583 -- SIFY-AS-IN Sify Limited 4 - 83.228.71.0/2428026 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25757 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 72.50.96.0/20 24225 0.4% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 7 - 12.8.7.0/24 18957 0.3% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 8 - 210.214.151.0/24 14904 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 196.42.0.0/20 14593 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 10 - 89.38.98.0/23 13305 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 11 - 210.210.112.0/24 12032 0.2% AS9583 -- SIFY-AS-IN Sify Limited 12 - 221.135.80.0/24 11995 0.2% AS9583 -- SIFY-AS-IN Sify Limited 13 - 203.63.26.0/2411584 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 14 - 195.251.5.0/2411458 0.2% AS5408 -- GR-NET Greek Research & Technology Network, http://www.grnet.gr 15 - 196.27.104.0/218984 0.1% AS30969 -- TAN-NET TransAfrica Networks 16 - 83.239.192.0/218925 0.1% AS42362 -- ALANIA-AS Sevosetinelectrosvyaz 17 - 205.162.132.0/23 8880 0.1% AS23541 -- Scarlet B.V. 18 - 196.27.108.0/228849 0.1% AS30969 -- TAN-NET TransAf
HurricaneElectric
Is anyone from Hurricane Electric/TunnelBroker.net here?
Re: IP Fragmentation
On 29 aug 2008, at 2:14, Glen Kent wrote: I understand, but the question is what if they dont? Then the internet breaks.
