- Test - lists.nanog.org

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

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

27 Sep '16

On 27 Sep 2016, at 12:31, Jason Hofmann wrote: > It probably was a tough sell to get people to realize they were fully > responsible for their in-home wiring, but optional "inside wire > maintenance plans" made that clear while also adding to providers' > coffers. Perhaps something similar would work here. Concur that this is the least-improbable model, absolutely. But keep in mind that subscriptions/services for in-home wiring were (and are) also a tiny percentage of the user base. ----------------------------------- Roland Dobbins <rdobbins(a)arbor.net>

1 0

routing issues between NTT/ATT/Level3?
by Nick Ellermann 26 Sep '16

26 Sep '16

Starting on 9/23 and really bad over the weekend we have had issues with end points out on AT&T's US network specifically in the Texas and Michigan areas. When our end points with AT&T drop, we end up losing monitored endpoints on Level3's network as well. Really bad periods of packetloss. Both of which for us are utilizing NTT as our upstream out of Ashburn. We have opened a ticket with NTT. Anyone else seeing similar issues? Since about noon today 9/26, it's gotten a little better but still periods of packet loss and dropped customer VPN tunnels. Probably not bothering the average web surfer but killing our customers voip and vpn traffic. It's really hard to diagnose and fix other vendors' networks! Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann(a)broadaspect.com<mailto:nellermann@broadaspect.com> P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

1 0

is someone with BCP38.info update privs summarizing this discussion?
by Stephen Satchell 26 Sep '16

26 Sep '16

I think some pretty good information has surfaced, that would be WONDERFUL to have on that site.

1 0

Lightower (ASN:46887) RTBH community info
by Matthew Crocker 26 Sep '16

26 Sep '16

Hello, Does anyone know the RTBH community for Lightower? I’ve tried 46887:666 but that doesn’t work. I have a /32 I need to blackhole, Lightower is the last ISP and it doesn’t appear they support RTBH ☹ Thanks -Matt -- Matthew Crocker President – Crocker Communications matthew(a)corp.crocker.com<mailto:matthew@corp.crocker.com>

5 4

Re: IP addresses being attacked in Krebs DDoS?
by Alexander Maassen 26 Sep '16

26 Sep '16

Just give me thise ips so i can add em in dronebl Kind regards, Alexander Maassen - Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- Peplink Certified Engineer -------- Oorspronkelijk bericht --------Van: Brett Glass <nanog(a)brettglass.com> Datum: 25-09-16 22:01 (GMT+01:00) Aan: NANOG <nanog(a)nanog.org> Onderwerp: IP addresses being attacked in Krebs DDoS? As an ISP who is pro-active when it comes to security, I'd like to know what IP address(es) are being hit by the Krebs on Security DDoS attack. If we know, we can warn customers that they are harboring infected PCs and/or IoT devices. (And if all ISPs did this, it would be possible to curtail such attacks and plug the security holes that make them possible.) --Brett Glass, LARIAT.NET

1 0

AS4233852001 advertising 192.0.0.0/2?
by Adam Greene 26 Sep '16

26 Sep '16

We were alerted to this by https://radar.qrator.net. This seems wrong from a number of angles . Adam

3 2