June 2012 - Test - lists.nanog.org

ROVER routing security - its not enumeration
by Daniel Massey 11 Jun '12

11 Jun '12

Hi, Just wanted to clarify a few things about the ROVER approach. One key misunderstanding seems to be that ROVER is an approach for enumerating all potentially valid routes. This is not the case. Slides on ROVER are posted for the NANOG 55 talk and there was an additional Lightning talk Monday in NANOG A good summary of misunderstandings are listed below and addressed below: > Summarizing a few other things other people have mentioned: > > - The normal operating mode with RPKI is to fetch everything rather > than do a point query. We've spent the last decade or so making > that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead > of NSEC, etc). This makes it fairly difficult to know in advance > what queries one should be asking ROVER (as Paul Vixie puts it, > ROVER isn't a catalogue). When I pressed the ROVER folks about this > at the Paris IETF meeting, they mumbled something about maybe > walking the IRR or other external databases as a way of knowing what > DNS queries to issue. ROVER's operational model is ask a question and get an answer. ROVER is not an enumeration method. RPKI does provide enumeration, but ROVER is not trying to duplicate RPKI. I think the first step is to step back and ask whether every operational model needs enumeration. For example, the talk yesterday by Level3 used the DNS and IRR did not need such an enumeration. Enumeration is not a goal in itself. There are number of operational models that provide the needed routing protection without enumeration. > - Circular dependencies are a problem. Helical dependencies can be > made to work, but this says that one probably should not be > depending on routing to make a point query to make decisions about > routing. If you look at the architecture of the existing RPKI > validators (well, mine and BBN's, anyway, not sure about RIPE's but > suspect they took the same approach), we've gone to some trouble to > make sure that the validator will continue to work across network > outages as long as the collected data haven't expired or been > revoked. In theory one could do the same thing with bulk transfers > of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it > would not work well with point queries. Or a simpler approach that does not require bulk zone transfers or zone walking is simply DNS caching, which already exists and is well understood. More broadly, whether one calls its a cache or RPKI validator or whatever, you can build it with redundancy. One can certainly make either system work across network outages. > - ROVER gives us no traction on path validation (BGPSEC), it's limited > to origin validation. RPKI can certify both prefixes and ASNs, > which gives it the basics needed to support path validation as well > as origin validation. ASNs have no hierarchical structure, thus > would be a very poor match for encoding as DNS names. The focus is on origin and sub prefix hijacks. There are certainly discussions and early experiments with future additions, but the work is focused on origin/subprefix events. > - Some of the DNS aspects of ROVER are a little strange. In > particular, as currently specified ROVER requires the relying party > to pay attention to DNS zone cuts, which is not normal in DNS (the > basic DNS model since RFC 883 has been that zones are something for > the zone administrator to worry about, resolvers mostly just see a > tree of RRsets). ROVER requires the relying party to check for the > same data in multiple zones and pay close attention to zone cuts. > While it is certainly possible to do all this, it is not a matter of > issuing a simple DNS query and you're done. DNS caching effects can > also complicate matters here if the zone structure is changing: > think about what happens if you have cached responses to some (but > not all) of the queries you need to make to figure out whether to > allow a more specific route punched out of a larger prefix block. > This is a misunderstanding of the ROVER approach. Multiple copies of the data do not exist in multiple zones. There is a one-to-one mapping between a prefix and a DNS name. The resolver simply finds the data and has no need to understand where zone cuts occur. On the other hand, DNS administrators do care about how they make zone cuts and delegate to their customers. They can take a /16 and delegate two /17's, or they can manage the whole thing in a single zone. Their choice. A resolver simply issues a query for the unique DNS name associated with a prefix. This could be done with anything from a complex tool set to a simply command line tool like dig. The confusion here may arise from what happens if you get an *authenticated* response saying there is no routing data at this name. This could mean 1) the prefix should not be announced or 2) the reverse DNS happens to be signed with DNSSEC but the site is not participating in routing security via DNS. To determine this, you issue a second query. Is an RLOCK present along with the DNSKEY used to sign the data? The existence of an RLOCK proves participation. > - The reuse of existing infrastructure argument for ROVER is somewhat > disingenuous -- it's only partial reuse of existing infrastructure. > ROVER's new encoding of prefixes as DNS names means that a lot of > new stuff would need to be deployed, and attempting to be backwards > compatible with the existing DNS reverse tree adds some complexity > to ROVER's architecture I strongly disagree with this. ROVER does use a naming convention. This is simply a convention, not a protocol change. The best analogy here is that one may have an internal naming convention for naming routers or particular servers or so forth. You should follow this convention and build this into your provisioning scripts where appropriate. Clearly it is enormously better if there is a consistent way to name prefixes so we have a common convention for naming the data. Everyone putting data in is using the convention and we are working to get the convention standardized. The convention is also useful for storing data at prefixes; geolocations is one example. > (conflicting data for same prefix can appear > in multiple zones, relying party has to sort this out, yum). Again, this is simply a naming convention. There is a unique name for a prefix. To DNS, this is a name like any other name. A DNS name belongs to a zone. It cannot appear in multiple zones. The prefix has a unique name. The name cannot appear in multiple zones. ROVER is not trying to do exactly what RPKI is doing. Much of this seems to be an attempt to build a form of enumeration into ROVER. See the Level3 NANOG talk from Monday (6/4/12) for a concrete example of a different model. There are many different operational models. We seek a common convention for data publishing, but believe strongly there can and should be different operational models for how you do validation in your network. Thanks, Dan and Joe

7 12

Dear Linkedin,
by Michael Thomas 10 Jun '12

10 Jun '12

