September 2016 - Test - lists.nanog.org

PeeringDB Product Committee Charter Survey / NANOG
by Arnold Nipper 29 Sep '16

29 Sep '16

Hello PeeringDB users / hello NANOG, the PeeringDB Product Committee (PC, [0]) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. We're looking for feedback and input from the community on our charter proposal. Please take this short survey [1]. Your input and comments are appreciated! [0] http://docs.peeringdb.com/gov/ [1] https://www.surveymonkey.com/r/JN36DT2 Greetings Arnold -- Arnold Nipper email: arnold(a)nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9

1 0

Go Daddy contact
by Feldman, Mark 29 Sep '16

29 Sep '16

Can someone from Go Daddy contact me off-list about a shared customer issue? Mark Comcast DNS

1 0

Re: BCP38 adoption "incentives"?
by larrysheldon＠cox.net 29 Sep '16

29 Sep '16

---- Alain Hebert <ahebert(a)pubnix.net> wrote: > Do not forget the "NRA" ways. I do not understand the "NRA" reference.

1 0

contact @ detroit pistons IT/network org?
by david raistrick 28 Sep '16

28 Sep '16

by chance - anyone have a clueful contact at the detroit pistons who can help resolve an https MITM proxy problem? (likely a misconfigured watchguard.) trying to diagnose a proxy level certificate problem through a management level proxy is less than fun.....

1 0

CDN Overload?
by Mike Hammett 28 Sep '16

28 Sep '16

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

12 24

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey
by Alexander Maassen 28 Sep '16

28 Sep '16

If those where in fact non-spoofed sources, then i am surely interested in getting that list in order to put it into my dnsbl (dronebl). So if someone has it, or can tell me who to contact. Feel free to provide me with it offlist. Especially if this botnet uses one of the many irc networks (like undernet) that is utilizing the dnsbl list and the cc is harbored there, it might help. Also, most 'admins' only start realizing something is wrong in their network once their precious bizmail won't arrive at clients because their infected ip is listed and the remote mx refuses the mail because of the listing. Kind regards, Alexander Maassen - Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- Peplink Certified Engineer -------- Oorspronkelijk bericht --------Van: Hugo Slabbert <hugo(a)slabnet.com> Datum: 26-09-16 05:54 (GMT+01:00) Aan: "John R. Levine" <johnl(a)iecc.com> Cc: nanog(a)nanog.org Onderwerp: Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey On Sun 2016-Sep-25 17:01:55 -0400, John R. Levine <johnl(a)iecc.com> wrote: >>https://www.internetsociety.org/sites/default/files/01_5.pdf >> >>The attack is triggered by a few spoofs somewhere in the world. It is not >>feasible to stop this. > >That paper is about reflection attacks. From what I've read, this was >not a reflection attack. The IoT devices are infected with botware >which sends attack traffic directly. Address spoofing is not particularly >useful for controlling botnets. But that's not only remaining use of source address spoofing in direct attacks, no? Even if reflection and amplification are not used, spoofing can still be used for obfuscation. >For example, the Conficker botnet generated pseudo-random domain names >where the bots looked for control traffic. > >>Please see https://www.ietf.org/rfc/rfc6561.txt > >Uh, yes, we're familiar with that. We even know the people who wrote >it. It could use an update for IoT since I get the impression that in >many cases the only way for a nontechnical user to fix the infection >is to throw the device away. > >Regards, >John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", >Please consider the environment before reading this e-mail. https://jl.ly -- Hugo Slabbert | email, xmpp/jabber: hugo(a)slabnet.com pgp key: B178313E | also on Signal

1 0

Re: Providing transit to unallocated networks
by Alistair Mackenzie 28 Sep '16

28 Sep '16

Thanks for this, it shows as apnic|ZZ|ipv4|103.***.***.0|1024|20160927|reserved||e-stats I expect this still stands with it being reserved? William, it's 100% an apnic range and shows no org and is registered to the APNIC Hostmaster. This applies for both the ASN and the address space. On 28 September 2016 at 01:28, William Herrin <bill(a)herrin.us> wrote: > On Tue, Sep 27, 2016 at 8:18 PM, Alistair Mackenzie <magicsata(a)gmail.com> wrote: > > I've come across a network which seem to be getting transit yet both the > > ASN and IP space is not allocated by the RIR. > > Hi Alistair, > > There is still unicast address space that isn't allocated by any RIR? > > Seriously though, check all your bases. Is not the space unallocated > by all RIRs or just the one you expect to hold it? If you have a > transit provider that's not playing by the rules, contact their > transit providers to complain and if you still don't get satisfaction, > I'd name and shame the lot of them. Failure to filter bad actors is > how prefix hijacking happens. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us > Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> > > On 28 September 2016 at 01:36, George Michaelson <ggm(a)algebras.org> wrote: > check if the block is in this file. > > http://labs.apnic.net/delegated-nro-extended > > If not, then the block is hijacked or being abused. > > the file format is a bit obscure: the ipv4 record is base-ip|hostcount > but converting that to prefix length is pretty simple. > > -G > > On Wed, Sep 28, 2016 at 10:18 AM, Alistair Mackenzie > <magicsata(a)gmail.com> wrote: > > Hi, > > > > I've come across a network which seem to be getting transit yet both the > > ASN and IP space is not allocated by the RIR. It does appear at some > point > > that it was valid however this is no longer the case. > > > > The network is single homed and I tried asking the transit provider what > > their policy was on this but got no answer. > > > > Has anyone seen anything like this? What has happened in the past with > > things like this? > > > > Thanks, > > Alistair >

