questions regarding prefix hijacking
Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin
Re: questions regarding prefix hijacking
Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T m4rtn...@gmail.com wrote: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: questions regarding prefix hijacking
On (2013-08-07 11:20 +0300), Martin T wrote: on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. -- ++ytti
Re: questions regarding prefix hijacking
On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti s...@ytti.fi wrote: On (2013-08-07 11:20 +0300), Martin T wrote: on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. I hope it has better adoption than BCP38/BCP84. :-) - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: questions regarding prefix hijacking
Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson fergdawgs...@gmail.com: Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T m4rtn...@gmail.com wrote: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: questions regarding prefix hijacking
On 8/7/13 11:13 AM, Martin T wrote: Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? Of course similar problems have occurred in the past. Just take a look at this video: http://www.youtube.com/watch?v=IzLPKuAOe50 Some minor occurrences have happened recently as well. Ciao! -- Massimiliano Stucchi
Re: questions regarding prefix hijacking
On Wed, Aug 7, 2013 at 2:13 AM, Martin T m4rtn...@gmail.com wrote: Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? Historically, most prefix hijacks have been accidental, generally due to configuration error -- for instance: http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
RE: questions regarding prefix hijacking
It has happened in the past and there is no silver bullet solution to prevent this 100%. -Original Message- From: Martin T [mailto:m4rtn...@gmail.com] Sent: Wednesday, 7 August 2013 7:13 PM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: questions regarding prefix hijacking Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson fergdawgs...@gmail.com: Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T m4rtn...@gmail.com wrote: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Re: Comcast contact
I have found Comcast rate shapes or resets long running encrypted sessions such as https. At $DAYJOB I had to set our SSL VPN system to re-key via new-tunnels every 5 minutes to keep it under their threshold of what looks like seven minutes for a tcp session. After that the sessions appeared to rate shape down to 128kbps. It may also only kick in during local POP congestion. I am assuming this is DPI trying to do peer-2-peer mitigation. We don't have such network practices and are required not to under Open Internet rules. I have no idea what was causing your VPN issue - I can use my corporate VPN for hours or days at a time with no issues. Happy to assist off list if you like. Jason
Re: Comcast contact
Andy, I posted in this list earlier in the week regarding Comcast and an issue my company was experiencing. I also posted at www.reddit.com/r/networking. I had numerous support staff from Comcast contact me over on Reddit. I would recommend posting there too. Message: 4 Date: Tue, 6 Aug 2013 11:10:30 -0500 From: Brandon Galbraith brandon.galbra...@gmail.com To: Andy Ringsmuth a...@newslink.com Cc: NANOG list nanog@nanog.org Subject: Re: Comcast contact Message-ID: cade4tyv2f4okfny2grpbckfa9gvuwjyggaq18dfbjboyljm...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Have you monitored your user's home Comcast connection with regards to packet loss or latency, preferably from network-near the SIP termination point? On Tue, Aug 6, 2013 at 10:56 AM, Andy Ringsmuth a...@newslink.com wrote: Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. Much appreciated! Andy Ringsmuth a...@newslink.com News Link ? Manager Technology Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: Comcast contact
agreed this isn't the case based on what I've seen based on my latest former employer(s). Comcast is playing by the (generally agreed upon) rules. what I have been seeing is a lot of other route optimizations changing as other providers consolidate routing among latest acquisitions. And of course, there's always the defensive changes also based said changes. constant maintenance and optimizations in recognition of the contracts. it'll sort out, the questions are what's needed to force the issue and, of course, where the standouts end up. -R On Wed, Aug 7, 2013 at 5:38 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: I have found Comcast rate shapes or resets long running encrypted sessions such as https. At $DAYJOB I had to set our SSL VPN system to re-key via new-tunnels every 5 minutes to keep it under their threshold of what looks like seven minutes for a tcp session. After that the sessions appeared to rate shape down to 128kbps. It may also only kick in during local POP congestion. I am assuming this is DPI trying to do peer-2-peer mitigation. We don't have such network practices and are required not to under Open Internet rules. I have no idea what was causing your VPN issue - I can use my corporate VPN for hours or days at a time with no issues. Happy to assist off list if you like. Jason
RE: Comcast contact
I agree it's not a lot of bandwidth, but I was grasping at straws at that point finding out about the cross country VoIP arrangement after the fact. For whatever reason, the 711 calls were full of voice clipping and call drops, 729, (with to your point, the lower MOS) worked better as despite not sounding as good, the calls stopped dropping and people's voices were no longer dropping out. Matt -Original Message- From: Rob Seastrom [mailto:r...@seastrom.com] Sent: Tuesday, August 06, 2013 11:56 PM To: Shaw, Matthew Cc: Brandon Galbraith; Andy Ringsmuth; NANOG list Subject: Re: Comcast contact Shaw, Matthew ms...@fairpoint.com writes: Make sure the remote phone is using a low bandwidth codec too. In a previous life changing a remote (home) user's phone from G.711 to G.729 made all the difference in the world to their call quality. i think you've got that backwards. 80 kbit/sec on the wire is not a lot these days, and in a world where we're conditioned to accept gsm or worse, un-transcoded g.711u sounds startlingly good. if you're so short on bandwidth that moving to a 24 kbit/sec on the wire codec makes a difference, you're on the ragged edge of being hosed. -r ___ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.
Re: questions regarding prefix hijacking
One big happening I can recall was the AS7007 incident way back in 1997. http://en.wikipedia.org/wiki/AS_7007_incident Cheers. On Wed, Aug 7, 2013 at 7:23 PM, Ahad Aboss a...@telcoinabox.com wrote: It has happened in the past and there is no silver bullet solution to prevent this 100%. -Original Message- From: Martin T [mailto:m4rtn...@gmail.com] Sent: Wednesday, 7 August 2013 7:13 PM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: questions regarding prefix hijacking Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson fergdawgs...@gmail.com: Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T m4rtn...@gmail.com wrote: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
IPAM
I have customer that we deployed Northstar for their internal ip management over 8 yrs ago. They are still using it, but it is slowly breaking on them. Can someone recommend an IPAM solution that has a Northstar import option? They have hundreds of entries detailing customer who was assigned the ip address and I would like to avoid any data massaging. TIA -- Natambu Obleton, CISSP CCIE Senior Network Engineer FastTrack Communications, Inc. 970.828.1009
Re: questions regarding prefix hijacking
On Wed, 07 Aug 2013 03:07:04 -0700, Paul Ferguson said: Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. Do I need ECC on my brain to stop the bitrot, or was there a kerfluffle a long ways back when somebody announced 127/8, and a surprising number of systems actually bit? pgp7YfnQYp_mz.pgp Description: PGP signature
RE: questions regarding prefix hijacking
From: Paul Ferguson Sent: Wednesday, August 7, 2013 3:07 AM Subject: Re: questions regarding prefix hijacking Historically, most prefix hijacks have been accidental, generally due to configuration error -- for instance... Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. - Marsh
Re: questions regarding prefix hijacking
On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? they seem to occur often enough that that isn't really required :(
Re: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts
BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it wasn't reachable? Is this an artifact? On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid chad.r...@apollogrp.edu wrote: Thanks for the assistance everyone. This issue was resolved by shutting down a BGP peering session between Time Warner and Comcast. --Chad Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu -Original Message- From: Chad Reid Sent: Sunday, August 04, 2013 7:41 AM To: 'nanog@nanog.org' Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Hello NANOG, A few hundred of our users that use Comcast in the South East United States (other regions aren't affected) are unable to access our websites in the IP block 204.17.16.0/20. Based upon testing with the users, they're getting a destination unreachable from a Comcast backbone router in ASN 7922: be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: Destination net unreachable. We're not a customer of Comcast, nor are any of our ISPs. Because of this, we can't find anyone at Comcast to look at this issue nor do we have good contact info to even reach someone. Our users in the South East can open tickets with Comcast technical support, but you can imagine how successful they are trying to explain this to frontline support and getting frontline support to understand. Is anyone from Comcast on the list that can assist or know of a contact? Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services │ IT Operations Center (ITOC) 4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040 phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- Phil Fagan Denver, CO 970-480-7618
RE: questions regarding prefix hijacking
From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, IP whitelist) When I hear about this, I would really *love* to be able to link them to a credible source. they seem to occur often enough that that isn't really required :( *I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? - Marsh
Re: questions regarding prefix hijacking
Regards Alexander Alexander Neilson Neilson Productions Limited alexan...@neilson.net.nz 021 329 681 022 456 2326 On 8/08/2013, at 9:47 AM, Marsh Ray ma...@microsoft.com wrote: From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. I would see there being a problem with Wikipedia trying to categorise some of them as accidental / malicious. I think if it was done it would have to be list where ones that were publicly announced as accidental would be listed as accidents and the rest left un noted to comply with neutral point of view and verification. do we really need that? Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, IP whitelist) When I hear about this, I would really *love* to be able to link them to a credible source. they seem to occur often enough that that isn't really required :( *I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? I would tend to say as it lists BGPmon.net as an external link thats a good resource for finding out about other ones that have happened. Also maybe that section should be renamed notable incidents and just have it as a sample of some of these incidents. - Marsh smime.p7s Description: S/MIME cryptographic signature
Re: questions regarding prefix hijacking
It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an AS3549 customer. From GBLX looking glass, ATL1 traceroute Protocol [ip]: ip Target IP address: 10.0.0.1 Source address: Numeric display [n]: n Timeout in seconds [3]: 1 Probe count [3]: 2 Minimum Time to Live [1]: 1 Maximum Time to Live [30]: 30 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.0.0.1 VRF info: (vrf in name/id, vrf out name/id) 1 te3-1-10G.par9.CTA1.GRU.gblx.net (67.16.142.26) 120 msec 124 msec 2 122.5.125.189.static.impsat.net.br (189.125.5.122) 120 msec 120 msec 3 10.0.0.1 [AS 262487] 124 msec 120 msec Apparently the customer didn't have proper inbound filter.. Reply from 10.0.0.1: bytes=32 time=132ms TTL=61 On 08/07/2013 02:20 AM, Martin T wrote: Hi, as probably many of you know, it's possible to create a route object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a route object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin
Re: IPAM
On Wed, 7 Aug 2013, Natambu Obleton wrote: I have customer that we deployed Northstar for their internal ip management over 8 yrs ago. They are still using it, but it is slowly breaking on them. Can someone recommend an IPAM solution that has a Northstar import option? They have hundreds of entries detailing customer who was assigned the ip address and I would like to avoid any data massaging. TIA I'm pretty sure that if 6connect doesn't have an existing tool to import Northstar that they'd work with your client to get it done. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
Re: questions regarding prefix hijacking
In message bd2d7aeac3fa49afa090e4869977d...@blupr03mb166.namprd03.prod.outlook .com, Marsh Ray writes: From: Christopher Morrow Sent: Wednesday, August 7, 2013 2:06 PM On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray ma...@microsoft.com wrote: It would be incredibly useful for someone to start a page or a category on Wikipedia List of Internet Routing and DNS Incidents that would include both accidental and malicious events. do we really need that? Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, IP whitelist) Yes. I've even had to configure my DHCP client to auto generate requests to get the whitelist updated when my ISP gives my cable modem a new address. They are used all the time to allow access to DNS servers. If fact we ship nameservers where the default setting whitelist particular sets of clients (directly connected) by default. When I hear about this, I would really *love* to be able to link them to a credible source. they seem to occur often enough that that isn't really required :( *I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? - Marsh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: questions regarding prefix hijacking
In message CANQy6Fb2cv+bdtaz7LVx0G_D0FbxJYqSr=ki5hfm_9qoum1...@mail.gmail.com , Paul Ferguson writes: On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti s...@ytti.fi wrote: On (2013-08-07 11:20 +0300), Martin T wrote: on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. I hope it has better adoption than BCP38/BCP84. :-) SIDR should help with BCP38/BCP84 as it allows correct filters to be securely built. Mark - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: questions regarding prefix hijacking
On 8/7/2013 2:58 PM, valdis.kletni...@vt.edu wrote: On Wed, 07 Aug 2013 03:07:04 -0700, Paul Ferguson said: Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. Do I need ECC on my brain to stop the bitrot, or was there a kerfluffle a long ways back when somebody announced 127/8, and a surprising number of systems actually bit? Seems like that might have been the first time I was annoying the Big Net Operators about why they route unroutable traffic. And a new annoying question: does it seem odd that the Big Net Operator's Private Mailing List is answering such gut basic and old news questions about how do I best destroy the Internet, should I wan t to do that? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
