January 2011 - Test - lists.nanog.org

ARIN and the RPKI (was Re: AltDB?)
by Christopher Morrow 07 Jan '11

07 Jan '11

Sorry for the subject change, it seems now we're talking about something perhaps more relevant to me (security and routing stuff) On Wed, Jan 5, 2011 at 5:32 PM, Randy Bush <randy(a)psg.com> wrote: > i have a rumor that arin is delaying and possibly not doing rpki that > seems to have been announced on the ppml list (to which i do not I have heard this as well ... the message in the archive is: (arin-announce actually, not ppml) <http://lists.arin.net/pipermail/arin-announce/2010-December/001107.html> Essentially the note says that Kosters & crew are delaying until Q2-2011 the deployment of RPKI services (nebulous 'other features need to be implemented due to security concerns' is the stated reason) > subscribe). as it has impact on routing, not address policy, across > north america and, in fact the globe, one would think it would be > announced and discussed a bit more openly and widely. I agree... so, what is the RPKI for and why should ops/security folks care? (and should we care enough to poke our local ARIN constabulary in the eye with a sharp stick?) I'm of the belief that if we (ops/security folks) feel the need to have a more secure routing infrastructure so we can hope to avoid incidents like: (quick examples, there are many others like these) o AS7007 full-table re-announce + re-originate o ConEdison "hijack" + re-originate o Pakistan/YT hijack + re-originate o "Pilosov/Kapela" hijacks/manipulations o Christmas TurkTelecom leak/hijack o PRC network leakages/hijacks/etc of April 2010 (Note: let's not debate if the above incidents are one/the-other hijack/mistake/etc, the simple fact is traffic was diverted and some better filtering/control would have avoided these failures in our system) We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity o routing software that can digest the enhanced data o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements I believe the lynch-pin in this is the accurate mapping of resources to authorized users, I believe that is supposed to be the RPKI system. I believe that the RPKI will tell me, an end-operator, that 63.0.0.0/9 was handed from IANA to ARIN to UUNET/VerizonBusiness and that this is being properly announced with an Origin-AS of 701. Having the service run by these organizations seems reasonable to me... IANA signs down to the RIR (ARIN in my example) and ARIN signs to VZB who can choose to sign down to their customers if necessary. Today there is a very loose, in all regions not just ARIN's, association with lots of cruft and inaccuracies. The RPKI, operated by RIR's, would provide some solid linkage and authority between resources and owners, it should help to enforce cruft management as well as provide mechanical (and relatively simple) management of the data and associated filtering/etc on devices. There is, of course, some risk with this model and we should take the time to accept/discuss that as well. Danny has had lots of good input on this topic, I'd hope that other folks who've been through longer term ops battles with filtering (jared, shane, charles gucker, rs, ras, ...) and the like can take some time to think about this problem. I'd love it if we could have some reasoned discussion here as well. Finally, everyone should go poke their ARIN corporate representative(s) (or email the BoT or AC folks directly even?) with their thoughts on whether or not the RPKI system and Routing Security are important items for ARIN (as one RIR) to pursue for the health of the Internet and Ops Sanity. The BoT folks are listed at: <https://www.arin.net/about_us/bot.html> (with email addresses even!) The AC folks are listed at: <https://www.arin.net/about_us/ac.html> -Chris

4 9

NIST IPv6 document
by Jeff Wheeler 07 Jan '11

07 Jan '11

On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco(a)ns.sol.net> wrote: > However, that's not the only potential use! A client that initiates > each new outbound connection from a different IP address is doing > something Really Good. No, Joe, it is not doing anything Good. This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. Every additional person who is expressing concern to their vendors brings us closer to a solution. In addition, if the machine can choose another random IPv6 address in the /64 for each new outgoing connection, it could just as easily source all its outgoing connections from ... a single IPv6 address that does not accept any incoming connections. I will grant that this does not prevent "magic packet" attacks against bugs in the machine in kernel space, and that the machine could be the recipient of a DoS attack; but your proposed solution has no advantage in the case of, say, SQL Slammer 6, or other attacks exploiting vulnerabilities in user-space. On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong <owen(a)delong.com> wrote: > Is there any reason we really need to care what size other people use for their Point to Point > links? > > Personally, I think /64 works just fine. > > I won't criticize anyone for using it. It's what I choose to use. You should care what size you choose, Owen. I would if I was your customer. There are several reasons why. If you configure a /64 on a point-to-point interface e.g. SONET, some current platforms will bounce any "scan" packets back and forth between the two hosts until the TTL expires, which means an attacker can saturate the point-to-point link with two orders of magnitude less attack traffic than the link capacity. This is very bad. Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem. This may be a per-interface issue on your box, or it may be a global one. In the per-interface case, most likely, the failure mode will be okay; but some vendors (including Juniper?) will eventually expire the ARP/NDP entry even though there is active traffic, and may be unable to re-learn it when needed due to the attack, which would break the link between routers. On the other hand, if it's a global issue, it will break NDP on the entire router, affecting all interfaces by whatever the platform's failure mode is. Obviously, that is worse. This is why "RFC compliant" is wrong, Owen. That a learned, experienced person such as yourself has no clue what the underlying problem is exemplifies my point: much, much more noise needs to be made about this issue. A lot of smart people have known about it for years but nothing is being done. Anyone can choose not to use /64 on their point-to-point links with no consequence to their business. Customers aren't going to choose another vendor because they are likely never even aware of it. The operational problem is that customers will want it on the PE/CE LANs, hosting center LANs, and so on; and right now, if you tell them "we can't do that," they have trouble believing you because the standard says otherwise, and a lot of other networks are currently doing it (because they think they don't have a choice other than to lose potential customers.) However, if you are running /64 instead of something like /124 on your VLANs or SONET circuits between routers, you should change this practice as soon as practical. Not doing so once you have been educated about this problem because it is "the standard" is very stupid. Pretty much every major transit network has figured this out and are doing it on their interfaces to BGP customers, too, either optionally, by default, or as the only choice. The industry standard must change to be non-hostile toward choosing a smaller subnet size than /64 to give coverage to those of us who do understand what we are doing as we roll out IPv6 to customers. -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

10 12

The FCC on IPv6
by Steven Bellovin 06 Jan '11

06 Jan '11

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-303870A1.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb

1 0

Verizon DSL Transport Contact?
by nanog＠velocity.net 06 Jan '11

06 Jan '11

Hello NANOG, Excuse me if I've missed something, but I cannot seem to get to the proper Verizon tech to get this corrected. We're an ISP in Erie, PA who "leases" Verizon DSL service. Verizon then drops this service on an ATM PVC on a DS3 that we terminate into our own gear. The current problem is that every evening between 6 and 10 pm localtime (think residential peak hours) we get packet loss (1-30%) to several DSL customers. The customers call complaining that browsing is slow and that they lose packets and cannot play games, watch Netflix, etc. There are other customers that ride the same DS3s that do not experience any packet loss. The physical DS3s are not taking errors and are well under 50% capacity during the problem period. The problem DSL circuits come from a few different COs here, ERIEPAXW and ERIEPAXS at least. All I can assume is that the DS3/OC3/etc that transports this data from some point to ERIEPAXM (where we connect via DS3) gets full. The problem goes away after 10pm and crops back up the next day. Sometimes it lasts 15 minutes, sometimes all 4 hours. I have detailed logs and locations of the circuits to provide to a Verizon tech if needed. Thanks, Velocity.Net

2 1

Where to go for connectivity in VA / DC
by bas 06 Jan '11

06 Jan '11

Hi, We've recently opened a POP in northern Virginia. The DC does not have a lot of connectivity options to choose from. So we've ordered dark fiber to Equinix Ashburn DC2, we will light it up with our own DWDM, and pick up connectivity there. We do however need a second point to pick up connectivity for redundancy purposes. (that runway from IAD is pretty scary) Initially we had thought to pick up that connectivity at Coresite K-street. However many of the carriers we use are not available at K-street. What would you guys advise us to go to for lots of connectivity options. Thanks, Bas

2 1

The tale of a single MAC
by Graham Wooden 06 Jan '11

06 Jan '11

Hi there, I encountered an interesting issue today and I found it so bizarre so I thought I would share it. I brought online a spare server to help offload some of the recent VMs that I have been deploying. Around the same time this new machine (we¹ll call it Server-B) came online, another machine which has been online for about a year now stopped responding to our monitoring (and we¹ll name this Server-A). I logged into the switch and saw that the machine that stopped responding was in the same VLAN as this newly deployed, and then quickly noticed that Server-A¹s MAC address was now on Server-B¹s switch port. ³What the ...² was my initial response. I went ahead and moved Server-B¹s to another VLAN, updated the switchport, cleared the ARP, and Server-A came back to life. Happy new year to me. So here is the interesting part... Both servers are HP Proliant DL380 G4s, and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not spoofd and the OS drivers are not mucking with them ... They¹re burned-in I triple checked them in their respective BIOS screen. I acquired these two machines at different times and both were from the grey market. The ³What the ...² is sitting fresh in my mind ... How can this be? In the last 15 years of being in IT, I have never encountered a ³burned-in² duplicated MACs across two physically different machines. What are the odds, that HP would dup¹d them and that both would eventually end up at my shop? Or maybe this type of thing isn¹t big of deal... ? -graham

24 31

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 06 Jan '11

06 Jan '11

Dear Colleagues, The RIPE NCC received the following AS Number Blocks from the IANA in January 2011. 56320-57343 57344-58367 197632-198655 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

Spamming and ssh attack from a customers
by Tarig Ahmed 06 Jan '11

06 Jan '11

hi all I am receiving emails from many servers saying that: this ip (from a customer) is trying to attacking one of our servers. Is it appropriate to filter ssh, telnet, and smtp from my customers, or just forward the message to my customer contact persons? Thanks in advance.. Tarig Yassin Ahmed

4 3

Qwest access problems
by Wes Bachman 06 Jan '11

06 Jan '11

Anyone seeing problems with Qwest access circuits this evening? Our AT&T GigE circuit with Qwest LEC has bounced twice. Oddly when I went to check it out from home, my Qwest DSL was down at the exact same time, and appeared to come back up at around the same time. I'm in eastern Iowa. I haven't heard anything from Qwest or AT&T so far, and received no notice of any planned maintenance? -Wes Bachman Leepfrog Technologies, Inc.

1 0

Clearwire/Clear for branch office connectivity?
by Brandon Galbraith 06 Jan '11

06 Jan '11

Is anyone using Clearwire/Clear's wireless broadband offering for stationary branch offices/remote equipment monitoring? Looking for results/experiences off-list. We're looking at it for industrial telemetry, and have spoken to people using ATT and VZW who are doing the same, but we wanted to look at Clear as well. Curious as to reliability, link performance, and support quality. Thanks! Brandon -- Brandon Galbraith US Voice: 630.492.0464

8 7