2 1

Providing transit to unallocated networks
by Alistair Mackenzie 28 Sep '16

28 Sep '16

Hi, I've come across a network which seem to be getting transit yet both the ASN and IP space is not allocated by the RIR. It does appear at some point that it was valid however this is no longer the case. The network is single homed and I tried asking the transit provider what their policy was on this but got no answer. Has anyone seen anything like this? What has happened in the past with things like this? Thanks, Alistair

3 3

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey
by John Kristoff 27 Sep '16

27 Sep '16

On Sun, 25 Sep 2016 14:36:18 +0000 Ca By <cb.list6(a)gmail.com> wrote: > As long as their is one spoof capable network on the net, the problem will > not be solved. This is not strictly true. If it could be determined where a large bulk of the spoofing came from, public pressure could be applied. This may not have been the issue in this case, but in many amplification and reflection attacks, the originating spoof-enabled networks were from a limited set of networks. De-peering, service termination, shaming, etc could have an effect. John

13 14

BCP38 -- disabusing misinformation in this discussion
by Stephen Satchell 27 Sep '16

27 Sep '16

"BCP38 applies only to egress filtering" INCORRECT. The title of the update to BCP38/RFC2827, BCP84/RFC2074, exposes the balderdash on its face. That title? "Ingress Filtering for Multihomed Networks." Oops. This is a short snipping from the Introduction: > RFC 2827 recommends that ISPs police their customers' traffic by > dropping traffic entering their networks that is coming from a source > address not legitimately in use by the customer network. ENTERING, not LEAVING. QED (Although I can understand some of the confusion. Some people might IMPLEMENT BCP38 using egress filtering, relying on the infamous "as-if" rule. Indeed, in my implementation of BCP38, I implement it on both INPUT and OUTPUT, so that it traps nasty traffic generated within the four corners of the system on which the firewall runs. This works for servers, particularly servers with multiple virtual guests.) .......... Looking at RFC 2827 (I couldn't sleep, so here I am in the middle of the dark reading RFCs) Section 3, this paragraph appears: > In the example above, the attacker resides within 204.69.207.0/24, > which is provided Internet connectivity by ISP D. An input traffic > filter on the ingress (input) link of "router 2", which provides > connectivity to the attacker's network, restricts traffic to allow > only traffic originating from source addresses within the > 204.69.207.0/24 prefix, and prohibits an attacker from using > "invalid" source addresses which reside outside of this prefix range. > In other words, the ingress filter on "router 2" above would check: > > IF packet's source address from within 204.69.207.0/24 > THEN forward as appropriate > > IF packet's source address is anything else > THEN deny packet > > Network administrators should log information on packets which are > dropped. This then provides a basis for monitoring any suspicious > activity. (Note that "router 2" in the diagram is the router to which the attacker is talking, not a router on upstream ISPs A, B, C, and D. Although I guess router 2 could be owned by the ISP...) So, if I'm reading the RFC correctly, my original assertion that BCP mandates routers block "the bad stuff" on output, but ALSO on input. In fact, I don't see any discussion of output filtering in the RFC -- show me where it does, please. Now getting back to the discussion of uRPF (Unicast Reverse Path Forwarding), the RFC also talks about this: > ... The method > suggested is to look up source addresses to see that the return path > to that address would flow out the same interface as the packet > arrived upon. With the number of asymmetric routes in the Internet, > this would clearly be problematic. That description roughly corresponds with Cisco's definition of "strict". My question is whether my simplified example in a prior rock would correspond with Cisco's definition of "loose" -- you allow any source address in any downstream or local subnet the router knows about. ..... Just to show that I do read entire RFCs, here is this little nugget, from RFC 2827, Section 5: > If ingress filtering is used in an environment where DHCP or BOOTP is > used, the network administrator would be well advised to ensure that > packets with a source address of 0.0.0.0 and a destination of > 255.255.255.255 are allowed to reach the relay agent in routers when > appropriate. The scope of directed broadcast replication should be > controlled, however, and not arbitrarily forwarded. In the SOHO environment, the problem is moot because the DHCP is usually provided on the first router. (That's true in my home, and in businesses where I have installed networking.) In larger networks, or with ISPs that insist on doing DHCP upstream from a router, this is an issue.

1 0