September 2016 - Test - lists.nanog.org

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

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

26 Sep '16

On Sun, 25 Sep 2016 22:59:15 +0000 Stephen Satchell <list(a)satchell.net> wrote: > In short, I have yet to see a "cookbook" for BGP38 filtering, for ANY > filtering system -- BSD, Linux, Cisco. There is some here for integrating Team Cymru's bogon BGP service into various router platforms: <http://www.team-cymru.org/bogon-reference-bgp.html> John

1 0

IPv6 traffic percentages?
by nanog-isp＠mail.com 26 Sep '16

26 Sep '16

Hello all, Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic? Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook? Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6… ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-i… ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf ) I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out. Thanks, Jared

9 18

One Year On: IPv4 Exhaust
by Jay R. Ashworth 26 Sep '16

26 Sep '16

One year ago today, at 12:36pm EDT, Facebook On This Day reminds me, John Curran announced that the last IPv4 address block in ARIN's Free Pool had been assigned. How's that been workin' out for everyone? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

8 15