Re: SIXSS not working?
> still wondering why this is on NANOG maybe ipv6 is becoming relevant to operations? randy
Re: SIXSS not working?
On 2012-06-20 23:23, Hank Nussbacher wrote: > At 19:25 20/06/2012 -0400, Kyle Creyts wrote: > > Until such time that Sixxs responds as to what happened, it will all be > conjecture. > > -Hank > >> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1820 possibly >> related? I pointed to the status page for a reason, the sessions are up for a much longer time than that. But yes, we are fully aware that the quagga and the rest of GRH needs to be swapped out with a better bgpd etc, something with time etc though. Greets, Jeroen (still wondering why this is on NANOG, but ala, seems it is important enough to discuss here which is cool though ;)
Re: SIXSS not working?
At 19:25 20/06/2012 -0400, Kyle Creyts wrote: Until such time that Sixxs responds as to what happened, it will all be conjecture. -Hank http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1820 possibly related? On Wed, Jun 20, 2012 at 11:34 AM, Jeroen Massar wrote: > Good morning (at least on this side of the planet), > > On 2012-06-20 02:14, Hank Nussbacher wrote:> On Wed, 20 Jun 2012, Jeroen > Massar wrote: >> >> Ill report it to them but: > > NANOG is afaik still not the "contact the people who run things" email > address... > > Nevertheless, if issues, do not hesitate to report to i...@sixxs.net > >> http://www.sixxs.net/tools/grh/tla/ >> Shows every country as V=0 (prefixes visible per country). > > That would mean that every prefix was not updated in the last day, > sounds odd to me. > > On 2012-06-20 04:00, Hank Nussbacher wrote: >> On Wed, 20 Jun 2012, Hank Nussbacher wrote: >> >> It would appear that whatever was broken is now fixed. > > The only thing I can think of is that you have noticed some weird glitch > of the kind there. > > As mentioned above the "Visible" is basically the amount of prefixes > visible in the last 24 hours. For that to become 0 it would have meant > that no prefix would have been seen for the last 24 hours. > > According to http://www.sixxs.net/tools/grh/status/ which just telnets > into grh.sixxs.net and asks for quagga's status, seems that even peering > sessions are connected for longer than that, thus I am puzzled to what > could have caused that then. > > Greets, > Jeroen > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
PIM survey for operators
The IETF pim working group is conducting a survey in order to advance the PIM Sparse Mode spec on the IETF Standards Track, and would like input from operators. The survey ends July 20th. Please see below for more information. thank you, pim chairs Mike & Stig Introduction: PIM-SM was first published as RFC 2117 in 1997 and then again as RFC 2362 in 1998. The protocol was classified as Experimental in both of these documents. The PIM-SM protocol specification was then rewritten in whole and advanced to Proposed Standard as RFC 4601 in 2006. Considering the multiple independent implementations developed and the successful operational experience gained, the IETF has decided to advance the PIM-SM routing protocol to Draft Standard. This survey intends to provide supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Proposed Standard to Draft Standard. (Due to RFC 6410, now the intention is to progress it to Internet Standard. Draft Standard is no longer used.) This survey is issued on behalf of the IETF PIM Working Group. The responses will be collected by a neutral third-party and kept strictly confidential; only the final combined results will be published. Marshall Eubanks has agreed to anonymize the response to this Questionnaire. Marshall has a long experience with Multicast but has no direct financial interest in this matter, nor ties to any of the vendors involved. He is also a member of the IAOC, Chair of the IETF Trust and co-chair of the IETF Layer 3 VPN Working Group. Please send Questionnaire responses to his email address, marshall.euba...@gmail.com. He requests that such responses include the string "RFC 4601 bis Questionnaire" in the subject field. Before answering the questions, please comple the following background information. Name of the Respondent: Affliation/Organization: Contact Email: Provide description of PIM deployment: Do you wish to keep the information provided confidential: Questions: 1 Have you deployed PIM-SM in your network? 2 How long have you had PIM-SM deployed in your network? Do you know if your deployment is based on the most recent RFC4601? 3 Have you deployed PIM-SM for IPv6 in your network? 4 Are you using equipment with different (multi-vendor) PIM-SM implementations for your deployment? 5 Have you encountered any inter-operability or backward- compatibility issues amongst differing implementations? If yes, what are your concerns about these issues? 6 Have you deployed both dense mode and sparse mode in your network? If yes, do you route between these modes using features such as *,*,RP or PMBR? 7 To what extent have you deployed PIM functionality, like BSR, SSM, and Explicit Tracking? 8 Which RP mapping mechanism do you use: Static, AutoRP, or BSR? 9 How many RPs have you deployed in your network? 10 If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446) or Anycast-RP using PIM (RFC 4610)? 11 Do you have any other comments on PIM-SM deployment in your network?
Re: How to fix authentication (was LinkedIn)
On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth wrote: > - Original Message - >> From: "Leo Bicknell" > Yes, but you're securing the account to the *client PC* there, not to > the human being; making that Portable Enough for people who use and > borrow multiple machines is nontrivial. Or a wizard in your browser/OS/whatever could prompt you to put in a 'special' USB key and write the identity data there, making it portable. Or like my ssh keys, I have one on my home computer, one on my work computer, one on my USB drive, etc... If I lose my USB key, I can revoke the SSH key and still have access from my home computer. And I'm sure someone would come up with the 'solution' where they store the keys for you, but only you have the passphrase...ala lastpass. -A
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 11:05 PM, Jay Ashworth wrote: > - Original Message - >> From: "Dave Hart" > >> Sure, there are folks out there who believe NAT gives them benefits. >> Some are actually sane (small multihomers avoiding BGP). You stand >> out as insane for attempting to redefine "transparent" to mean >> "inbound communication is possible after negotatiation with multiple >> levels of NAT". >> >> > However, it does not invalidate end to end NAT as a counter >> > argument against people insisting on IPv6 so transparent with >> > a lot of legacy NAT used by people who loves it. >> > >> > That is, end to end transparency can not be a reason to >> > insist on IPv6. >> >> It certainly is, for those of us not arguing by redefinition. > > Ah, you're on the "I should be required to allow direct outside connection > to my interior machines if I want to be connected to the Internet" crowd. Not quite. I'd go for "I should be able to permit direct outside connection to my interior machines via stable IPv6 prefix, or it's not really the Internet to me." Packet filter to your heart's content. 1:1 NAT your clients if you believe breaking connectivity is in your interest. Cheers, Dave Hart
AAA design document pointers
My takeaway from the conversations we're having as the second and third-order resultants of the LinkedIn password break is that, if there *is* an accepted definition of the problem, in slices small enough for implementers to understand, a lot of people haven't read it. Including me. *Is* there a good defnition of the current shape of the authentication/ authorization problem as it presently exists in the Wide Area with the General Public as audience, which someone can point to? One that identifies, as it goes along, all the points we batted around today, like "person or PC", "multiple accounts", "non/repudiation", and whatever you call "multiple services not being able to tell you're the same person as an account holder, unless you *want* them to"? Not even the solutions, you understand, just the definition of the problem? Seems to me we're on different pages in the hymnal... Off-list, please; I'll summarize. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: How to fix authentication (was LinkedIn)
who would mediate/verify/validate the trust transactions, though... thats the hard part. On Wed, Jun 20, 2012 at 7:46 PM, wrote: > On Wed, 20 Jun 2012 19:31:40 -0400, Kyle Creyts said: >> Guess we all need implants deep in less-than-easily-operable areas to >> bind us to a digitally-accessible identity. This would make for an >> interesting set of user-based trust-anchoring paradigms, at least. > > Credential revocation would suddenly get more interesting. And I'm > sure there's a divorce lawyer or 3 out there who will get some creatively > evil ideas... -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
Re: How to fix authentication (was LinkedIn)
On Wed, 20 Jun 2012 19:31:40 -0400, Kyle Creyts said: > Guess we all need implants deep in less-than-easily-operable areas to > bind us to a digitally-accessible identity. This would make for an > interesting set of user-based trust-anchoring paradigms, at least. Credential revocation would suddenly get more interesting. And I'm sure there's a divorce lawyer or 3 out there who will get some creatively evil ideas... pgpWCRzD3JXmG.pgp Description: PGP signature
RE: How to fix authentication (was LinkedIn)
There should be a way to authenticate the same user differently depending on what device they're using and tie it all together in a central place; of course if that central place gets compromised it would be horrible.. Still, I think it would help if you use the same password on every site if your browser could encrypt or hash the password before it sends it to the website. That way at least if the website doesn't properly store the passwords they'll be encrypted anyway =) -Drew -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Wednesday, June 20, 2012 7:27 PM To: NANOG Subject: How to fix authentication (was LinkedIn) - Original Message - > From: "Leo Bicknell" > SSL certificates could be used this way today. > > SSH keys could be used this way today. > > PGP keys could be used this way today. > > What's missing? A pretty UI for the users. Apple, Mozilla, W3C, > Microsoft IE developers and so on need to get their butts in gear and > make a pretty UI to create personal key material, send the public key > as part of a sign up form, import a key, and so on. Yes, but you're securing the account to the *client PC* there, not to the human being; making that Portable Enough for people who use and borrow multiple machines is nontrivial. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: LinkedIn password database compromised
> The fact that it is symmetric leads to the problem. > > Even if the attacker had fully compromised the server end they get > nothing. There's no reply attack. No shared secret they can use to log > into another web site. Zero value. with per-site passphrases there is no cross-site threat. there is replay, as you point out. would be interested to hear smb on this. > Yep. Don't get me wrong, there's an RFC or two here, a few pages of > code in web servers and browsers. I am not asserting this is a trival > change that could be made by one guy in a few minutes. However, I am > suggesting this is an easy change that could be implemented in weeks > not months. did you say RFC in the same sentence as weeks? but i definitely agree that we should be able to do better than we are now. randy
Re: How to fix authentication (was LinkedIn)
Guess we all need implants deep in less-than-easily-operable areas to bind us to a digitally-accessible identity. This would make for an interesting set of user-based trust-anchoring paradigms, at least. On Wed, Jun 20, 2012 at 7:26 PM, Jay Ashworth wrote: > - Original Message - >> From: "Leo Bicknell" > >> SSL certificates could be used this way today. >> >> SSH keys could be used this way today. >> >> PGP keys could be used this way today. >> >> What's missing? A pretty UI for the users. Apple, Mozilla, W3C, >> Microsoft IE developers and so on need to get their butts in gear >> and make a pretty UI to create personal key material, send the >> public key as part of a sign up form, import a key, and so on. > > Yes, but you're securing the account to the *client PC* there, not to > the human being; making that Portable Enough for people who use and > borrow multiple machines is nontrivial. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
How to fix authentication (was LinkedIn)
- Original Message - > From: "Leo Bicknell" > SSL certificates could be used this way today. > > SSH keys could be used this way today. > > PGP keys could be used this way today. > > What's missing? A pretty UI for the users. Apple, Mozilla, W3C, > Microsoft IE developers and so on need to get their butts in gear > and make a pretty UI to create personal key material, send the > public key as part of a sign up form, import a key, and so on. Yes, but you're securing the account to the *client PC* there, not to the human being; making that Portable Enough for people who use and borrow multiple machines is nontrivial. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: SIXSS not working?
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1820 possibly related? On Wed, Jun 20, 2012 at 11:34 AM, Jeroen Massar wrote: > Good morning (at least on this side of the planet), > > On 2012-06-20 02:14, Hank Nussbacher wrote:> On Wed, 20 Jun 2012, Jeroen > Massar wrote: >> >> Ill report it to them but: > > NANOG is afaik still not the "contact the people who run things" email > address... > > Nevertheless, if issues, do not hesitate to report to i...@sixxs.net > >> http://www.sixxs.net/tools/grh/tla/ >> Shows every country as V=0 (prefixes visible per country). > > That would mean that every prefix was not updated in the last day, > sounds odd to me. > > On 2012-06-20 04:00, Hank Nussbacher wrote: >> On Wed, 20 Jun 2012, Hank Nussbacher wrote: >> >> It would appear that whatever was broken is now fixed. > > The only thing I can think of is that you have noticed some weird glitch > of the kind there. > > As mentioned above the "Visible" is basically the amount of prefixes > visible in the last 24 hours. For that to become 0 it would have meant > that no prefix would have been seen for the last 24 hours. > > According to http://www.sixxs.net/tools/grh/status/ which just telnets > into grh.sixxs.net and asks for quagga's status, seems that even peering > sessions are connected for longer than that, thus I am puzzled to what > could have caused that then. > > Greets, > Jeroen > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
Re: LinkedIn password database compromised
In a message written on Thu, Jun 21, 2012 at 08:02:58AM +0900, Randy Bush wrote: > what is the real difference between my having holding the private half > of an asymmetric key and my holding a good passphrase for some site? > that the passphrase is symmetric? The fact that it is symmetric leads to the problem. The big drawback is that today you have to provide the secret to the web site to verify it. It doesn't matter if the secret is transfered in the clear (e.g. http) or encrypted (e.g. https), they have it in their RAM, or on their disk, and so on. Today we _trust_ sites to get rid of that secret as fast as possible, by doing things like storing a one way hash and then zeroing the memory. But what we see time and time again is sites are lazy. The secret is stored in the clear. The secret is hashed, but with a bad hash and no salt. Even if they are "good guys" and use SHA-256 with a nice salt, if a hacker hacks into their server they can intercept the secret during processing. With a cryptographic solution the web site would say something like: "Hi, it's 8:59PM, transaction ID 1234, cookie ABCD, I am foo.com, who are you." Your computer would (unknown to you) would use foo.com to figure out that bickn...@foo.com (or super...@foo.com) was your login, do some math, and sign a response with your private key that says: "Hi, I'm bickn...@foo.com, I agree it's 8:59 PM, transaction 1234, cookie ABCD." Even if the attacker had fully compromised the server end they get nothing. There's no reply attack. No shared secret they can use to log into another web site. Zero value. > s/onto web sites/this web site/ let's not make cross-site tracking any > easier than it is today. Yep. Don't get me wrong, there's an RFC or two here, a few pages of code in web servers and browsers. I am not asserting this is a trival change that could be made by one guy in a few minutes. However, I am suggesting this is an easy change that could be implemented in weeks not months. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpL49D9nWRoj.pgp Description: PGP signature
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
- Original Message - > From: "Dave Hart" > Sure, there are folks out there who believe NAT gives them benefits. > Some are actually sane (small multihomers avoiding BGP). You stand > out as insane for attempting to redefine "transparent" to mean > "inbound communication is possible after negotatiation with multiple > levels of NAT". > > > However, it does not invalidate end to end NAT as a counter > > argument against people insisting on IPv6 so transparent with > > a lot of legacy NAT used by people who loves it. > > > > That is, end to end transparency can not be a reason to > > insist on IPv6. > > It certainly is, for those of us not arguing by redefinition. Ah, you're on the "I should be required to allow direct outside connection to my interior machines if I want to be connected to the Internet" crowd. Got it. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: LinkedIn password database compromised
leo, what is the real difference between my having holding the private half of an asymmetric key and my holding a good passphrase for some site? that the passphrase is symmetric? > First time a user goes to sign up on a web page, the browser should > detect it wants a key uploaded and do a simple wizard. > - Would you like to create an online identity for logging into web > sites?Yes, No, Import s/onto web sites/this web site/ let's not make cross-site tracking any easier than it is today. randy
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Dave Hart wrote: > Sure, there are folks out there who believe NAT gives them benefits. > Some are actually sane (small multihomers avoiding BGP). They are sane, because there is no proper support for multiple addresses (as is demonstrated by a host with a v4 and a v6 addresses) nor automatic renumbering with neither v4 nor v6. Here, v6 is guilty for lack of transparency because they are the promised features of v6. But, there are people, including me, still working on them both with v4 and v6 and we know they are not a very hard problems. > You stand > out as insane for attempting to redefine "transparent" to mean > "inbound communication is possible I just say it is as transparent as hosts directly connected to the Internet with port based routing such as RSIP [RFC3102] hosts: : Abstract :This document examines the general framework of Realm Specific IP :(RSIP). RSIP is intended as a alternative to NAT in which the end- :to-end integrity of packets is maintained. We focus on :implementation issues, deployment scenarios, and interaction with :other layer-three protocols. and despite IESG note on it, RSIP is transparent to IPsec if SPI is regarded as port numbers. > after negotatiation with multiple > levels of NAT". It will be necessary with, according to your definition, insane configuration with multiple levels of NAT. >> That is, end to end transparency can not be a reason to >> insist on IPv6. > > It certainly is, for those of us not arguing by redefinition. The problem is that you are arguing against non existing redefinitions. Masataka Ohta
Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 06:37:50PM -0400, valdis.kletni...@vt.edu wrote: > I have to agree with Leo on this one. Key management *is* hard - especially > the part about doing secure key management in a world where Vint Cerf > says there's 140M pwned boxes. It's all nice and sugary and GUI-fied and > pretty and Joe Sixpack can do it - till his computer becomes part of the 140M > and then he's *really* screwed. I'm glad you agree with me. :) That's no different than today. Today Joe Sixpack keeps all his passwords in his browsers cache. When his computer becomes part of the botnet the bot owner downloads that file, and also starts a keylogger to get more passwords from him. In the world I propose when his computer becomes part of the botnet they will download the private key material, same as before. My proposal neither helps, nor hurts, the problem of Joe Sixpack's machine being broken into is orthoganal and not addressed. It needs to be, but not by what I am proposing. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpfhOcWj5KHW.pgp Description: PGP signature
Re: LinkedIn password database compromised
On Wed, 20 Jun 2012 14:39:14 -0700, Leo Bicknell said: > In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda > wrote: > > Key management: doing it right is hard and probably beyond most end users. > > I could not be in more violent disagreement. I have to agree with Leo on this one. Key management *is* hard - especially the part about doing secure key management in a world where Vint Cerf says there's 140M pwned boxes. It's all nice and sugary and GUI-fied and pretty and Joe Sixpack can do it - till his computer becomes part of the 140M and then he's *really* screwed. pgpUbmPBlgOeY.pgp Description: PGP signature
Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 03:05:17PM -0700, Aaron C. de Bruyn wrote: > You're right. Multiple accounts is unpossible in every way except > prompting for usernames and passwords in the way we do it now. > The whole ssh-having-multiple-identities thing is a concept that could > never be applied in the browser in any sort of user-friendly way. > Aw come on guys, that's really not hard, and code is already in the browsers to do it. If you have SSL client certs and go to a web site which accepts multiple domains you get a prompt, "Would you like to use identity A or identity B." Power users could create more than one identity (just like more than one SSH key). Browsers could even generate them behind the scenes for the user "create new account at foo.com" tells the browser to generate "bickn...@foo.com" and submit it. If I want another a quick trip to the menu creates "super...@foo.com" and saves it. When I go to log back in the web site would say "send me your @foo.com" signed info. Seriously, not that hard to do and make seemless for the user; it's all UI work, and a very small amount of protocol (HTTP header probably) update. In a message written on Wed, Jun 20, 2012 at 02:54:10PM -0700, Matthew Kaufman wrote: > Yes. Those users who have a single computer with a single browser. For > anyone with a computer *and* a smartphone, however, there's a huge > missing piece. And it gets exponentially worse as the number of devices > multiplies. Yeah, and no one has that problem with a password. Ok, that was overly snarky. However people have the same issue with passwords today. iCloud to sync them. Dropbox and 1Password. GoodNet. Syncing certs is no worse than syncing passwords. None of you have hit on the actual down side. You can't (easily) log in from your friends computer, or a computer at the library due to lack of key material. I can think of at least four or five solutions, but that's the only "hard" problem here. This has always failed in the past because SSL certs have been tied to _Identity_ (show me your drivers license to get one). SSH keys are NOT, you create them at will, which is why they work. You could basically coopt SSL client certs to do this with nearly zero code provided people were willing to give up on the identity part of X.509, which is basically worthless anyway. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgprmtzyIhFHO.pgp Description: PGP signature
Re: LinkedIn password database compromised
On Jun 20, 2012, at 5:54 PM, Matthew Kaufman wrote: > On 6/20/2012 2:39 PM, Leo Bicknell wrote: >> Users would find it much more convenient and wonder why we ever used >> passwords, I think... > > Yes. Those users who have a single computer with a single browser. For anyone > with a computer *and* a smartphone, however, there's a huge missing piece. > And it gets exponentially worse as the number of devices multiplies. Not including the "app culture" that results in things like the Hilton (for example) app being just a bookmark into their mobile website. That does not make it a fully fledged application. I could have used my web browser to get to the same place and flow better as well :) (oh and the per-brand apps that exist as well.. *sigh*). Not sure how to import my crypto key into those :) - Jared
Re: LinkedIn password database compromised
On Wed, Jun 20, 2012 at 2:44 PM, Elmar K. Bins wrote: > (Fight of the Leos...) > > bickn...@ufp.org (Leo Bicknell) wrote: > >> Users would find it much more convenient and wonder why we ever used >> passwords, I think... > > Yeah cool. Shame I have three accounts on peerindb.com alone... You're right. Multiple accounts is unpossible in every way except prompting for usernames and passwords in the way we do it now. The whole ssh-having-multiple-identities thing is a concept that could never be applied in the browser in any sort of user-friendly way. -A
Re: LinkedIn password database compromised
On 6/20/2012 2:39 PM, Leo Bicknell wrote: Users would find it much more convenient and wonder why we ever used passwords, I think... Yes. Those users who have a single computer with a single browser. For anyone with a computer *and* a smartphone, however, there's a huge missing piece. And it gets exponentially worse as the number of devices multiplies. Matthew Kaufman
Re: LinkedIn password database compromised
(Fight of the Leos...) bickn...@ufp.org (Leo Bicknell) wrote: > Users would find it much more convenient and wonder why we ever used > passwords, I think... Yeah cool. Shame I have three accounts on peerindb.com alone...
Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote: > Key management: doing it right is hard and probably beyond most end users. I could not be in more violent disagreement. First time a user goes to sign up on a web page, the browser should detect it wants a key uploaded and do a simple wizard. - Would you like to create an online identity for logging into web sites?Yes, No, Import User says yes, it creates a key, asking for an e-mail address to identify it. Import to drag it in from some other program/format, No and you can't sign up. Browser now says "would you like to sign up for website 'foobar.com'", and if the user says "yes" it submits their public key including the e-mail they are going to use to log on. User doesn't even fill out a form at all. Web site still does the usual e-mail the user, click this link to verify you want to sign up thing. User goes back to web site later, browser detects "auth needed" and "public key foo" accepted, presents the cert, and the user is logged in. Notice that these steps _remove_ the user filling out forms to sign up for simple web sites, and filling out forms to log in. Anyone who's used cert-based auth at work is already familiar, the web site "magically" knows you. This is MUCH more user friendly. So the big magic here is the user has to click on "yes" to create a key and type in an e-mail once. That's it. There's no web of trust. No identity verification (a-la ssl). I'm talking a very SSH like system, but with more polish. Users would find it much more convenient and wonder why we ever used passwords, I think... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpmm2yrs9KQ1.pgp Description: PGP signature
Re: LinkedIn password database compromised
Exactly! Passwords = Fail All we can do is make it as difficult as possible for them to crack it until the developers decide to make pretty eye candy. - Robert Miller (arch3angel) On 6/20/12 3:43 PM, Leo Bicknell wrote: In a message written on Wed, Jun 20, 2012 at 03:30:58PM -0400, AP NANOG wrote: So the question falls back on how can we make things better? Dump passwords. The tech community went through this back in oh, 1990-1993 when folks were sniffing passwords with tcpdump and sysadmins were using Telnet. SSH was developed, and the problem was effectively solved. If you want to give me access to your box, I send you my public key. In the clear. It doesn't matter if the hacker has it or not. When I want to log in I authenticate with my private key, and I'm in. The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now. I can use the same "password" (key) for every web site on the planet, web sites no longer need to enforce dumb rules (one letter, one number, one character your fingers can't type easily, minimum 273 characters). SSL certificates could be used this way today. SSH keys could be used this way today. PGP keys could be used this way today. What's missing? A pretty UI for the users. Apple, Mozilla, W3C, Microsoft IE developers and so on need to get their butts in gear and make a pretty UI to create personal key material, send the public key as part of a sign up form, import a key, and so on. There is no way to make passwords "secure". We've spent 20 years trying, simply to fail in more spectacular ways each time. Death to traditional passwords, they have no place in a modern world.
Re: LinkedIn password database compromised
>> What's missing? A pretty UI for the users. Apple, Mozilla, W3C, perhaps this is a good starting point: http://gpg4usb.cpunk.de/ GPLv3, lightweight, portable, compatibility with GNU/Linux and Windows
RE: LinkedIn password database compromised
Hi, Leo Bicknell wrote: [public key cryptography] > > What's missing? A pretty UI for the users. Apple, Mozilla, W3C, Microsoft IE developers and so on need to get their butts in gear and make a pretty UI to create personal key material, send the public key as part of a sign up form, import a key, and so on. Key management: doing it right is hard and probably beyond most end users. Regards, Leo smime.p7s Description: S/MIME cryptographic signature
Re: LinkedIn password database compromised
In a message written on Wed, Jun 20, 2012 at 03:30:58PM -0400, AP NANOG wrote: > So the question falls back on how can we make things better? Dump passwords. The tech community went through this back in oh, 1990-1993 when folks were sniffing passwords with tcpdump and sysadmins were using Telnet. SSH was developed, and the problem was effectively solved. If you want to give me access to your box, I send you my public key. In the clear. It doesn't matter if the hacker has it or not. When I want to log in I authenticate with my private key, and I'm in. The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now. I can use the same "password" (key) for every web site on the planet, web sites no longer need to enforce dumb rules (one letter, one number, one character your fingers can't type easily, minimum 273 characters). SSL certificates could be used this way today. SSH keys could be used this way today. PGP keys could be used this way today. What's missing? A pretty UI for the users. Apple, Mozilla, W3C, Microsoft IE developers and so on need to get their butts in gear and make a pretty UI to create personal key material, send the public key as part of a sign up form, import a key, and so on. There is no way to make passwords "secure". We've spent 20 years trying, simply to fail in more spectacular ways each time. Death to traditional passwords, they have no place in a modern world. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpjw9J6dZJCK.pgp Description: PGP signature
Re: LinkedIn password database compromised
I normally don't respond and just sit back leeching knowledge, however this incident with LinkedIn & eHarmony strikes close to home. Not just because my password was in this list of dumped LinkedIn accounts, but the fact that this incident struck virtually every business professional and corporation across the world. Please bare with me while I ramble a few thoughts... The real problem with authentication falls on "trust". You either have to trust the website is storing the data securely or some other party will verify you are who you really are. Just as in the example of the DMV. If you think about your daily life you have put your entire life on display for the world. You trust the DMV with your drivers license information, address, social security number, heck they are even asking for email now. If your active or prior military you have given that same information, plus DNA and fingerprints. Think about how much information about you and your habits occur from simply using "rewards" cards, or "gas points". You, meaning users, give up your identity everyday and with little regard, but when it comes to a website or tracking you across websites we throw our hands up and scream "stop". Please don't get me wrong, I am a HUGE fan boy of privacy and protection of data, but responsibility ultimately falls back on the user. Those users who do not know any better are still at fault, but it is our job to educate them in better methods of protection. So the question falls back on how can we make things better? The fact that we must trust people outside ourselves is key. We need to explain the importance of things such as KeePass (http://keepass.info/), and pass-phases, rather than words. Below is an example, my password which was leaked during the LinkedIn dump, but till I started using this as an example the likelihood of the hash being cracking it was VERY slim. Use this as an example of how to select a password for websites and how even if the hashes are dumped the likelihood of cracking it is slim. Password: !p3ngu1n_Pow3r! SHA1 Hash: b34e3de2528855f02cf9ed04c217a15c61b35657 LinkedIn Hash: 0de2528855f02cf9ed04c217a15c61b35657 To crack this pass-phase using the following systems it would take the the associated amount of time: $180,000 cracker it would take roughly 2 decades, 7 years to complete the crack $900 cracker it would take 3 centuries, 3 decades to complete the crack Average graphics card it would take 15 centuries to complete the crack Average desktop computer would take 795 centuries to complete the crack Now what does this mean in the schema of things. You cannot trust any website, third party identity verification, one time password, etc. You can only trust yourself in creating a password that even if dumped will make it nearly impossible to crack. Use some form of nomenclature to identify a website separate from the base pass-phrase, thus giving you individual "passwords" and in turn if one site gets dumped the others remain safe. Practicality is more along the lines of what the solution is. It is not practical to develop an pub/priv solution because of the user themselves, it is however practical to educate everyone we meet, preaching to them how to make simple changes can increase their protection ten fold. A similar question though comes from "Website xyz.com was just dumped, how do I know if my password was in this group?". Just from previous experience, organizations release the warning stating they had a breach, but it normally takes a good bit of time, as seen with LinkedIn, for them to release who was part of this dump. If they ever really do, sometimes it becomes a blanket "We were breached please change your password." story. If a website you have been using is breached then I revert back to the original statement saying that the issue becomes trust. In the early days of LinkedIn websites claiming to check your password against the database dump were popping up left and right. Is it truly wise to jump to these sites and put your password, which potentially will take decades to crack, into a website that claims to check it without storing that password anywhere. I know there are sites which were created by companies and individuals with outstanding reputations, however it was outside my control and thus not trusted. I decided to write a small, very simple, Python script that will run on your local machine and allow you to check your password against the dump of hashes. Right now it only does the LinkedIn dumps, but my goal is to do any dump all you have to do is point it to the file. I also then decided to take a little longer on the next release and learn to code in a GUI for users who may not be a techie. I will continue to work on the GUI release, but if you want to get that release email me and I'll make sure you are aware of its release. Until then I hope this helps those who
Re: Cisco Smartnet for 6509E Line Cards
This is also the way I have understood "chassis" Smartnet in the past, that is that line cards have always been covered, and in my career, Cisco has always replaced (RMA'd) failed line cards of any kind no questions asked. This seems to be a new Cisco policy, quoting Smartnet for line cards. Does anyone know if companies like Arista, which advocate "merchant silicon" for their Ethernet switches, have a one price support contract for the "whole ball of wax" if a component fails in their switches? Regards, David On Wed, Jun 20, 2012 at 5:26 AM, STARNES, CURTIS < curtis.star...@granburyisd.org> wrote: > That is the way I understood it in the past but: > I recently priced a new 10G blade for our 6509 and was quoted Smartnet for > it. > I asked about if it was covered under the chassis Smartnet and was told > that line cards were not covered. > I do know that I have replaced the supervisor card before under the > Smartnet contract on the chassis. > My understanding now is that the chassis, supervisor card, fan trays, and > power supplies are covered by the chassis Smarnet. > Any line cards added need to be covered with their own Smartnet contract. > > If anyone knows better, please let us (me in particular) know. > I work in the K-12 educational market and right now the Smarnet on the > chassis runs about 30% of what the chassis costs (bare chassis without sup, > fans, and power supplies). > If the sup, fan trays and powers supplies are not covered then that is a > steep price to pay for a bare chassis. I could buy another chassis and put > on the shelf and it would be cheaper since the chassis itself would have to > be abused badly to need replacing. > > If the chassis, supervisor, fans, and power supplies are covered under the > chassis contract then the pricing on the chassis contract makes sense. > > Curtis > > -Original Message- > From: david peahi [mailto:davidpe...@gmail.com] > Sent: Wednesday, June 20, 2012 12:02 AM > To: nanog@nanog.org > Subject: Cisco Smartnet for 6509E Line Cards > > Can anyone comment on Cisco 6509E Smartnet "chassis" coverage? In the > past, "chassis" has always meant, not just the passive chassis itself, but > all of the components including supervisor cards, line cards, power > supplies, fan trays, etc. Now it appears that Cisco is requiring Smartnet > coverage on line cards in addition to the chassis. > My understanding is that Smartnet functioned much like insurance policies, > where Cisco collected maintenance contract fees year after year, but the > devices were generally so reliable that the collected Smartnet fees always > far exceeded the dollar amount required to replace failed components. > > Regards, > > David >
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 8:44 AM, Masataka Ohta wrote: > Because we still have enough IPv4 addresses, because most > users are happy with legacy NAT and because some people > loves legacy NAT, there is not much commercial motivation. Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine "transparent" to mean "inbound communication is possible after negotatiation with multiple levels of NAT". > However, it does not invalidate end to end NAT as a counter > argument against people insisting on IPv6 so transparent with > a lot of legacy NAT used by people who loves it. > > That is, end to end transparency can not be a reason to > insist on IPv6. It certainly is, for those of us not arguing by redefinition. Cheers, Dave Hart
Saleslurkers - onnet check in greenville nc
Anyone have it? 638 Chapman Rd., Greenville, NC 28590 Thanks Chris -- Sent from my mobile device
Re: SIXSS not working?
Good morning (at least on this side of the planet), On 2012-06-20 02:14, Hank Nussbacher wrote:> On Wed, 20 Jun 2012, Jeroen Massar wrote: > > Ill report it to them but: NANOG is afaik still not the "contact the people who run things" email address... Nevertheless, if issues, do not hesitate to report to i...@sixxs.net > http://www.sixxs.net/tools/grh/tla/ > Shows every country as V=0 (prefixes visible per country). That would mean that every prefix was not updated in the last day, sounds odd to me. On 2012-06-20 04:00, Hank Nussbacher wrote: > On Wed, 20 Jun 2012, Hank Nussbacher wrote: > > It would appear that whatever was broken is now fixed. The only thing I can think of is that you have noticed some weird glitch of the kind there. As mentioned above the "Visible" is basically the amount of prefixes visible in the last 24 hours. For that to become 0 it would have meant that no prefix would have been seen for the last 24 hours. According to http://www.sixxs.net/tools/grh/status/ which just telnets into grh.sixxs.net and asks for quagga's status, seems that even peering sessions are connected for longer than that, thus I am puzzled to what could have caused that then. Greets, Jeroen
Re: TW in ohio
Thank you for the information. I just wish they would get it all working. At this point I would be happy with a GRE tunnel to a router that had IPv6. I use tunnel broker now but with the low lease time of the TW dhcp server i have to run the updater script just about every hour to keep the tunnel up. /beginrant When I called the tech support line trying to get information about their IPv6 plans it was like talking to a brick wall. Eventually I got a supervisor on the phone and he stated that there was no need for IPv6. Everytime I talk to their support I feel dumber and dumber. They don't even know the difference between a software issue and a network issue in most cases. I called about seeing extremly high latency at the border router as seen by traceroute at 2 seperate locations and they refused to do anything until I requested them to talk to their supervisor. They put a ticket in to the advanced tech support but I never heard a word from them. /endrant... So maybe they can't do IPv6 until they get the network issues taken care of. Somedays I miss having qwest, their tech support was great. My account was tagged in someway and they usually asked if I would like to be sent straight to level 2 support once they looked up my account. Maybe someone from TW tech support will eventually see our messages and give the official response. Brian Henson On Tue, Jun 19, 2012 at 10:18 PM, wrote: > Brian, > When I called Roadrunner about a week before IPV6 day, they had trouble > finding > anyone even in the business tech people that knew if it was even partially > working > for residential or not. I also had signed up over a year ago for testing, > heard nothing. > Our datacenter in Columbus is fully IPV6, and I could route a /64 to me > over an > IPV6->IPV4 tunnel to my D-Link DIR-825 router and it worked great, > contacted any > IPV6 site no problems from within my residential RR network. > But as far as native, they have no idea when, if even by year end. > I couldn't even get a straight answer if they were doing IPV6 over their > business class, > so who knows. They don't even have the IPV6 testing signup page any more. > > Gary Anagnostis > CompleteWeb.Net > > > > Anyone here using timewarrner residential able to use IPv6 natively > during > > world IPv6 day? I have the equipment to support it but never saw any > ipv6 > > address being assigned to my firewall. > > > > Brian Henson > > > > >
RE: Cisco Smartnet for 6509E Line Cards
That is the way I understood it in the past but: I recently priced a new 10G blade for our 6509 and was quoted Smartnet for it. I asked about if it was covered under the chassis Smartnet and was told that line cards were not covered. I do know that I have replaced the supervisor card before under the Smartnet contract on the chassis. My understanding now is that the chassis, supervisor card, fan trays, and power supplies are covered by the chassis Smarnet. Any line cards added need to be covered with their own Smartnet contract. If anyone knows better, please let us (me in particular) know. I work in the K-12 educational market and right now the Smarnet on the chassis runs about 30% of what the chassis costs (bare chassis without sup, fans, and power supplies). If the sup, fan trays and powers supplies are not covered then that is a steep price to pay for a bare chassis. I could buy another chassis and put on the shelf and it would be cheaper since the chassis itself would have to be abused badly to need replacing. If the chassis, supervisor, fans, and power supplies are covered under the chassis contract then the pricing on the chassis contract makes sense. Curtis -Original Message- From: david peahi [mailto:davidpe...@gmail.com] Sent: Wednesday, June 20, 2012 12:02 AM To: nanog@nanog.org Subject: Cisco Smartnet for 6509E Line Cards Can anyone comment on Cisco 6509E Smartnet "chassis" coverage? In the past, "chassis" has always meant, not just the passive chassis itself, but all of the components including supervisor cards, line cards, power supplies, fan trays, etc. Now it appears that Cisco is requiring Smartnet coverage on line cards in addition to the chassis. My understanding is that Smartnet functioned much like insurance policies, where Cisco collected maintenance contract fees year after year, but the devices were generally so reliable that the collected Smartnet fees always far exceeded the dollar amount required to replace failed components. Regards, David
Re: SIXSS not working?
On Wed, 20 Jun 2012, Hank Nussbacher wrote: It would appear that whatever was broken is now fixed. -Hank On Wed, 20 Jun 2012, Jeroen Massar wrote: Ill report it to them but: http://www.sixxs.net/tools/grh/tla/ Shows every country as V=0 (prefixes visible per country). -Hank On 2012-06-20 01:04, Hank Nussbacher wrote: > I am seeing all IPv6 prefixes that are monitored by Sixxs as being down > and unavailable. Hmmm, I didn't see this on i...@sixxs.net which would be the usual place to report any issues with respect to SixXS, but there the same reply would be given: which monitoring of which prefixes? I can only assume you mean the GRH portion of SixXS: http://www.sixxs.net/tools/grh/status/ But there most of it looks fine (ignoring the broken peering sessions) thus I can only wonder what the issue might be. But maybe I am missing something obvious ;) If you do see something that looks out of the ordinary, don't hesitate to report it to i...@sixxs.net as quite clearly stated on the contact page and apparently needs repeating on the NANOG list... Greets, Jeroen
Re: SIXSS not working?
On Wed, 20 Jun 2012, Jeroen Massar wrote: Ill report it to them but: http://www.sixxs.net/tools/grh/tla/ Shows every country as V=0 (prefixes visible per country). -Hank On 2012-06-20 01:04, Hank Nussbacher wrote: I am seeing all IPv6 prefixes that are monitored by Sixxs as being down and unavailable. Hmmm, I didn't see this on i...@sixxs.net which would be the usual place to report any issues with respect to SixXS, but there the same reply would be given: which monitoring of which prefixes? I can only assume you mean the GRH portion of SixXS: http://www.sixxs.net/tools/grh/status/ But there most of it looks fine (ignoring the broken peering sessions) thus I can only wonder what the issue might be. But maybe I am missing something obvious ;) If you do see something that looks out of the ordinary, don't hesitate to report it to i...@sixxs.net as quite clearly stated on the contact page and apparently needs repeating on the NANOG list... Greets, Jeroen
Re: SIXSS not working?
On 2012-06-20 01:04, Hank Nussbacher wrote: > I am seeing all IPv6 prefixes that are monitored by Sixxs as being down > and unavailable. Hmmm, I didn't see this on i...@sixxs.net which would be the usual place to report any issues with respect to SixXS, but there the same reply would be given: which monitoring of which prefixes? I can only assume you mean the GRH portion of SixXS: http://www.sixxs.net/tools/grh/status/ But there most of it looks fine (ignoring the broken peering sessions) thus I can only wonder what the issue might be. But maybe I am missing something obvious ;) If you do see something that looks out of the ordinary, don't hesitate to report it to i...@sixxs.net as quite clearly stated on the contact page and apparently needs repeating on the NANOG list... Greets, Jeroen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
valdis.kletni...@vt.edu wrote: >> hosts. However, for an ISP operating the NAT gateway, it may be >> easier to operate independent servers at default port for DNS, SMTP, >> HTTP and other applications for their customers than operating >> application relays. > > So you're admitting that the NAT breaks things badly enough at the ISP > level that running a forwarding ALG is easier than actually making the > NAT work. No, I don't. I just wrote that, if servers' port numbers are not changeable, which has nothing to do with NAT, ISPs or someone else can run servers, not ALGs. It's like operating a server for whois, when whois commands had a hard coded fixed IP address of the server. Note that, at that time, the Internet was completely transparent that your argument has nothing to do with the transparency. >>> (HInt - we haven't solved that problem for NAT yet, it's one of the big >>> reasons that NAT breaks stuff) >> >> As you can see, there is no such problem. > > You haven't actually *deployed* your solution in a production environment, > have you? Because we still have enough IPv4 addresses, because most users are happy with legacy NAT and because some people loves legacy NAT, there is not much commercial motivation. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. Masataka Ohta
SIXSS not working?
I am seeing all IPv6 prefixes that are monitored by Sixxs as being down and unavailable. Anyone know why? Thanks, Hank
Re: solid v smart optics
On (2012-06-19 17:07 -0700), ryanL wrote: > anyone have any opinions on the two subject vendors, with general > regard to 10GE transceivers? SR multi-mode data center stuff for my > application. I'm not familiar with solid optics, but AFAIK smart optics today resells finisar, so you probably don't need to worry about quality When choosing optic vendor, you might want to find out - where do they source the parts, if they self-assemble, whose lasers/receivers they use. Do you value single source for parts? It means longer lead-times but you can expect consistent quality. - do you value on-site eepromming, does vendor offer it - do all the optics support DDM, in your equipment - so you have sufficient datasheets for each optic, not too interesting in SR though - how far is the price from market price (10G LR can sell at 1unit anywhere from 120USD to 300USD, SR should be significantly less) - does the vendor have references you can verify -- ++ytti
RE: Cisco Smartnet for 6509E Line Cards
I have found that SmartNet is good for only "software" updates in certain gear. 3rd party maintenance is MUCH cheaper when regarding to "6500" gear as it is NOT a distributed architecture as the 12000 series. IMHO Larz -Original Message- From: PC [mailto:paul4...@gmail.com] Sent: Wednesday, June 20, 2012 1:29 AM To: david peahi Cc: nanog@nanog.org Subject: Re: Cisco Smartnet for 6509E Line Cards I'd say hardware replacement is only a small benefit of smartnet, or I would have found it more economical to just stock spares a long time ago. You also received technical support in addition to software updates. In fact, IMHO, the greatest benefit is the access to Cisco development resources for both defect resolution and software updates. In fact, I see little value in continued smartnet past last date of software development, and that typically is my cancellation date well before end of life. Besides, between that date and EOL, chances are stocking spares is dirt cheap and you little other benefit... On Tue, Jun 19, 2012 at 11:02 PM, david peahi wrote: > Can anyone comment on Cisco 6509E Smartnet "chassis" coverage? In the past, > "chassis" has always meant, not just the passive chassis itself, but all of > the components including supervisor cards, line cards, power supplies, fan > trays, etc. Now it appears that Cisco is requiring Smartnet coverage on > line cards in addition to the chassis. > My understanding is that Smartnet functioned much like insurance policies, > where Cisco collected maintenance contract fees year after year, but the > devices were generally so reliable that the collected Smartnet fees always > far exceeded the dollar amount required to replace failed components. > > Regards, > > David >
