Re: AS number inconsistencies
Hank Nussbacher is rumoured to have written: * >And there are only two ASes which appear, and are not registered anywhere * >- one is intermittent, the other, AS5757, has been there since I started * >this over 3 years ago. * * So what does UUnet have to say? * Who gave the permission for them to accept AS5757 from their single-homed * customer? I registered AS5757 sometime in 1995. In fact, I sent in the registration request for AS5758 for UMD within 10 minutes of AS5757. For whatever reason, the record for 5757 disappeared. You'll note that 5758 is still there, no problems. I occasionally would call up the NIC and ask them where the record went, and at the time they would tell me they could see it fine in their system, and they couldn't tell me why it wasn't appearing in the public dump. Unfortunately, I didn't push the issue. Their response eventually changed to "we don't know what you are talking about". Someone who would know told me that all older AS's were also recorded by hand in some sort of physical medium. I can't get ahold of anyone at ARIN who knows what I'm talking about, for that, either. The orginal email confirming the allocation is sitting on an 8mm tape, right in front of me. I don't have the means to retrieve the data. [Anyone have a mid-90's sun 8mm tape deck I can borrow?] 5757 wasn't intended to be singly-homed. Times have changed, and I'm between, um, providers. If it will make things easier for everyone, I'll be happy to have UUnet turn 207.19.224.67 into a static route. But that doesn't fix my disappearing record problem. I'd welcome any useful suggestions. _jenn
Re: AS number inconsistencies
hey... looks like this might actually get fixed! --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Tue, 9 Jul 2002, Hank Nussbacher wrote: > > At 02:10 PM 09-07-02 +1000, Philip Smith wrote: > > > >And there are only two ASes which appear, and are not registered anywhere > >- one is intermittent, the other, AS5757, has been there since I started > >this over 3 years ago. > > So what does UUnet have to say? > > * 207.19.224.0 152.158.76.66 0 2686 7018 701 > 5757 i > > Who gave the permission for them to accept AS5757 from their single-homed > customer? > > -Hank > >
Re: AS number inconsistencies
hmm, I'm not responsible for this kind of thing but I can certainly ASK someone... this has been from the same path for this whole time? --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Tue, 9 Jul 2002, Hank Nussbacher wrote: > > At 02:10 PM 09-07-02 +1000, Philip Smith wrote: > > > >And there are only two ASes which appear, and are not registered anywhere > >- one is intermittent, the other, AS5757, has been there since I started > >this over 3 years ago. > > So what does UUnet have to say? > > * 207.19.224.0 152.158.76.66 0 2686 7018 701 > 5757 i > > Who gave the permission for them to accept AS5757 from their single-homed > customer? > > -Hank > >
Re: AS number inconsistencies
At 02:10 PM 09-07-02 +1000, Philip Smith wrote: >And there are only two ASes which appear, and are not registered anywhere >- one is intermittent, the other, AS5757, has been there since I started >this over 3 years ago. So what does UUnet have to say? * 207.19.224.0 152.158.76.66 0 2686 7018 701 5757 i Who gave the permission for them to accept AS5757 from their single-homed customer? -Hank
Re: AS number inconsistencies
Hi Marwan, At 09:55 08/07/2002 -0400, Marwan Fayed wrote: >I am a CS PhD student trying to track ASes (for reasons I'm happy to >discuss offline). There is a grave inconsistency I have come across and >can't explain. Simply, there seems to be many AS numbers in the >non-private range that come into use at some point in time and advertise a >range of IPs, but these AS numbers are not allocated until much later. Can you give examples? Both the CIDR-Report, posted to this list, and my own Routing Report (which I spare NANOG of, but is "inflicted" on ARIN's rtma, RIPE's routing-wg, and APOPS :), look up every single AS which is present in the BGP table - any AS which is announced and is unregistered in any of the three registry databases is flagged in the report. And there are only two ASes which appear, and are not registered anywhere - one is intermittent, the other, AS5757, has been there since I started this over 3 years ago. >Does any one have any explanations? Are network operators "notified" of >their new AS number well in advance of the actual receipt of that number >on paper, for example? Any help is appreciated (and hopefully this >occurence is of interest to nanog). That tends to happen, but in my experience APNIC, ARIN and the RIPE NCC will put the entry in their database before they inform their customer of the allocation. So, examples would be good - send to me privately if you wish and I can cross reference with my own routing table views. philip --
Re: AS number inconsistencies
On Mon, 8 Jul 2002, John Todd wrote: > - Do these PASes announce "new" routes, or do they announce routes > that already exist in the global tables via some other legitimate AS? In addition to John's excellent suggestions, I'd consider the possibility that you're seeing configuration typos or transpositions. For instance, are you seeing a prefix being prematurely advertised by AS31000 which is also being correctly advertised by AS13000? Are these announcements, on average, shorter-lived than usual? Do they advertise the same prefixes before and after the RIR has actually allocated them? -Bill
Re: AS number inconsistencies
More data would be useful to answer this question. I have not done any research to answer these questions myself, but here are some additional points which may further clarify your own search: - Do these "Premature ASes" announce the same routes before and after they are registered? - Do these PASes announce "new" routes, or do they announce routes that already exist in the global tables via some other legitimate AS? - Do these PASes appear from behind the same transit ASes before and after they are registered? - Is there oscillation in appearances of these PASes before official registration? In other words, do they only appear for a few hours at a time in the period before they're officially registered? There have been instances of rogue network operators announcing networks in order to cause disruption (think DNS cache attack) in "whack-a-mole" style where the AS will appear and disappear very quickly in order to give some minimal additional difficulty in tracking down the culprit. The questions I ask above, if answers are available, would be able to classify some of these attacks and allow for further examination versus some other, yet unidentified cause. Or, is it the case that _all_ off the PASes are then legitimately registered at some point in the future? It may be the case that a savvy network attacker would pick "soon-to-be-legitimate" or "once-were-legitimate-but-are-now-unused" ASes for their attack, but I would bet that at least some would pick ASes that don't come from an easily overlooked range. JT >Hi All, > >This is my first post to this list so please forgive me if it's in any way >inappropriate, and as I know everyone has work to do, I'll try to be >brief. > >I am a CS PhD student trying to track ASes (for reasons I'm happy to >discuss offline). There is a grave inconsistency I have come across and >can't explain. Simply, there seems to be many AS numbers in the >non-private range that come into use at some point in time and advertise a >range of IPs, but these AS numbers are not allocated until much later. > >More specifically, archived BGP tables show many AS numbers which ARIN >shows not to have allocated (in their allocation history tables) until >many months, sometimes a year/two, later. The number of such ASes has >shrunk over time (from about 100 in 1999/2000 to 20-30 in 2002) but still >exists. I don't want to "name ASes" . > >Does any one have any explanations? Are network operators "notified" of >their new AS number well in advance of the actual receipt of that number >on paper, for example? Any help is appreciated (and hopefully this >occurence is of interest to nanog). > >Thanks, >--marwan > >ps. If one wishes to refer to a cluster of members of nanog, are they >referred to as "NANOs"? (Not to be confused with the salutation made >famous by tv's Mork & Mindy, of course) :-) > > >"Theatre is not supposed to change the world, > but it can show the world can change." > --unnamed director >
Re: AS number inconsistencies
On Mon, 8 Jul 2002, Marwan Fayed wrote: > I am a CS PhD student trying to track ASes (for reasons I'm happy to > discuss offline). There is a grave inconsistency I have come across and > can't explain. Simply, there seems to be many AS numbers in the > non-private range that come into use at some point in time and advertise a > range of IPs, but these AS numbers are not allocated until much later. > > More specifically, archived BGP tables show many AS numbers which ARIN > shows not to have allocated (in their allocation history tables) until > many months, sometimes a year/two, later. The number of such ASes has > shrunk over time (from about 100 in 1999/2000 to 20-30 in 2002) but still > exists. I don't want to "name ASes" . > > Does any one have any explanations? Are network operators "notified" of > their new AS number well in advance of the actual receipt of that number > on paper, for example? Any help is appreciated (and hopefully this > occurence is of interest to nanog). The most plausible explanations I can think of for people not using their ASNs in their production networks for a long time after receiving them from their RIR are: 1) There are technical challenges to be overcome before the AS can start to originate routes. For example, the AS migrations, or some other large network cutover or architecture change. 2) After the ASN is allocated, business/technical drivers shift as they often do in this industry, and the project that required the new ASN is now pushed back/scaled down/eliminated entorely. I've seen examples of both "in the wild". jms
