importance of fiber cleaning
https://www.sunet.se/blogg/long-read-cleanliness-is-a-virtue/ This is an excellent article regarding fiber cleaning and its importance. Please do share with other people in our business. I'm sure lack of proper fiber cleaning causes a lot of unneccessary outages and operational problems worldwide, partly because people aren't aware of its importance. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: "Defensive" BGP hijacking?
Hello, We wanted to clarify that we are not the ones behind these attacks and we were not the ones behind the previous hijackings. We have also been the targets of DDoS attacks reaching up to 200+ Gbps (~20 times a day), every day since Krebs' original article that included our name. We believe these attacks are coming from vDOS past customers and other botnets that used the vDOS service for launching and selling attacks. We have also been targeted with what seems to be multiple e-mail list bombs in attempts to delay our response time. As I mentioned before, NANOG's trust means everything in this industry and we want to be able to answer as much as we can. Sincerely, Bryant Townsend On Tue, Sep 20, 2016 at 8:28 PM, Tom Beecher wrote: > Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at > his site. > > https://twitter.com/briankrebs/status/778398865619836928 > > On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman wrote: > > > While I was reading the krebsonsecurity.com article cited below, the > > site, hosted at Akamai address 72.52.7.144, became non responsive and now > > appears to be offline. Traceroutes stop before the Akamai-SWIPed border > > within Telia, as if blackholed (but adjacent IPs pass through to Akamai): > > > > traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte > > packets > > 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms > > 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms > > 0.744 ms > > 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 > ms > > 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms > > 2.904 ms > > 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms > > 3.567 ms 3.401 ms > > 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 > > ms > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > > > Weird coincidence? > > > > -mel beckman > > > > > On Sep 20, 2016, at 6:46 PM, Hugo Slabbert wrote: > > > > > > Lucy, you got some (*serious*) 'splainin to do... > > > > > > http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ > > > http://krebsonsecurity.com/2016/09/ddos-mitigation-firm- > > has-history-of-hijacks/ > > > > > > -- > > > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > > > pgp key: B178313E | also on Signal > > > > > >> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher > > wrote: > > >> > > >> So after reading your explanation of things... > > >> > > >> Your technical protections for your client proved sufficient to handle > > the > > >> attack. You took OFFENSIVE action by hijacking the IP space. By your > own > > >> statements, it was only in response to threats against your company. > You > > >> were no longer providing DDoS protection to a client. You were > exacting > > a > > >> vendetta against someone who was being MEAN to you. Even if that > person > > >> probably deserved it, you still cannot do what was done. > > >> > > >> I appreciate the desire to want to protect friends and family from > > >> anonymous threats, and also realize how ill equipped law enforcement > > >> usually is while something like this is occurring. > > >> > > >> However, in my view, by taking the action you did, you have shown your > > >> company isn't ready to be operating in the security space. Being > > threatened > > >> by bad actors is a nominal part of doing business in the security > space. > > >> Unfortunately you didn't handle it well, and I think that will stick > to > > you > > >> for a long time. > > >> > > >> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend < > > bry...@backconnect.com> > > >> wrote: > > >> > > >>> @ca & Matt - No, we do not plan to ever intentionally perform a > > >>> non-authorized BGP hijack in the future. > > >>> > > >>> @Steve - Correct, the attack had already been mitigated. The decision > > to > > >>> hijack the attackers IP space was to deal with their threats, which > if > > >>> carried through could have potentially lead to physical harm. > Although > > the > > >>> hijack gave us a unique insight into the attackers services, it was > > not a > > >>> factor that influenced my decision. > > >>> > > >>> @Blake & Mel - We will likely cover some of these questions in a > future > > >>> blog post. > > >>> > > >
Re: PlayStationNetwork blocking of CGNAT public addresses
On Wed, 21 Sep 2016 11:29:49 +1000, Mark Andrews said: > What we need is business tech reporters to continually report on > these failures of content providers to deliver their services over > IPv6. 20 years lead time should be enough for any service. Interestingly enough, the Playstation 4 has at least rudimentary IPv6 support - it will DHCPv6 and answer pings. Threw me for a loop first time I saw it, I couldn't figure out what unaccounted-for gear I had that was grabbing an IPv6 address... :) pgpXiDyor6qTh.pgp Description: PGP signature
Re: "Defensive" BGP hijacking?
Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at his site. https://twitter.com/briankrebs/status/778398865619836928 On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman wrote: > While I was reading the krebsonsecurity.com article cited below, the > site, hosted at Akamai address 72.52.7.144, became non responsive and now > appears to be offline. Traceroutes stop before the Akamai-SWIPed border > within Telia, as if blackholed (but adjacent IPs pass through to Akamai): > > traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte > packets > 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms > 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms > 0.744 ms > 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms > 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms > 2.904 ms > 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms > 3.567 ms 3.401 ms > 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 > ms > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > Weird coincidence? > > -mel beckman > > > On Sep 20, 2016, at 6:46 PM, Hugo Slabbert wrote: > > > > Lucy, you got some (*serious*) 'splainin to do... > > > > http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ > > http://krebsonsecurity.com/2016/09/ddos-mitigation-firm- > has-history-of-hijacks/ > > > > -- > > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > > pgp key: B178313E | also on Signal > > > >> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher > wrote: > >> > >> So after reading your explanation of things... > >> > >> Your technical protections for your client proved sufficient to handle > the > >> attack. You took OFFENSIVE action by hijacking the IP space. By your own > >> statements, it was only in response to threats against your company. You > >> were no longer providing DDoS protection to a client. You were exacting > a > >> vendetta against someone who was being MEAN to you. Even if that person > >> probably deserved it, you still cannot do what was done. > >> > >> I appreciate the desire to want to protect friends and family from > >> anonymous threats, and also realize how ill equipped law enforcement > >> usually is while something like this is occurring. > >> > >> However, in my view, by taking the action you did, you have shown your > >> company isn't ready to be operating in the security space. Being > threatened > >> by bad actors is a nominal part of doing business in the security space. > >> Unfortunately you didn't handle it well, and I think that will stick to > you > >> for a long time. > >> > >> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend < > bry...@backconnect.com> > >> wrote: > >> > >>> @ca & Matt - No, we do not plan to ever intentionally perform a > >>> non-authorized BGP hijack in the future. > >>> > >>> @Steve - Correct, the attack had already been mitigated. The decision > to > >>> hijack the attackers IP space was to deal with their threats, which if > >>> carried through could have potentially lead to physical harm. Although > the > >>> hijack gave us a unique insight into the attackers services, it was > not a > >>> factor that influenced my decision. > >>> > >>> @Blake & Mel - We will likely cover some of these questions in a future > >>> blog post. > >>> >
Re: "Defensive" BGP hijacking?
earlier on Twitter Krebs said he was hit by 665Gbps attack (so says Prolexic/Akamai). Could be ongoing/related. Justin Paine Head of Trust & Safety CloudFlare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Tue, Sep 20, 2016 at 8:21 PM, Mel Beckman wrote: > While I was reading the krebsonsecurity.com article cited below, the site, > hosted at Akamai address 72.52.7.144, became non responsive and now appears > to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, > as if blackholed (but adjacent IPs pass through to Akamai): > > traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets > 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms > 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms > 0.744 ms > 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms > 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms > 2.904 ms > 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 > ms 3.401 ms > 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms > 7 * * * > 8 * * * > 9 * * * > 10 * * * > > Weird coincidence? > > -mel beckman > >> On Sep 20, 2016, at 6:46 PM, Hugo Slabbert wrote: >> >> Lucy, you got some (*serious*) 'splainin to do... >> >> http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ >> http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/ >> >> -- >> Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com >> pgp key: B178313E | also on Signal >> >>> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher wrote: >>> >>> So after reading your explanation of things... >>> >>> Your technical protections for your client proved sufficient to handle the >>> attack. You took OFFENSIVE action by hijacking the IP space. By your own >>> statements, it was only in response to threats against your company. You >>> were no longer providing DDoS protection to a client. You were exacting a >>> vendetta against someone who was being MEAN to you. Even if that person >>> probably deserved it, you still cannot do what was done. >>> >>> I appreciate the desire to want to protect friends and family from >>> anonymous threats, and also realize how ill equipped law enforcement >>> usually is while something like this is occurring. >>> >>> However, in my view, by taking the action you did, you have shown your >>> company isn't ready to be operating in the security space. Being threatened >>> by bad actors is a nominal part of doing business in the security space. >>> Unfortunately you didn't handle it well, and I think that will stick to you >>> for a long time. >>> >>> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend >>> wrote: >>> @ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future. @Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision. @Blake & Mel - We will likely cover some of these questions in a future blog post.
Re: "Defensive" BGP hijacking?
While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai): traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms 7 * * * 8 * * * 9 * * * 10 * * * Weird coincidence? -mel beckman > On Sep 20, 2016, at 6:46 PM, Hugo Slabbert wrote: > > Lucy, you got some (*serious*) 'splainin to do... > > http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ > http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/ > > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > >> On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher wrote: >> >> So after reading your explanation of things... >> >> Your technical protections for your client proved sufficient to handle the >> attack. You took OFFENSIVE action by hijacking the IP space. By your own >> statements, it was only in response to threats against your company. You >> were no longer providing DDoS protection to a client. You were exacting a >> vendetta against someone who was being MEAN to you. Even if that person >> probably deserved it, you still cannot do what was done. >> >> I appreciate the desire to want to protect friends and family from >> anonymous threats, and also realize how ill equipped law enforcement >> usually is while something like this is occurring. >> >> However, in my view, by taking the action you did, you have shown your >> company isn't ready to be operating in the security space. Being threatened >> by bad actors is a nominal part of doing business in the security space. >> Unfortunately you didn't handle it well, and I think that will stick to you >> for a long time. >> >> On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend >> wrote: >> >>> @ca & Matt - No, we do not plan to ever intentionally perform a >>> non-authorized BGP hijack in the future. >>> >>> @Steve - Correct, the attack had already been mitigated. The decision to >>> hijack the attackers IP space was to deal with their threats, which if >>> carried through could have potentially lead to physical harm. Although the >>> hijack gave us a unique insight into the attackers services, it was not a >>> factor that influenced my decision. >>> >>> @Blake & Mel - We will likely cover some of these questions in a future >>> blog post. >>>
Re: "Defensive" BGP hijacking?
Lucy, you got some (*serious*) 'splainin to do... http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/ -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher wrote: So after reading your explanation of things... Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done. I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring. However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time. On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend wrote: @ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future. @Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision. @Blake & Mel - We will likely cover some of these questions in a future blog post. signature.asc Description: PGP signature
Re: PlayStationNetwork blocking of CGNAT public addresses
Mark Andrews writes: > > In message <09342130-874f-4fa4-b410-b7b66a75f...@mtin.net>, Justin Wilson wri > te > s: > > PSN is one reason I am not a fan of CGNAT. All they see are tons of > > connections from the same IP. This results in them banning folks. Due > > to them being hacked so many times getting them to actually communicate > > is almost impossible. My .02 is just get the gamers a true public if at > > all possible. > > > > Justin Wilson > > j...@mtin.net > > What we need is business tech reporters to continually report on > these failures of content providers to deliver their services over > IPv6. 20 years lead time should be enough for any service. Additionally is the a role for the SEC in ensuring that companies take IPv6 seriously? If I remember correctly they got involved with Y2K. Just because there isn't a hard date it doesn't mean that IPv6 is any less important than Y2K to your business's survival. > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: PlayStationNetwork blocking of CGNAT public addresses
In message <09342130-874f-4fa4-b410-b7b66a75f...@mtin.net>, Justin Wilson write s: > PSN is one reason I am not a fan of CGNAT. All they see are tons of > connections from the same IP. This results in them banning folks. Due > to them being hacked so many times getting them to actually communicate > is almost impossible. My .02 is just get the gamers a true public if at > all possible. > > Justin Wilson > j...@mtin.net What we need is business tech reporters to continually report on these failures of content providers to deliver their services over IPv6. 20 years lead time should be enough for any service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CDN Overload?
* Jon Lewis: > This is kind of a funny problem though, because CDNs get paid to > deliver data, and they get compared/graded according to who can > deliver the bits the fastest...and here you are complaining that > they're delivering the bits too fast (or at least faster than you'd > like them to). Surely CDNs bill packets which are subsequently dropped by the network. :)
Re: CDN Overload?
This is what I'm asking of them: = Have you seen a CDN overloading a customer? Help me gather information on the issue. What CDN? What have you identified the traffic to be? What is the access network? Where is the rate limiting done? How is the rate limiting done (policing vs. queueing, SFQ, PFIFO, etc,, etc.)? What is doing the rate limiting? What is the rate-limit set to? Upstream of the rate-limiter, what are you seeing for inbound traffic? One connection or many? How much traffic? How does other traffic behave when exceeding the rate limit? Where is NAT performed? What is doing NAT? Shared NAT or isolated to that customer? Have you done a packet capture before and after the rate limiter? The NAT device? Would you be willing to send a filtered packet capture (only the frames that relate to this CDN) to the CDN if they want it? There have been reports of CDNs sending more traffic than the customer can handle and ignores TCP convention to slow down. Trying to investigate this thoroughly so we can get the CDN to fix their system. Multiple CDNs have been shown to do this. = - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Mike Hammett" To: "NANOG" Sent: Monday, September 19, 2016 12:34:48 PM Subject: CDN Overload? I participate on a few other mailing lists focused on eyeball networks. For a couple years I've been hearing complaints from this CDN or that CDN was behaving badly. It's been severely ramping up the past few months. There have been some wild allegations, but I would like to develop a bit more standardized evidence collection. Initially LimeLight was the only culprit, but recently it has been Microsoft as well. I'm not sure if there have been any others. The principal complaint is that upstream of whatever is doing the rate limiting for a given customer there is significantly more capacity being utilized than the customer has purchased. This could happen briefly as TCP adjusts to the capacity limitation, but in some situations this has persisted for days at a time. I'll list out a few situations as best as I can recall them. Some of these may even be merges of a couple situations. The point is to show the general issue and develop a better process for collecting what exactly is happening at the time and how to address it. One situation had approximately 45 megabit/s of capacity being used up by a customer that had a 1.5 megabit/s plan. All other traffic normally held itself within the 1.5 megabit/s, but this particular CDN sent excessively more for extended periods of time. An often occurrence has someone with a single digit megabit/s limitation consuming 2x - 3x more than their plan on the other side of the rate limiter. Last month on my own network I saw someone with 2x - 3x being consumed upstream and they had *190* connections downloading said data from Microsoft. The past week or two I've been hearing of people only having a single connection downloading at more than their plan rate. These situations effectively shut out all other Internet traffic to that customer or even portion of the network for low capacity NLOS areas. It's a DoS caused by downloads. What happened to the days of MS BITS and you didn't even notice the download happening? A lot of these guys think that the CDNs are just a pile of dicks looking to ruin everyone's day and I'm certain that there are at least a couple people at each CDN that aren't that way. ;-) Lots of rambling, sure. What do I need to have these guys collect as evidence of a problem and who should they send it to? - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP
Re: PlayStationNetwork blocking of CGNAT public addresses
PSN is one reason I am not a fan of CGNAT. All they see are tons of connections from the same IP. This results in them banning folks. Due to them being hacked so many times getting them to actually communicate is almost impossible. My .02 is just get the gamers a true public if at all possible. Justin Wilson j...@mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting – Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Sep 20, 2016, at 8:24 AM, Danijel Starman wrote: > > Something similar happened to a local FantasyConon I was helping set up, we > had only two PS4 machines there and accounts provided by Blizzard for > Overwatch. Outside IP of the LAN (as it was NATed) was banned by PSN in > about 8h. There was no other traffic other then those two accounts playing > Overwatch so my guess is that they have some too aggressive checks. I've > managed to convince our ISP there to change the outside IP of the link so > we got them working the next day but it happened again in 8h. > > -- > *blap* > > On Fri, Sep 16, 2016 at 3:12 PM, Simon Lockhart wrote: > >> All, >> >> We operate an access network with several hundred thousand users. >> Increasingly >> we're putting the users behind CGNAT in order to continue to give them an >> IPv4 >> service (we're all dual-stack, so they all get public IPv6 too). Due to the >> demographic of our users, many of them are gamers. >> >> We're hitting a problem with PlayStationNetwork 'randomly' blocking some >> of our >> CGNAT outside addresses, because they claim to have received anomalous, or >> 'attack' traffic from that IP. This obviously causes problems for the other >> legitimate users who end up behind the same public IPv4 address. >> >> Despite numerous attempts to engage with PSN, they are unwilling to give us >> any additional information which would allow us to identify the 'rogue' >> users >> on our network, or to identify the 'unwanted' traffic so that we could >> either >> block it, or use it to identify the rogue users ourselves. >> >> Has anyone else come up against the problem, and/or have any suggestions on >> how best to resolve it? >> >> Many thanks in advance, >> >> Simon >> >> >
Re: "Defensive" BGP hijacking?
On Sep 20, 2016, at 10:48 AM, Christopher Morrow mailto:morrowc.li...@gmail.com>> wrote: On Tue, Sep 20, 2016 at 8:05 AM, John Curran mailto:jcur...@arin.net>> wrote: ... If you want to just use your legacy address block (wth the same services that where in place at ARIN's formation), then you don't need to enter into an LRSA - but please do still update your registration in the ARIN registry to have current contact data, as this helps deter potential hijackers. If you want to have those services that were developed since ARIN's formation, then I'd suggest reviewing the actual current LRSA agreement, as it is significantly improved over earlier versions. and probably: "If you think there are still improvements, show up at arin meetings and lobby for change" yes? Absolutely. /John
Re: "Defensive" BGP hijacking?
On Tue, Sep 20, 2016 at 8:05 AM, John Curran wrote: > On Sep 19, 2016, at 11:58 PM, Christopher Morrow > wrote: > > > > (caution! I don't really think arin is evil!) > > Nor do I… (but I will remind folks that organizations evolve based on > participation, > so ongoing diligence and involvement is definitely warranted.) > > > On Mon, Sep 19, 2016 at 1:16 PM, John Curran wrote: > > > >> To be clear, he would still end up bound to an agreement which provides > >> that they > >> indemnify the RIR regarding their RPKI usage (which was the complaint > >> expressed > >> in the NANOG community regarding ARIN’s RPKI terms and conditions) - > >> > >> > > maybe, but his point was that the evil (evile?) arin would not be putting > > their clutches on his ip-address-spaces... Sure he's trading ARIN for > RIPE > > here, but I diidn't think the RPA bit was his concern as much as the LRSA > > and 'now that you agree these are ip blocks are subject to the legacy > > registry services agreement, we (arin - with twisty mustasche) might > decide > > to wrest them away from you!!!’ > > A distinct possibly, but much improved in the current LRSA (and RSA, which > are the same document at this point.) Unless he’s planning to not pay the > annual maintenance fee and ignore the notices and letters that follow over > the next 120 days, or if going to make a serious misrepresentation in the > process of claiming the rights to the address block, he’s fairly safe... > for > example, ARIN now specifically disclaims revocation for lack of > utilization. > (Furthermore, if ARIN breaches its obligations, the status of the address > block reverts to the same prior to entry the LRSA – this is definitely less > than RIPE provides, which is effectively exit at any time, but far better > than > the original LRSA.) > > If you want to just use your legacy address block (wth the same services > that > where in place at ARIN’s formation), then you don’t need to enter into an > LRSA – > but please do still update your registration in the ARIN registry to have > current > contact data, as this helps deter potential hijackers. If you want to > have those > services that were developed since ARIN’s formation, then I’d suggest > reviewing > the actual current LRSA agreement, as it is significantly improved over > earlier > versions. > > and probably: "If you think there are still improvements, show up at arin meetings and lobby for change" yes? > Thanks! > /John > > John Curran > President and CEO > [Evil?] ARIN > > > >
Re: Customers announcing communities to SP of SP
On Mon, Sep 19, 2016 at 12:00:36PM -0400, Jason Lixfeld wrote: > Hi, > > Consider the following scenario: > > - Customer A is a customer of SP A > - SP A is a customer of SP B > - SP B has a traffic engineering community implementation > > With regards to using BGP communities for TE: > > - Does SP A write their own community implementation that maps to (some > portion of) the community implementation of SP B? > - Does SP A write their own community implementation that has no mappings at > all to the community implementation of SP B; any TE that is required to be > pushed to SP B is done by some dialog and coordination between Customer A and > SP A? > - Does SP A allow Customer A to announce prefixes tagged with SP B???s > communities[1][2] "Sometimes" for all of the above; it depends on the network. There are networs which strip all signalling but their own. There are those who will strip signalling to their immediate neighbors (expecting customers to use thri own). There are some which propagate anything and everything. IME, it is generally good to sanitize an input stream of signalling you use to reduce unknown/difficult to trace conditions. It is also a good principle for a sender to be aware of how far their dollars/euros/quatloos propagate, as that's pretty much the limit of guarantee others will act on their requests. In your scenario, when SP B changes their communities, they have no obligation (nor method) to let a downstream of a downstream know about it... > - Is this sort of thing really complicated today, but one of the > goals of draft-heitz-idr-large-community? It can be complicated - review the various way folks have published their policies via the compilation up at https://onestep.net/communities/ and you'll see a number of approaches. I can't speak for the authors, but by my reading draft-heitz-idr-large-community provides two things: - parity for 32b and 16b use in communities - the room to clearly express multiple party ASNs distinctly from 'take action' data, which we do not have now Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
Re: PlayStationNetwork blocking of CGNAT public addresses
Something similar happened to a local FantasyConon I was helping set up, we had only two PS4 machines there and accounts provided by Blizzard for Overwatch. Outside IP of the LAN (as it was NATed) was banned by PSN in about 8h. There was no other traffic other then those two accounts playing Overwatch so my guess is that they have some too aggressive checks. I've managed to convince our ISP there to change the outside IP of the link so we got them working the next day but it happened again in 8h. -- *blap* On Fri, Sep 16, 2016 at 3:12 PM, Simon Lockhart wrote: > All, > > We operate an access network with several hundred thousand users. > Increasingly > we're putting the users behind CGNAT in order to continue to give them an > IPv4 > service (we're all dual-stack, so they all get public IPv6 too). Due to the > demographic of our users, many of them are gamers. > > We're hitting a problem with PlayStationNetwork 'randomly' blocking some > of our > CGNAT outside addresses, because they claim to have received anomalous, or > 'attack' traffic from that IP. This obviously causes problems for the other > legitimate users who end up behind the same public IPv4 address. > > Despite numerous attempts to engage with PSN, they are unwilling to give us > any additional information which would allow us to identify the 'rogue' > users > on our network, or to identify the 'unwanted' traffic so that we could > either > block it, or use it to identify the rogue users ourselves. > > Has anyone else come up against the problem, and/or have any suggestions on > how best to resolve it? > > Many thanks in advance, > > Simon > >
Re: "Defensive" BGP hijacking?
On Sep 19, 2016, at 11:58 PM, Christopher Morrow wrote: > > (caution! I don't really think arin is evil!) Nor do I… (but I will remind folks that organizations evolve based on participation, so ongoing diligence and involvement is definitely warranted.) > On Mon, Sep 19, 2016 at 1:16 PM, John Curran wrote: > >> To be clear, he would still end up bound to an agreement which provides >> that they >> indemnify the RIR regarding their RPKI usage (which was the complaint >> expressed >> in the NANOG community regarding ARIN’s RPKI terms and conditions) - >> >> > maybe, but his point was that the evil (evile?) arin would not be putting > their clutches on his ip-address-spaces... Sure he's trading ARIN for RIPE > here, but I diidn't think the RPA bit was his concern as much as the LRSA > and 'now that you agree these are ip blocks are subject to the legacy > registry services agreement, we (arin - with twisty mustasche) might decide > to wrest them away from you!!!’ A distinct possibly, but much improved in the current LRSA (and RSA, which are the same document at this point.) Unless he’s planning to not pay the annual maintenance fee and ignore the notices and letters that follow over the next 120 days, or if going to make a serious misrepresentation in the process of claiming the rights to the address block, he’s fairly safe... for example, ARIN now specifically disclaims revocation for lack of utilization. (Furthermore, if ARIN breaches its obligations, the status of the address block reverts to the same prior to entry the LRSA – this is definitely less than RIPE provides, which is effectively exit at any time, but far better than the original LRSA.) If you want to just use your legacy address block (wth the same services that where in place at ARIN’s formation), then you don’t need to enter into an LRSA – but please do still update your registration in the ARIN registry to have current contact data, as this helps deter potential hijackers. If you want to have those services that were developed since ARIN’s formation, then I’d suggest reviewing the actual current LRSA agreement, as it is significantly improved over earlier versions. Thanks! /John John Curran President and CEO [Evil?] ARIN
Re: CDN Overload?
What do most broadband platforms do for rate limiting? - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Matthew Walster" To: "George Skorup" Cc: "nanog list" Sent: Tuesday, September 20, 2016 2:44:24 AM Subject: Re: CDN Overload? On 20 Sep 2016 9:14 am, "George Skorup" wrote: > > Now lets move the Windows 10 updates. A 'buried in the sticks' customer on Canopy 900 FSK. 1.5Mbps/384k. Multiple streams from Microsoft and LLNW at the same time. LLNW alone had maybe 10 streams going and was sending at over 15Mbps on average and at worst about 25Mbps... to a 1.5Mbps subscriber. I could throw in a MikroTik queue upstream which only moved the problem as that 15-25Mbps was still hitting backhaul links. And when I have a 100Mbps link going into the site, 25Mbps is a lot. Maybe I'm being naive but this sounds like an issue primarily with buffers. Police rather than shape the traffic, and reduce the burst size, and a lot of this should disappear... M
Re: CDN Overload?
On 20 Sep 2016 9:14 am, "George Skorup" wrote: > > Now lets move the Windows 10 updates. A 'buried in the sticks' customer on Canopy 900 FSK. 1.5Mbps/384k. Multiple streams from Microsoft and LLNW at the same time. LLNW alone had maybe 10 streams going and was sending at over 15Mbps on average and at worst about 25Mbps... to a 1.5Mbps subscriber. I could throw in a MikroTik queue upstream which only moved the problem as that 15-25Mbps was still hitting backhaul links. And when I have a 100Mbps link going into the site, 25Mbps is a lot. Maybe I'm being naive but this sounds like an issue primarily with buffers. Police rather than shape the traffic, and reduce the burst size, and a lot of this should disappear... M
