I'm not entirely certain what is going on but has anyone noticed some
strange announcements for 174.128.31.0/24?
I received a hijack notice that my AS (AS11708) was announcing the above
IP range. I verified that I was not when I started noticing some
strange announcements for that range. Around 10 Am CST AS11911 was
announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST
I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083).
This was from this AM around 10 AM CST:
telnet@MLX4AP3#sho ip bgp route 174.128.31.0/24
Number of BGP Routes matching display condition : 1
Prefix Next Hop Metric LocPrf Weight
Status
1 174.128.31.0/24 160.81.151.109 88 200 100
BE
AS_PATH: 1239 2914 3130 11911
Last update to IP routing table: 2h24m33s, 1 path(s) installed:
This was from this AM around 11:30 AM CST:
Number of BGP Routes matching display condition : 1
Prefix Next Hop Metric LocPrf Weight
Status
1 174.128.31.0/24 160.81.151.109 88 200 100
BE
AS_PATH: 1239 2914 3130 12083
Last update to IP routing table: 0h0m43s, 1 path(s) installed:
Same here.. got a notice this morning and while it's false, I still have
no response from Randy neither on this matter...
If they are going to involve our AS numbers and trigger alarms it would
be nice to notify us first... especially on something as major as a
prefix hijacking (potentially)
At some point 3130 announced these prefixes, and is now prepending other
ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix
hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS"
The IAR was the source of my notice as well and is what started me down
this path of cat herding.
I would think that it would only be polite to notify people about what
is going on so that other people do not waste their time looking for
phantom issues.
Absolutely - according to their website " No real or production prefixes
or data packets are being harmed in this experiment. If you become aware
that this experiment causes any actual real operational problem, please
write to us immediately. "
I have asked them to have some courtesy next time before wasting a lot
of people's time...
if you wrote me directly, you would have a response by now. almost to the bottom of my mailbox.
part of the experiment is to measure the difference between the amount of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we get in 2009 while not pre-announcing.
I agree with Paul and Michienne, having the courtesy to notify next time
would be very much appreciated. I was headed into a family member's
funeral when I received the hijack notification. I took the 15 minutes
to do some quick investigation, fire off a few emails informing my
colleagues of the issue and "arrived" at the funeral a bit late.
Perhaps in the future it would be better not to play with my toys
without asking my permission first?
- - - -
Joshua Fiske '03, '04
Network and Security Engineer
Clarkson University, Office of Information Technology
(315) 268-6722 -- Fax: (315) 268-6570
I route, therefore you are.
Think before you print.
CONFIDENTIALITY: This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited. If you received this e-mail in error,
please notify the sender and delete this e-mail from your system.
I think this is over the line. You can't put other people's IDs into
routing data on production networks. (Well, technically you can,
obviously, but you shouldn't.)
Actually, the placement of the ASN is exactly what they need to do the test, as it is treated as a routing loop and discarded. This allows for fancy reachability tests while a portion of the network cannot see the route in question.
Of course, people track their ASN usage these days and get red alarms when their ASN shows up in ways unexpected. I'm not completely sure why the ASN matters, except it's probably just a bonus service to route hijacking detection (since ASN hijacking doesn't exactly serve a purpose except to limit the route being advertised and perhaps leave someone complaining to the wrong person if the hijacker is doing bad things).
The AS_PATH attribute is a loop-avoidance mechanism, not a signature on a cheque.
AS_PATH prepending with your own and with others' AS numbers (the latter intended to effect "don't let this prefix leak into that AS") has been sitting in the inter-domain traffic engineering toolbox for years.
I see no lack of ethics in the simple act of the as-path prepend as part of a route export policy.
I think this is over the line. You can't put other people's IDs into
routing data on production networks. (Well, technically you can,
obviously, but you shouldn't.)
Actually, the placement of the ASN is exactly what they need to do the
test, as it is treated as a routing loop and discarded.
Sorry, I fail to see how apparent necessity justifies anything,
especially in an academic context.
People have been doing it forever. However, it has been considered sketchy at best.
If this were not Randy doing a research project, but, say, Cogent prepending the ASN of $LATEST_DEPEERED_NETWORK on announcements to Verio, how different would the tone of this thread have been?
If A cannot / should not do it, then the same should go for B.
If this were not Randy doing a research project, but, say, Cogent
prepending the ASN of $LATEST_DEPEERED_NETWORK on announcements to
Verio, how different would the tone of this thread have been?
