April 2013 - Test - lists.nanog.org

alexandria cable cutters?
by Randy Bush 01 Apr '13

01 Apr '13

nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-int… randy

6 9

Re: BCP38 tester?
by Peter Baldridge 01 Apr '13

01 Apr '13

I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives. On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason(a)lixfeld.ca> wrote: On 2013-03-31, at 10:48 AM, Jay Ashworth <jra(a)baylink.com> wrote: > Is there a program which users can run on an end-site workstation which > would test whether they are being some link which is doing BCP38, or some > related type of source-address ingress filtering? > > I'm hoping for something that could be downloaded by users and run, and > try to forge a few packets to somewhere useful, which could be logged > somehow in conjunction with some unforged packets containing a traceroute, > so we could build up a database of leaky networks. > > On a related topic, while I know GRC Research's Steve Gibson is a bit of > a polarizing personality, he does have a fairly sizable consumer audience, > and might be a great distribution venue for such a thing. > > Or, perhaps, is there someone on here from Ookla? > > Patrick? Could Akamai be persuaded to take an interest in this as a > research project? >From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period. Most network operators are probably either too inexperienced to understand or too lazy to care. I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?

5 5

GlobalCrossing looking glass problem
by Eduardo Schoedler 01 Apr '13

01 Apr '13

Hi all, Someone is getting access to the GlobalCrossing the looking glass? # telnet route-server.gblx.net Trying 67.17.81.28... telnet: connect to address 67.17.81.28: Connection refused Thanks. -- Eduardo Schoedler

2 1

Re: Open Resolver Problems
by Brian Dickson 01 Apr '13

01 Apr '13

For filtering to/from "client-only" networks, here's the filtering rules (in pseudo-code, convert to appropriate code for whatever devices you operate), for DNS. The objective here is: - prevent spoofed-source DNS reflection attacks from your customers, from leaving your network - prevent your customers' open DNS servers (regardless of what they are) from being used in reflection attacks - permit normal DNS usage by clients, regardless of whether they are talking to an external DNS resolver, or doing their own local resolution (e.g. local DNS resolver on a host, or SOHO router) from client: permit source=client-subnet dest=any port=53 proto=TCP (TCP only works if reaches "established", i.e. spoofing is irrelevant, but we stop spoofed SYN here) permit source=client-subnet dest=any port=53 proto=UDP QR=0 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 (regardless of source/dest - either spoofed source, or QR=1, if reached this rule) to client: permit dest=any source=any port=53 proto=TCP permit dest=any source=any port=53 QR=1 (first/highest bit of 3rd octet of DNS packet payload of UDP) deny port=53 proto=UDP (QR=0 which is what we want to avoid) (We don't have to check dest==client-subnet, since routing handles this requirement) If you have "eyeball" networks, please apply liberally. Brian

1 0

AS1239 & AS701 IP Transit sales folks
by Jason Lixfeld 01 Apr '13

01 Apr '13

If there are any IP Transit sales folks[1] listening form Sprint or Verizon, please drop me a line off-list. Thanks. [1] No resellers, please.

1 0

Tier 2 ingress filtering
by Jay Ashworth 31 Mar '13

31 Mar '13

In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

12 23