July 2013 - Test - lists.nanog.org

Re: .nyc - here we go...
by Scott Weeks 03 Jul '13

03 Jul '13

--- rubensk(a)gmail.com wrote: From: Rubens Kuhl <rubensk(a)gmail.com> > Thank you for explaining this. Again, probably. <snip> Summary: there are residual risks, but the checks and balances of the process are likely to stop bad actors, at the cost of also stopping some good actors. Error in the side of caution preferred. ----------------------------------------------------------- Thanks for the explanation. I will begin to learn more about this. scott

1 0

RPKI Dashboard
by Thijs Stuurman 03 Jul '13

03 Jul '13

FYI, source information: http://staff.science.uva.nl/~delaat/rp/2012-2013/index.html#Presentations-r… Dashboard: http://academic.slowpoke.nl/ With kind regards, Thijs Stuurman

2 1

Perl router snmp to DNS
by Jensen Tyler 03 Jul '13

03 Jul '13

My Google fu is failing. Can anybody point me to a script that will create DNS entries from router snmp info? Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC

3 2

Re: [cryptography] Google's QUIC
by Eugen Leitl 03 Jul '13

03 Jul '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Wed, 03 Jul 2013 13:24:54 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] Google's QUIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 On 3/07/13 12:37 PM, Eugen Leitl wrote: > ----- Forwarded message from Saku Ytti <saku(a)ytti.fi> ----- > > Date: Tue, 2 Jul 2013 21:35:58 +0300 > From: Saku Ytti <saku(a)ytti.fi> > To: nanog(a)nanog.org > Subject: Re: Google's QUIC > User-Agent: Mutt/1.5.21 (2010-09-15) > > On (2013-06-29 23:36 +0100), Tony Finch wrote: > >> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf > > Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. > > QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to > attribute as chance, considering both are DJB's work, both are used by his > NaCl library and by extension by MinimaLT. Neither is particularly common > algorithm. It's not the choice of algorithm that is "by chance" it is the choice of suite as a design decision that matters. I also would like to use the same ciphersuite, but the reason is that DJB has already done the work to define the entire suite, saving me from doing it. This is quite a saving for me, and hasn't hitherto existed as an external service. Last time it took over a month of hard research and learning to settle on RSA/AES128/CBC/SHA1/HMAC/Encrypt-then-mac. As an added bonus, DJB came up with a shorter, catchier name: curve25519xsalsa20poly1305 In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification ... Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work. > I'm not implying QUIC plagiarizes MinimaLT, there are differences in the > protocol, just choice of the algorithm implies QUIC authors are aware of > MinimaLT. Picking curve25519xsalsa20poly1305 is good enough for that One True CipherSuite motive alone, and doesn't imply any other sort of copying one might have seen. It's an innovation! Adopt it. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: .nyc - here we go...
by Larry Sheldon 03 Jul '13

03 Jul '13

On 7/2/2013 11:39 PM, Andrew Sullivan wrote: > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon <LarrySheldon(a)cox.net> > wrote: > >> Makes me wonder if concern for routing table size is worrying about >> the right thing. > > Because obviously, the problems of scaling router memory and scaling > DNS servers are the same kind? I would not say "same" but I would say "similar" and "related" when you think about things like how big the cache will be and how much of the traffic the peerages worry about will be pure overhead, and stuff like that. > Yes, having many many new TLDs introduces new problems. (If you're > not scared enough, I encourage you to go read the output of the > Variant Issues Project. Full disclosure: I had a hand in.) Why are > we talking about this non-news now? We all knew about three years > ago, at the latest, that ICANN was planning to do this. If we > didn't, shame on us. What is going to happen tomorrow is sometimes less interesting that what is happening a while ago. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Re: .nyc - here we go...
by Scott Weeks 03 Jul '13

03 Jul '13

--- rubensk(a)gmail.com wrote: From: Rubens Kuhl <rubensk(a)gmail.com> > As places like that see $186,000 as small change, I wonder > what other countries (much less the cities within them) > like .nu, .sb or .vu will do? For them this is an > astronomical number. Someone's about to hit a financial > home run reminiscient of the tech-stock bubble... > No countries were obliged to apply. Both country codes and country names were excluded from the new gTLD process. Actually, they couldn't even apply, as they are considered ccTLDs. > I haven't read enough, but what's to stop speculators > paying the $186,000 then charging the tiny countries > mors when they are able to make the purchase? Please > don't suggest arbitration because that only increases > the cost to those countries. ------------------------------------------------------------- Thank you for explaining this. Again, probably. So the cities in those countries could buy them (if they could afford them) but not the countries? So .portvila is available, but not .vanuatu? What about places like Singapore? The city name is the same as the country name. "I haven't read enough, but what's to stop speculators paying the $186,000 then charging the tiny countries mors when they are able to make the purchase?" s/tiny countries/cities in tiny countries/ Does the speculator issue have to go to arbitration? scott

3 6

Re: .nyc - here we go...
by Scott Weeks 02 Jul '13

02 Jul '13

--- johnl(a)iecc.com wrote: From: "John Levine" <johnl(a)iecc.com> >I haven't read enough, but what's to stop speculators >paying the $186,000 then ... Rather than asking random strangers, you can read the applicant guidebook and find out what the actual rules are: http://newgtlds.icann.org/en/applicants/agb ---------------------------------------- Ok, you're correct. I need to add that to my list of reading. I am just thinking about the digital divide getting larger (not smaller) as these places are writing about on their various technical mailing lists. That kind of money is not insignificant to them. scott

3 2

Re: Ciena 6200 clue?
by Larry Sheldon 02 Jul '13

02 Jul '13

On 7/2/2013 6:30 PM, Jason Lixfeld wrote: > So I've got a bunch of Ciena 6200 kit in, with some of their professional services folks onsite, helping with the initial setup. I know nothing of this kit, other than from what I'm being told, it's pretty bleeding edge, so much so that not even many people at Ciena know how to use it. > > The SE who's onsite is apparently claiming that there is no provision to set a default gateway on the management interface. This seems odd to me. What is more odd is that we have to buy a manual for it. There isn't an electronic version available, even. > > I've created an account on their portal, so when that gets approved, I'll see what sort of documentation I can find, but off the top of anyone's head, does anyone know how to do this default gateway thing on the management interface? It's apparently been IP'd properly, so that much is working... > > Thanks in advance. Sorry for the lack of content otherwise. Adding to the useless and pointless: Why is all of this being found out after delivery? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

IPMI vulnerabilities
by Steven Bellovin 02 Jul '13

02 Jul '13

http://www.wired.com/threatlevel/2013/07/ipmi/ Capsule summary: watch out! --Steve Bellovin, https://www.cs.columbia.edu/~smb

5 5

ALTDB question.
by Faisal Imtiaz 01 Jul '13

01 Jul '13

Hello, A quick question for all. It's my understanding that the Maintainer object needs to be created first. This is accomplished by sending the template to db-admin(a)altdb.net This is not an automated process, but gets done manually. If there is any discrepancy then one gets a reply back with the error . a) Am I correct in my understanding of above ? b) Is there any auto reply to confirm email receipt ? or only replies are after the request is either complete or sent back for missing / incorrect info ? c) What would be the appropriate amount of time to wait for such a reply ? d) Is there a way to check to see if the Maintainer object has been created ? Many thanks in advance. I dealing with Altdb for the first time, so am looking for some base for what to expect and or not to expect. Regards. Faisal Imtiaz Snappy Internet & Telecom

2 1