Linkedin has a blog post that ends with this sage advice: * Make sure you update your password on LinkedIn (and any site that you visit on the Web) at least once every few months. I have accounts at probably 100's of sites. Am I to understand that I am supposed to remember each one of them and dutifully update them every month or two? * Do not use the same password for multiple sites or accounts. So the implication is that I have 100's of passwords all unique and that I must change every one of them to be something new and unique every few months. And remember each of them. And not write them down. * Create a strong password for your account, one that includes letters, numbers, and other characters. And that each of those passwords needs to be really hard to guess that I change to every few months on 100's of web sites. I'm sorry, my brain doesn't hold that many passwords. Unless you're a savant, neither does yours. So what you're telling me and the rest of the world is impossible. What's most pathetic about this is that somebody actually believes that we all really deserve this finger wagging. Mike

19 37

Timeframe for LinkedIn Attack?
by Oliver Garraux 10 Jun '12

10 Jun '12

Hey, I'm curious if anyone has heard of a possible timeframe for the LinkedIn attack? I use different email aliases on most websites I sign up for. (So I can identify where a spammer got my email address from and so I can just remove the alias if I get spammed a lot). I've been testing some scripts I wrote to parse through my email logs recently, and noticed a few interesting log entries from back in May. I have accounts on Last.fm and on LinkedIn (using email aliases). I received a spam message on the email alias I use for LinkedIn on May 10. I also received four spam messages on the email alias I use for Last.fm on May 10. The LinkedIn related message came in at 20:22 UTC. The four Last.fm messages came in between 21:26 and 21:51 UTC. All of these messages were rejected because the IP the connection came from was listed on Spamhaus’s XBL (they came from 5 different IP's). I don't think this necessarily proves anything beyond a shadow of a doubt - but it seems really suspicious to me, given that I've never seen any other spam directed to these address before or after May 10, and that the email addresses for both of these sites that were compromised were spammed for the first time on the same day. (And none of the other 100+ email aliases I have received spam for the first time on that day). This would suggest to me that LinkedIn and Last.fm may have been compromised at least a month ago. Has anyone else seen anything that would confirm or refute this? Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux

2 1

Open DNS Resolver reflection attack Mitigation
by Joe Maimon 10 Jun '12

10 Jun '12

Is there any publicly available rate limiting for BIND? How about host-based IDS that can be used to trigger rtbh or iptables? Google and Level3 manage to run open resolvers, why cant I? Joe

5 8

CVV numbers
by Hal Murray 10 Jun '12

10 Jun '12

In response to my comment about: > If I'm not supposed to not "tell anyone", why is it even printed where I can > read it? (Sorry for the extra not in there.) I got an off list suggestion of: http://www.cvvnumber.com/ It looks reasonable. But then, whois for cvvnumber.com says: Registrant: Domains By Proxy, LLC DomainsByProxy.com 15111 N. Hayden Rd., Ste 160, PMB 353 Scottsdale, Arizona 85260 United States Should I really take them seriously? -- These are my opinions. I hate spam.

15 19

Re: Dear Linkedin,
by Hal Murray 10 Jun '12

10 Jun '12

>> I have accounts at probably 100's of sites. Am I to understand >> that I am supposed to remember each one of them and dutifully >> update them every month or two? > Yes; of course if most of those accounts are moribund and unused then you > don't need to change them so often, but the passwords you use frequently > should be changed at regular intervals. > It's pretty commonsensical once the threat is understood. Does anybody have a good URL explaining that idea? It's been kicking around for many years. I've never seen a convincing writeup. Does your bank request/require that you change the PIN on your ATM card every few months? Security is a tradeoff. I think there are two cases for passwords. I'll call them important and junk. I'm willing to store the junk ones in a file or piece of paper that I'm careful with. I have to memorize the important ones. I'm only smart enough to memorize a few good passwords. If I change them every few months, they will be less good, or fewer of them. -- These are my opinions. I hate spam.

6 7

Re: Dear Linkedin,
by Scott Weeks 09 Jun '12

09 Jun '12

--- lyndon(a)orthanc.ca wrote: From: Lyndon Nerenberg <lyndon(a)orthanc.ca> On 2012-06-08, at 12:48 PM, Michael Thomas wrote: > I'm sorry, my brain doesn't hold that many passwords. Unless you're > a savant, neither does yours. So what you're telling me and the rest > of the world is impossible. t :: https://agilebits.com/onepassword (1Password) is one solution to :: managing web site passwords. ---------------------------------------------------------------- Only if you have an OS you have to pay for: apple or ms. scot

8 7

ITU funsies
by Joe Provo 09 Jun '12

09 Jun '12

While we will expect to see the Patrick S. Ryan & Jacob Glick paper linked on http://www.nanog.org/meetings/nanog55/abstracts.php?pt=MTk0OCZuYW5vZzU1&nm=… at some point, folks wanting a head start on digesting it can hit http://ssrn.com/abstract=2077095 Interestingly enough, http://wcitleaks.org/ launched last Wednesday... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG

2 1

AUT-NUM ROUTE OBJECT
by Peter Ehiwe 09 Jun '12

09 Jun '12

Please can any one familiar with route object creation help with understanding this error I am having a weird error with AUT-NUM object , even though i am using the correct maintainer password i keep getting this error message. Authorisation for parent [as-block] using mnt-lower: not authenticated by: RIPE-NCC-RPSL-MNT ***Info: Authorisation for [aut-num] using mnt-by: authenticated by: XXXXX -- Warm Regards

2 2

Re: Dear Linkedin, [and proposed mitigation approach
by Hal Murray 08 Jun '12

08 Jun '12

> Yes, well, I'm being cynical ... Yes, but are you being cynical enough? ---------- > Is 14 months a excusable length of time for someone not to have > changed their password after a break? That cuts both ways. Who is changing the password, the good guys or the bad guys? -- These are my opinions. I hate spam.

1 0