large BCP38 compliance testing
Hi, To fix a lot of the DDOS attacks going on, we need to make sure BCP38 compliance goes up. Only way to do this I can think of, is large scale BCP38 testing. One way of doing this, is to have large projects such as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement something that would spoof 1 packet per day or something to a known destination, and in this packet the real source address of the packet is included. I have been getting pushback from people that this might be illegal. Could anyone please tell me what's illegal about trying to send a packet with a random source address? If we can get consensus in the operational world that this is actually ok, would that help organisations to implement this kind of testing. I could see vendors implement a test like help verify network stability and compliance, these tests are anonymous checkbox during the initial install, or something like this. Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS attacks, asking people to fix their open resolvers, NTP servers etc, when the actual culprit is that some networks in the world don't implement BCP38? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Marconi Society Symposium today
will be webcast. http://isoc-ny.org/p2/7040 -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: large BCP38 compliance testing
On Thu, 2 Oct 2014, Mikael Abrahamsson wrote: these tests are anonymous checkbox during the initial install, or something like this. After posting this, I was pointed to http://spoofer.cmand.org . This seems like the exact thing I would like to test. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: large BCP38 compliance testing
On 02/10/2014 11:10, Mikael Abrahamsson wrote: Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS attacks, asking people to fix their open resolvers, NTP servers etc, when the actual culprit is that some networks in the world don't implement BCP38? ntp monlist / dnssec abuse can provide ~30x amplification. So if you can find ten 1G links anywhere in the world which aren't protected with BGP38 filtering, you can initiate a mostly untraceable 300G DDoS. This shouldn't stop us from finding, then naming and shaming operators who don't use bcp38, but we also need to maintain realistic expectations about how successful it's going to be. It would probably be more productive to pressurise transit providers to enforce bcp38 on their customer links. Nick
Re: large BCP38 compliance testing
Le 02/10/2014 12:28, Nick Hilliard a écrit : It would probably be more productive to pressurise transit providers to enforce bcp38 on their customer links. This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense. Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? What are the known downsides to uRPF-strict ? When buying from transits, you either update your IRR for automatic perfix-filter generation on your transit's side, or start by a BGP over SMTP session. While the former could generate ACLs from a template, the latter will be prone to human error. And still, how many of us _really_ ensure their IRRs are always up-to-date ? Next in line : IXPs. You never really know what routes will be available or has to be filtered when 800+ AS, most with customers also using BGP, starts talking to the same route-server. Or maybe, the route-server could provide a flowspec AFI to send filters AND routes simultaneously. Would you trust it ? Will your router have enough silicon-horse-power to match both IP _and_ L2 headers at line-rate ? BCP38 aims at spoof prevention by filtering as close to the source as possible. Implementation on network's edge looks to me like a tricky one. Sharing the load amongst CPE is the best practice, and could be considered a requirement enforced by transit providers. Or shouldn't it ? Best regards, -- Jérôme Nicolle
Re: large BCP38 compliance testing
On Oct 2, 2014, at 6:23 PM, Jérôme Nicolle jer...@ceriz.fr wrote: Le 02/10/2014 12:28, Nick Hilliard a écrit : It would probably be more productive to pressurise transit providers to enforce bcp38 on their customer links. This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense. Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? uRPF Strict mode is NOT a tool to use on the transit connections. It was built for the SP-Customer connections. uRPF VRF mode _was_ built for the transit connections. You can take all the prefixes received from the peer and stick them into a VRF. You can then check all the incoming packet source addresses against that list. If there is no match, then it was not in the BGP advertisements. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: large BCP38 compliance testing
On 02/10/2014 12:23, Jérôme Nicolle wrote: This. But let me ask you, how many transit provider actually implement strict prefix-filtering ? I've seen many using a max-prefix as their sole defense. Plenty do and have no back-end capability to handle this, other than email updates. Now, let's consider what you want is to match an interface ACL to prefixes received on a BGP session runing through the same interface. Ain't that what uRPF-strict is all about ? What are the known downsides to uRPF-strict ? Your bgp announcement to your upstream is not guaranteed to be there all the time. E.g. if you're doing maintenance and stop announcing bgp to your upstream for inbound traffic, but still want to depend on it for outbound traffic, urpf will trash things. urpf is only feasible for statically configured hand-offs. When buying from transits, you either update your IRR for automatic perfix-filter generation on your transit's side, or start by a BGP over SMTP session. While the former could generate ACLs from a template, the latter will be prone to human error. And still, how many of us _really_ ensure their IRRs are always up-to-date ? This only happens when there is a reason to do so. Next in line : IXPs. You never really know what routes will be available or has to be filtered when 800+ AS, most with customers also using BGP, starts talking to the same route-server. Or maybe, the route-server could provide a flowspec AFI to send filters AND routes simultaneously. IXPs are more difficult, but if your IXP is running a route server, they should be implementing strict prefix filtering. At least, this puts pressure on IXP participants to register their prefix at their local irrdb. Would you trust it ? Will your router have enough silicon-horse-power to match both IP _and_ L2 headers at line-rate ? probably yes on most routers with dedicated hardware for this, but it will depend on the number of acl entries. BCP38 aims at spoof prevention by filtering as close to the source as possible. Implementation on network's edge looks to me like a tricky one. Sharing the load amongst CPE is the best practice, and could be considered a requirement enforced by transit providers. Or shouldn't it ? urpf is appropriate for the ISP last hop. Static filters are suitable for the transit provider connecting that ISP to the rest of the network. Nick
Re: large BCP38 compliance testing
On 10/02/14 06:10, Mikael Abrahamsson wrote: Hi, To fix a lot of the DDOS attacks going on, we need to make sure BCP38 compliance goes up. Only way to do this I can think of, is large scale BCP38 testing. One way of doing this, is to have large projects such as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement something that would spoof 1 packet per day or something to a known destination, and in this packet the real source address of the packet is included. A proof of concept could be as simple as a basic BCP38 test implemented into the OpenWRT/DD-WRT UI. I have been getting pushback from people that this might be illegal. Could anyone please tell me what's illegal about trying to send a packet with a random source address? You could reserve yourself an IP address in a subnet you own and use that as a source IP for testing. If we can get consensus in the operational world that this is actually ok, would that help organisations to implement this kind of testing. I could see vendors implement a test like help verify network stability and compliance, these tests are anonymous checkbox during the initial install, or something like this. In short: . Test Client call the BCP38 Test Server for a Token; . Test Client send a test packet with that token in the payload; . Test Client call the BCP38 Test Server with the Token and the server returns pass of fail which is displayed back in the CPE UI; While being over simplified, BCP38.org has some perl scripts from last year NTP DDoS rush that actually does part of this. If the initial proof of concept get traction, a more complete BCP38 test set can be implemented, there is a few projects out there that could be approached for it. Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS attacks, asking people to fix their open resolvers, NTP servers etc, when the actual culprit is that some networks in the world don't implement BCP38? most networks in the world BCP38 compliance is the exception not the norm. PS: About that uRPF Convo, we could dump all that knowledges into lets say... some comprehensive wiki page maybe =D That way when the topic arise we could just link to it.
Re: large BCP38 compliance testing
On Oct 2, 2014, at 7:16 PM, Alain Hebert aheb...@pubnix.net wrote: BCP38 compliance is the exception not the norm. I'm not sure that's actually the case, practically-speaking. NAT is an awful thing for many reasons, and it's negative in terms of its overall impact on security, but there's one actual benefit from it; it is effectively a form of anti-spoofing. The prevalence of NAT on consumer broadband access networks means that those networks do not generally emit spoofed packets. The same goes for many SME networks, even though they oughtn't to be running NAT in front of their servers. My guess is that the majority, if not all, of the reflection/amplification attacks we see are actually initiated from servers under the control of attackers and residing on hosting/co-location IDC networks which don't enforce anti-spoofing at the access, distribution, or peering/transit portions of their topologies. Some of these servers are tied into so-called 'booter' systems, whereas others are linked into more conventional CC under the direct control of attackers, while still others are utilized to launch attacks 'by hand', as it were. Those networks are unmanaged and are likely to remain so (or are so-called 'bulletproof' networks catering to criminals). Their peers/upstream transits likewise are not enforcing anti-spoofing on ingress, nor are they monitoring traffic originating from these networks as it ingresses their own networks (and in any event, the traffic volume of the spoofed packets on the attack source - reflector/amplifier leg is relatively small). So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: large BCP38 compliance testing
On 10/02/14 08:37, Roland Dobbins wrote: On Oct 2, 2014, at 7:16 PM, Alain Hebert aheb...@pubnix.net wrote: BCP38 compliance is the exception not the norm. I'm not sure that's actually the case, practically-speaking. NAT is an awful thing for many reasons, and it's negative in terms of its overall impact on security, but there's one actual benefit from it; it is effectively a form of anti-spoofing. The prevalence of NAT on consumer broadband access networks means that those networks do not generally emit spoofed packets. The same goes for many SME networks, even though they oughtn't to be running NAT in front of their servers. You are right on that point, I keep forgetting about the little man :( My mindset was set on DDoS and not CC/SPAM/etc. My guess is that the majority, if not all, of the reflection/amplification attacks we see are actually initiated from servers under the control of attackers and residing on hosting/co-location IDC networks which don't enforce anti-spoofing at the access, distribution, or peering/transit portions of their topologies. Some of these servers are tied into so-called 'booter' systems, whereas others are linked into more conventional CC under the direct control of attackers, while still others are utilized to launch attacks 'by hand', as it were. We had the same experience where you get a 1Mbps steam of DDoS amplification start on the 15th and end abruptly on the 30th at 23h55m (CC report cycle/reject is often around 15 days). Then on the 5th and end 15 days later... for a few month in a row. Those networks are unmanaged and are likely to remain so (or are so-called 'bulletproof' networks catering to criminals). Their peers/upstream transits likewise are not enforcing anti-spoofing on ingress, nor are they monitoring traffic originating from these networks as it ingresses their own networks (and in any event, the traffic volume of the spoofed packets on the attack source - reflector/amplifier leg is relatively small). So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: large BCP38 compliance testing
On Oct 2, 2014, at 7:54 PM, Alain Hebert aheb...@pubnix.net wrote: My mindset was set on DDoS and not CC/SPAM/etc. My point is that the ability to launch reflection/amplification DDoS attacks (as well as spoofed SYN-floods, and so forth) is dependent upon the ability to spoof packets, and that my hunch is that there're a relatively small number of networks from which the spoofed attack traffic is emitted. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Requesting a Global Crossing contact
Could someone from Global Crossing reach out to me please? Just need to confirm you see a route and haven't had any luck accessing your looking glass in the last 24 hours. Thanks!
Re: Requesting a Global Crossing contact
On Thu, 2 Oct 2014, Eric Sieg wrote: Could someone from Global Crossing reach out to me please? Just need to confirm you see a route and haven't had any luck accessing your looking glass in the last 24 hours. Have you tried reaching out to anyone at Level3? Level3 acquired GX 3 years ago. jms
Re: large BCP38 compliance testing
Nick Hilliard wrote on 02/10/14 12:28: This shouldn't stop us from finding, then naming and shaming operators who don't use bcp38, but we also need to maintain realistic expectations about how successful it's going to be. This feels indeed like boiling the ocean, but what are the alternatives, given that we are looking at a fundamental feature in the Internet routing system - source address has no practical significance? But on another side, how easy it is to comply? The best documentation I found was “RIPE Anti-Spoofing Task Force HOW-TO”, http://www.ripe.net/ripe/docs/ripe-431, but even that doesn't cover all cases and needs updating. Are there are other useful references, besides bcp38/84 and bcp38.info? Andrei
Re: large BCP38 compliance testing
On Thu, 02 Oct 2014 12:10:39 +0200, Mikael Abrahamsson said: I have been getting pushback from people that this might be illegal. Could anyone please tell me what's illegal about trying to send a packet with a random source address? The *real* problem isn't the testing. It's the assumption that you can actually *do* anything useful with this data. Name-n-shame probably won't get us far - and the way the US works, if there's a large cartel of BCP38-compliant providers calling out the offenders by name, you might encounter an offender that finds it cheaper to send a lawyer chanting 'restraint of trade!' or similar rather than actually fixing their problem pgpaEXsQwPh_o.pgp Description: PGP signature
cogent update suppression, and routing loops
hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan
Re: cogent update suppression, and routing loops
First time I'm seeing it, and I've been a Cogent client for quite a while. Have you tried getting in touch with their NOC yet? They're one of the most responsive in the industry. On 10/3/2014 午前 01:03, ryanL wrote: hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan
Re: large BCP38 compliance testing
On Oct 2, 2014, at 10:54 PM, valdis.kletni...@vt.edu wrote: you might encounter an offender that finds it cheaper to send a lawyer chanting 'restraint of trade!' or similar rather than actually fixing their problem In several jurisdictions in APAC, at least, truth is not a defense against *criminal* defamation charges, much less in civil suits. And there are more than a few networks in APAC which haven't implemented source-address validation to the degree possible . . . -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön signature.asc Description: Message signed with OpenPGP using GPGMail
Re: cogent update suppression, and routing loops
as stated, yep. i was on the phone with them for over three hours yesterday. On Thu, Oct 2, 2014 at 9:08 AM, Paul S. cont...@winterei.se wrote: First time I'm seeing it, and I've been a Cogent client for quite a while. Have you tried getting in touch with their NOC yet? They're one of the most responsive in the industry. On 10/3/2014 午前 01:03, ryanL wrote: hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan
Re: cogent update suppression, and routing loops
i still advertise the aggregate as a backing route. one reason i might like advertising a /24 is (usually) it's a nice way to gently attract return traffic down a certain path so i can do maintenance on the other side. plenty of other ways to do this, i know (prepending, communities, etc). On Thu, Oct 2, 2014 at 9:17 AM, Peter Persson peter.pers...@bredband2.se wrote: Just a stupid question. Why do you announce a /24 of a /22? Why not announce the whole /22 directly? Regards, Peter 2014-10-02 18:03 GMT+02:00 ryanL ryan.lan...@gmail.com: hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan
Re: Requesting a Global Crossing contact
fyi, Level3 was able to help me out. (Wasn't sure how integrated the two networks were as the network I wanted checked was glbx's legacy AS.) On Thu, Oct 2, 2014 at 10:34 AM, Eric Sieg eric.s...@gmail.com wrote: Could someone from Global Crossing reach out to me please? Just need to confirm you see a route and haven't had any luck accessing your looking glass in the last 24 hours. Thanks!
Re: large BCP38 compliance testing
On Oct 2, 2014, at 8:37 AM, Roland Dobbins rdobb...@arbor.net wrote: So, the problem is that those networks which are likely to implement the various topologically-appropriate at the various edges of their network are likely to have done so. And by definition, the endpoint networks where the spoofed traffic originates aren't likely to do so, nor are their immediate peers/upstream transits - or they would've done so long ago. We have not seen support from other customers of our vendors for these features in RFI/RFP. It has taken us sometimes a year (or more) to get software fixes for uRPF related defects. The network performance can be impacted for all users due to the penalty by turning on uRPF as well, so it’s not even technically viable if you want line-rate from certain hardware sets. (See RFI/RFP). I’ve tried to collect a list of other interested parties to include this in their purchasing process with 0 takers so have put this on the back burner and just kept measuring networks that permit spoofed packets instead. It’s like any other things (e.g.: BGP hygiene), many people don’t invest the time/though/resources to cause the necessary impact. - Jared
Re: large BCP38 compliance testing
On 10/2/2014 6:10 AM, Mikael Abrahamsson wrote: Hi, To fix a lot of the DDOS attacks going on, we need to make sure BCP38 compliance goes up. Only way to do this I can think of, is large scale BCP38 testing. One way of doing this, is to have large projects such as OpenWRT, RIPE Atlas project, perhaps even CPE vendors, implement something that would spoof 1 packet per day or something to a known destination, and in this packet the real source address of the packet is included. I have been getting pushback from people that this might be illegal. Could anyone please tell me what's illegal about trying to send a packet with a random source address? If we can get consensus in the operational world that this is actually ok, would that help organisations to implement this kind of testing. I could see vendors implement a test like help verify network stability and compliance, these tests are anonymous checkbox during the initial install, or something like this. Why isn't this being done? Why are we complaining about 300 gigabit/s DDOS attacks, asking people to fix their open resolvers, NTP servers etc, when the actual culprit is that some networks in the world don't implement BCP38? A lot of the discussion on BCP38 seems to be around providers who are unintentionally allowing IP spoofing. What about providers who knowingly allow IP spoofing, because it's profitable? There's a provider that basically caters to the DDOS-as-a-service industry by selling servers with unmetered connections, where they allow IP spoofing. (If you've ever looked into this at all, you know exactly who I'm talking about).
Re: large BCP38 compliance testing
On Oct 3, 2014, at 1:24 AM, Brian Rak b...@gameservers.com wrote: What about providers who knowingly allow IP spoofing, because it's profitable? Ultimately, the only way to even possibly try to get a handle on this facet of the problem may be via lawsuits; in many jurisdictions, the burden of proof is lower for the plaintiffs in a civil case than it is for prosecutors in criminal cases. The questions of evidence, standing, jurisdiction, provable damages, et. al. then come into play . . . and when those organizations are located in areas where the rule of law isn't particularly strong, it complicates matters further. There are precedents for extraterritorial legal suits, but unless there are assets that can be seized in the event of a verdict for the plaintiff, it's unclear how much actual impact they would have. [Note: IANAL, nor do I play one on television. All of the above is uninformed speculation and may be completely wrong.] -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: cogent update suppression, and routing loops
On Thu, 2 Oct 2014, ryanL wrote: hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. Perhaps related, I made an as-path prepend change on a route advertised to Cogent yesterday and noticed it took about 10 minutes for that change to propagate throughout Cogent's network and be visible on route-views. A moment later, I did the same thing with another carrier, and got the expected nearly instant gratification. Perhaps they've got a bunch of routers configured with minimum-advertisement-interval to batch the BGP updates and if you're unlucky with the timing, it can take a while for routes/changes to percolate through their network? Imagine driving down a long road, where every traffic light turns red just before you get to the intersection. Wait a minute here, wait a minute there... -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: large BCP38 compliance testing
On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote: What about providers who knowingly allow IP spoofing, because it's profitable? What about providers who knowingly host massive spam operations, because it's profitable? As in: http://www.spamhaus.org/statistics/networks/ We've been down this road before. Unless there is prompt, concerted, collective action (as there was AGIS) then there is zero reason for those behind such operations to do anything but keep collecting dirty money. So it's all good and well to *know* where the problems are: that's useful. But if the goal is to actually make the problems go away, then that'll require fingers on keyboards implementing null routing, firewalling, blacklisting etc. ---rsk
Re: large BCP38 compliance testing
In message 20141002224754.ga7...@gsp.org, Rich Kulawiec writes: On Thu, Oct 02, 2014 at 02:24:18PM -0400, Brian Rak wrote: What about providers who knowingly allow IP spoofing, because it's profitable? What about providers who knowingly host massive spam operations, because it's profitable? As in: http://www.spamhaus.org/statistics/networks/ We've been down this road before. Unless there is prompt, concerted, collective action (as there was AGIS) then there is zero reason for those behind such operations to do anything but keep collecting dirty money. So it's all good and well to *know* where the problems are: that's useful. But if the goal is to actually make the problems go away, then that'll require fingers on keyboards implementing null routing, firewalling, blacklisting etc. Or it will require legislation and I will assure that whatever is written not be liked. On the other hand everyone one in the country will be in the same boat. ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
DDOS - Law enforcement
Hi All, I just thought I would throw a little stone out here onto towards all the law enforcement people who are inevitably watching this list. As someone who, like most of the others on this list has to deal with the effects of scumbags who send DDOS attacks towards my networks, It amazes me how you cannot put more effort into the blatant DDOS for hire platforms that are readily available to anyone. I mean how can these sites be allowed to continue unmolested when you can spend so much effort on P2P platforms ? I am referring to in particular - http://top10booters.com/ etc. How blatant do these scumbags have to be, they are even using .com addresses !
Re: DDOS - Law enforcement
On Thu, Oct 2, 2014 at 6:02 PM, Tony Wicks t...@wicks.co.nz wrote: . I mean how can these sites be allowed to continue unmolested when you can spend so much effort on P2P platforms You probably have to consider the amount of lobbying money sent toward govts in your equation. Perhaps if you also lobbied the gov'ts in a similar manner there would be resolution you'd like.
Public Policy Consultation at NANOG 62 ARIN 34 Meeting!
NANOG Folks - There are a number of proposed changes to number resource policy in the ARIN region, and you'll have two opportunities to discuss these proposals next week in Baltimore (or remotely, as you prefer) The Public Policy Consultation within NANOG takes place on Tuesday morning from 9 to 1 PM; everyone is welcome (although preregistration is required if you are not already registered for NANOG.) The ARIN 34 Meeting will follow NANOG on Thursday and Friday; we will have discussions of policy changes, as well as ARIN fee schedule, changes in the stewardship of the IANA functions, and more. Information on ARIN registration is also included in the attached message. I look forward to seeing everyone in Baltimore! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN i...@arin.netmailto:i...@arin.net Subject: [arin-announce] The PPC @ NANOG 62 ARIN 34 Will Be Here Soon – Get Ready! Date: October 2, 2014 at 1:18:17 PM EDT To: arin-annou...@arin.netmailto:arin-annou...@arin.net Next week will be busy! With the Public Policy Consultation (PPC) at NANOG 62 and ARIN 34 Public Policy and Members Meeting, we will be in the thick of important community discussions on ten policy proposals. * Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements * Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] * Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers * Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers * Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification * Draft Policy ARIN-2014-1: Out of Region Use * Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update * Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate * Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments * Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization Whether you plan to join us online or in-person, we want to make sure you are ready. To help you prepare for the meeting, ARIN has published all of the meeting materials online for you to review or download before the meeting begins. Just visit: https://www.arin.net/ppc_materials or https://www.arin.net/ARIN34_materials Copies of the presentations of the meetings will also be posted at the above URLs once the meeting has started, as they are available. We hope to see you in Baltimore, but if you are unable to join us in person, be sure to keep up with us by participating remotely! View the agenda, learn more about remote participation, and register today by visiting: The PPC at NANOG 62: https://www.arin.net/ppcnanog62 ARIN 34: https://www.arin.net/ARIN34 Please contact us at i...@arin.net if you have any questions. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)
